Neil Pate

Yup, I had the same thought actually about modifying the x node to take a DVR. Going to tinker with this when I get a moment. One of my issues with the CVT is that as it stands everything is a double right?

Very nice indeed I am thinking about using this in a project where I have to interface with some external equipment via OPC-UA and some other custom protocol. I have lots of "variables" (tags) and want to experiment how things can be done as much as possible by just using a channel name in my code rather than individual element access. Anybody given any thought as to how best to share the variant between processes? Lots of options here, as Kahrma mentioned perhaps a good technique is a DVR?

Ah yes, that is the same VI "GDI Resize" I am using now (Thanks Darin.K). Internally that VI does use the PNG Data to Lv Image. That solution works perfectly, I get a pixel perfect representation of my PNG file.

Here is the PNG

Chris, both images are the same size, the picture from the left is from paint .net, the one on the right are just the pixels represented by colourboxes. hooovahh, I think you are right. I actually found code on my PC very similar to what you linked to, and I tried this and it works perfectly. By the way, I also give credit and thanks to the author of the VI I found on my PC that I downloaded from lavag some time ago, it is called GDI Resize.vi So my conclusion is that something strange is happening in the PNG Read VI. I think I have peeked into it before and it is just a LabVIEW.exe function call wrapped?

Hi All, I am getting some strange behaviour when using LV to read a PNG file. For reasons I cannot explain I get coloured pixels where I do not expect them. The attachment shows what I expect versus what LV is giving me. I have tried playing around with the transparency threshold input as a last resort but this does not seem to have too much effect. Any ideas? Any other tricks for reading a PNG file?

Hi, sorry I just saw your post now. There is no tutorial I know that mixes LabVIEW and SDL. I basically used lazy foos SDL tutorial (http://lazyfoo.net/SDL_tutorials/) which are done in C, and just ported the logic to LabVIEW, wrapping the SDL DLL as needed.

Hi, Strange behaviour I am seeing in LV2015 32-bit (Win10). For some reason I cannot create a DAQmx task in a Virtual Folder in the project, only directly under My Computer. I am pretty sure I used to be able to do this. Any ideas what is going on here?

Smashing! That method does work, but it looks like the FP containing the control should not be open when this occurs, so it does not seem to be like clicking "Apply". Dunno, maybe I am still doing something wrong. Anyway, although this is a bit of a pain I think I can make this work now. Thanks Shaun

It is a strict typedef. Something like this? Does not seem to work for me. I can get it to work if I open the typedef, change it from strict to plain, apply changes, change back to strict and re-apply changes. Then everything is in sync.

Hi, I have created some code to programatically replace the pictures in a boolean. I am applying my logic to a strict typedef and it works nicely. However my changes to this typedef do not seem to be propagated properly to a VI that uses the control. In my solution the front panel of the VI with the control is open, and I have a reference to the control I wish to modify. From there I get the typedef control, and then update it using the LabVIEW resource functions. After that I update call the Update Typedef method. In the project I sometimes get a message that the file has changed if I then try and open the .ctl, and if I allow that the new skinning is indeed working, however in the original FP the control still contains the existing pictures. In the typedef I cannot apply changes as this menu operation is disabled. I have tried mass compiling and it to does not seem to pick up the new changes. Any ideas what I am doing wrong?

I definitely do not recommend the way I demonstrated. It is a terrible developer experience and I only prototyped it to see if my hunch was correct... Your method sounds much better

I don't think it is possible to just change the source. However, as the .lvws is just an zip I was able to create a quick and dirty application (source and build attached) that can be run after any changes have been made to the source files and re-create the .lvws file. I ended up not using the LV web service to host the web pages, so did not use this application it in the end, but I believe it works but don't blame me if your PC bursts into flames. Web Service Resource Combiner.zip

Hi Rolf, Any update on this? I have a project coming up which requires a scripted test sequence, and was thinking this could be a good opportunity to try this. Do you have a idea on pricing? Neil

I remember seeing something around about 2010 about this. If memory serves me correctly forum member jgcode did some digging into this and had a usable example, but there were some things preventing a complete solution. I also think there is a NI community page dedicated to this, but cannot find it either. Sorry!

Thanks for the info dhakkan and LogMAN. I was able to copy my files to SysWOW64 and LabVIEW-32 bit was able to read them, even though in the code there are hardcoded paths of c:\Windows\System32.

Happy new year everybody Now, onto this year's first conundrum. I am trying to get some customer code running on my PC, and am getting a bit unstuck with some strangeness that I cannot explain. In particular this application reads and writes to files in a directory, lets call it ABCD that lives in c:\Windows\System32\ (As an aside, I am well aware this is not exactly a Windows "best practice" to put stuff in System32, but that is how it has been done in the application (which is quite old now), and that is what I have to live with given that I have inherited ownership of the project) The trouble is, on my Win 10 dev PC LabVIEW cannot even "see" that directory. If I try and open any files in it I get error 7 (File Not Found), and in fact when I browse to the System32 directory from within LabVIEW the ABCD directory is not even visible. Clearly this some Windows permission problem, but I cannot figure out how to work around it. I have messed about with all the permissions of that directory, and according to Windows my user should have full access to that directory. I have even tried starting LabVIEW as an Administrator but still no joy. Strangely, even from within Windows I can create a new text file in that directory but cannot save it. Any ideas what is going on? Edit: perhaps this has something to do with 32-bit/64-bit compatibility? If I open LabVIEW 64-bit I can see the directory if I browse there and the same LabVIEW code then is able to open and read the file contents just fine. I really did not know directories and files could have a "bitness" assigned to them...

And you forgot the sentence termination character. ;-)

Ouch. I suspected that could be the case, but was too lazy to google it as I didn't think anybody would be as pedantic as I was being I will try and make better jokes in 2016...

Rolf, will this run on versions of LabVIEW greater than 2? My Windows 3 PC is quite dusty. <ducks> Jokes aside I am looking forward to seeing this, thanks for the update.

Hi All, I am trying to get a list of files out of a particular build script. I think I am mostly there, but stumbling at the last bit. Attached is my attempt so far. I can get the source tags for the build, but don't know what to convert the variant to. I know it is a reference of some type, but have tried a few things and none of them seem to work. Any tips? Nevermind, figured it out The RefNum is type ProjectItem, converting the variant to this then allows the Path to be read

I think booleans in LabVIEW are stored as bytes, not bits. All bits clear is a false and any other pattern is true. This can lead to some interesting tricks you can play when typecasting in between boolean and characters.

Not sure if this is of any help to anybody. It is a comparison of a blank VI saved in 2015 32/64-bit Test 1 - 32 bit.vi Test 1 - 64 bit.vi

I still don't really get who you are trying to secure yourself against. This seems like a lot of work for very little real reason. I suppose in response to your OP, I am in the don't care category. All my systems that have some kind of network comms are on an intranet, and if somebody else on that network is trying to maliciously ruin my day it really is not my problem. Where I need to expose things to the Internet I would never use raw tcpip. In those circumstances I use Web Services with their built in security features.

Years ago I did some embedded programming with pretty basic micros like the 8051, and they had a hardware stack that you would push to and pop from. Maybe this is where I am getting confused, I do not have any formal CS training so have just cobbled together knowledge over time.