Rolf Kalbermatter

Basically during development directories are a lot better. For distribution llbs may be handy. Library structure Pros > * Unused files are automatically removed from library at save time. This is not true. You have to load the top VI and selecte Save with Options to create a new directory structure or library which only contains the currently used VIs. This is the same for LLbs and directories. > * Upgrading your software to newer LV versions is easy because libraries can hold all the device drivers as well I think you talk about instrument drivers. Keeping them in a subdirectory to your project dir would achieve the same. * Moderate compression of maybe 10 - 30 %. Nothing really to write home about.With harddisks costing dollars per GB and the fact that decompressing will also take performance everytime LabVIEW needs to load the VI into memory. For archiving purposes it is a good idea to ZIP up the entire source code tree anyhow. Cons > * Returning the files to directories can't be done, or at least I don't know how. Wrong as pointed out. > * Referencing a file inside the library might be possible, is it? I think not. With VI server for sure. If you talk about accessing in in Explorer this is possible too. LabVIEW 7 and later has a feature in Options which installs a shell extension which allows you to browse LLB files (and see the VI icons of any LabVIEW file in the Explorer) > * If naming is not done correctly, it can be a drag to find a certain file from large library. Again with above shell extension (assuming you use Windows ;-) this problem is eased upon. * Source code control won't work easily. Directory structure Pros > * Easy to group logical set of files to different directories Yes! > * With dynamic calls, run time editing is possible No difference to LLBs. You just have to consider that LLBs are handled by LabVIEW like an additional directory level with the LLB name as directory name. * Source code control is much more effectively possible Cons > * Upgrading LV version changes device drivers to new version also. They may but more probably may not work. No difference to when using LLBs. You will need to keep the instrument drivers together with your project for that to work, but that is also what is happening when they are copied inside the LLB. LabVIEW has also no preference to use VIs in an LLB instead of in a directory. It simply will try to load the VI from where it was last located when the calling VI was saved and if not found will start to search its standard paths indifferent if they are in LLBs or not.

As long as it is about retrieving version information for executables and dlls you should try to look for the GetFileVersionInfo() and VerQueryValue() functions. Not really sure if they are in user32.dll. MSDN says they are provided by version.lib which would usually mean there should be a version.dll somewhere. Changing this information on existing files is a VERY bad idea as it will screw up installers which you might try to use to upgrade or uninstall existing applications. Accessing property pages of other Explorer namespace objects is very difficult to do without COM (the base of OLE) object handling.

I have meant to try to get something done but never got around it. And yes you can't do without DLL or CIN. Georgo Zou has however in his Toolkit functions to just do that. Rolf Kalbermatter

Another idea might be to use sub panels for this. Create the control as a subVI with all the code you might feel necessary and allow some sort of communication to the main VI for instance through user registered events or queues. Then whenever you need the control insert it with a simple call into a sub panel control. Rolf Kalbermatter

Well that is not entirely true. It's only true because you usually don't have folders with endings but if you name your folders for instance Folder.dir a search pattern of *.dir will return those folders. Of course I agree with you that looking for particular file patterns is a nice feature and I thought the OpenG version does that also. The problem with this is the requirement of the two List Directory Nodes for each hierarchy level which will almost take double the time than one node does. I think with preallocating the arrays and such one can win another few percent but the real time spent is in the List Directory node.

And I'm positive that they actually use some cryptographic algorithme such as MD5 or similar to protect the password so trying to fake the password is a rather difficult if not useless approach. The only way I could see is in patching the LabVIEW executable bij removing the password check altogether. But that is beyond my abilities.

Your approach will work too, but since your data is really a 16 byte short in big endian format you could take advantage of the fact that LabVIEW's flattened stream format is also normalized to be in big endian. Just pick out the interesting bytes and wire them to the Type Cast function in Advanced->Data Manipulation. Wire a int16 constant to the middle terminal e voila you get your numeric 16 bit signed value. This is simple fast and will work on any LabVIEW platform independant of the underlying endianess of the CPU, since LabVIEW takes care of the necessary (if necessary) byte swapping for you. If the number in the stream would be in little endian format you would just have to add a Byte Swap node from the same palette to the wire after the Type Cast. Really swaps bytes twice on little endian machines (only Intel CPUs ;-) but it's most probably still faster than doing the byte extraction and joining on your own.

Hi Michael I just took a look at your List Directory and thought there would be something to improve. Look at the attached version. On my computer it is almost two times faster in enumerating large directory trees even if it is called first in the timing test to not give it advantage through Windows directory list caching. Download File:post-10-1081496463.vi