Rolf Kalbermatter

vi.lib\platform\icon.llb\Read Icons from ICO File.vi will read in an icon file into a cluster and also into a Picture control. It's actually what is used in the old Application Builder to support custom icons. Note that there are limitations as to the bitdepths supported here but the Picture control functions should be able to deal at least with 1, 4, and 8 bit icons. I would expect this library to not work well with the XP style icons inside some icon file but the rest should be fine. Rolf Kalbermatter

In order to have the lvanlys.dll file in the same directory as the main dll you can change the directory location for the "Support file directory" to be the same as the "Destination directory". Not sure exactly how this would be done in the Project Explorer in LabVIEW 8 however. I do this all the time since I don't like the support dlls to end up in a different directory than my executable and customize the location of other support files afterwards in the "Custom Destinations" dialog. Sorry for chiming in so late here but I have been swamped with project work lately and have not participated in any LabVIEW forums very much for quite some time (well no forums at all really). And no I'm not really a master in creating LabVIEW DLLs but quite proficient in creating DLLs in Visual C and less proficient with other C compilers and then using them from LabVIEW in sometimes rather sophisticated ways ;-) It seems you want a possibilty to pass an array from some caller to a LabVIEW dll and possibly return it back. Unless you want to burden the user of your DLL with LabVIEW specific memory manager calls (and have him link his application with labview.lib which won't work for non Visual C users normally) you will need to pass C style pointers as function parameters. Sorry for only being able to show you here an example using the LabVIEW 7.1 application builder but I haven't used the LabVIEW 8 project explorer for DLL projects at all yet. First you have your VI that contains an input array and output array of some type. Now you can either make a separate pointer parameter for each of those arrays or combine them in one. The second approach will have some performance advantages since less memory buffers need to be allocated. Add your VI to your DLL project and configure the function prototype. Add a parameter for the array and set it to Input/Output type. Connect the VI input to your input array control and the VI output to your output array control and set it to pass the array ass Array Data Pointer. You can use the same length parameter for the Input and Output Length in which case LabVIEW will make the length parameter to be passed by reference. On calling the length parameter should contain the number of elements passed in the data pointer and on return the length parameter will indicate the number of elements LabVIEW copied back into the pointer. Et voila! This will cause LabVIEW to generate glue code to allocate a LabVIEW handle, copy the data from the array data pointer into the handle, then call the VI. On returning from the VI LabVIEW will copy back the array data into the pointer and update the length parameter accordingly. You can't avoid copying the array data twice unless you require the user to directly provide LabVIEW handles but that is going to be a very big restriction for using your DLL and it still should be a lot faster than reading and writing the data from and to disk. Attached is a small example for an Input/Output array DLL project for LabVIEW 7.1 Rolf Kalbermatter Download File:post-349-1168555016.zip

Well I agree with both of your assertions about Irene :-) However the problem is not that your VIs "loose" the connection to their subVIs nor that VIs are usually referenced by an absolute path (absolut paths are only used if the volume is different and under Windows this means also a different drive letter) but that VIs located in the "standard" locations such as vi.lib and user.lib are not referenced by their full path ever but by an artificial path similar to "<vi.lib>/local path" LabVIEW recognizes the special path component <vi.lib> and will search in its vi.lib directory but the runtime system by default has not such a directory (nor has it any other standard search paths configured by default) and will fail locating the VIs in there. Rolf Kalbermatter

Well that is not exactly true but it is a bit of a pain and for reentrant CINs you really can be in trouble sometimes. The most reliable way is to add DbgPrintf calls into your code. That is a LabVIEW manager function just like the other xxPrintf function explained in the External Code Reference manual but the output goes to a debug console window that opens on the first execution of this function instead of a memory buffer address. Another one is to add a DebugBreak() call (Windows OS API, other platforms have different calls) into your source that will cause a user breakpoint exception and break into the system debugger if any is installed. Otherwise you get an Exception dialog. However newer versions of LabVIEW add exception catching around external code calls (at least for Call Library Nodes, have not done any CINs for a long time). You can disable this exception catching from LabVIEW 7.1 onwards by adding the extFuncCatching=False entry to the LabVIEW.INI file. This won't work in LabVIEW 6.1 or 7.0 so debugging external code really is a pain there. Note that if your CIN (or DLL call) is reentrant your are likely to run into a deadlock situation (at least with Visual C 6.0, not sure about other debuggers) with the debugger blocking on some GFL (Windows global f***ing lock) and also locking LabVIEW entirely. The only solution I have found so far out of this is Ctl-Alt-Del and then retry debugging with reentrancy disabled. Rolf Kalbermatter

I think a somewhat smarter way for ini files (and XML files are just as simple) would be to add an extra key such as SecurityHash=AB123FE45... Calculate that hash using all the key names and values of that section in a deterministic way combined with a hardcoded private key and a hash function such as MD5 or maybe better SHA-1. On load read that key and verify it. If failed use default data instead. After having had to enter a complete configuration two times most users will probably stop altering files (or be so pissed off that they won't use your application anymore ;-) Rolf Kalbermatter

Well, yes if you are not familiar with DLL development (and shared libraries on other platforms than Windows) you won't get far. Basically you need to implement most of the lvsn... functions from the lvpython.h (lvsnapi.h in the newest CVS version only) header file and then drop that dll in the Resource/script folder inside your LabVIEW folder. As to the Node.vi there is no mystery. It is all documented albeit not well known. You create a VI that contains the preconfigured diagram and then creating a VI palette icon in the palette editor you enable the Merge VI option in the popup menu of the icon. With merge enabled LabVIEW will drop the diagram in your diagram instead of the entire subVI. Read in the LabVIEW documentation about how to create your own menu palettes if you haven't done so yet. Rolf Kalbermatter

Checkout VISA properties. If you have a VISA refnum you can get various properties for that and the Interface Information->Interface Description should contain extra information in the string for other than built in serial ports. Rolf Kalbermatter

I'm afraid this won't work. Since the operation you try to abort is most probably not asynchronous but just waits in the VISA driver itself for the complete or timeout event and is therefore synchronous in nature. Your best bet is to write a VI that does a VISA read in a loop with short timeout instead until data has been returned OR another error than timeout is returned OR your long timeout has elapsed and abort that loop through a global when you need to do so. A tiny bit of programming and thinking but an absolutely fail safe solution that depends nor on external code, nor on specific LabVIEW hidden or version dependant features. Rolf Kalbermatter

I just append an improved version of the _browser WREG Read Key.vi here that is used by above mentioned Open Document on Disk.vi. I'm almost certain I had put that up somewhere already but may not remember right, so I do it now here. This VI takes into account extra registration of applciations for a certain file type and treats them the same way explorer does. The old way opened the last registered application for that file type. It is LabVIEW 7.1 format and the latest LabVIEW version might already contain this improvement, I didn't yet check. Rolf Kalbermatter Download File:post-349-1159618597.vi

I think it is amazing they even got it that far. As to supporting any and every header file format, this is going to be impossible. The windows.h header file hierarchy is so complicated, riddled with almost magic macros and other compiler specific stuff that to get this done you would have to create a real compiler. And that together with writing an OS is one of the things you absolutely do not want to do in LabVIEW. Every C compiler out there comes with its own platform SDK header files in order to support the specifics of that compiler. To try to compile with the original Windows SDK headers with another compiler than Visual C is almost impossible and a sure way to go insane, while you try to figure out which modifications need to be done to the several 100 headers to get them to not cause compile errors anymore. In addition there are several more or less commonly used C features LabVIEW simply can't deal with (yet), such as function pointers and complicated structures. Rolf Kalbemratter

This is not C++ and the DLL importer couldn't deal with C++ at all. It's standard C and defines a function pointer that can be used as callback parameter to another function. As such it is an advanced C feature a lot of people have trouble to understand. Worse it is not something LabVIEW could do directly for you, so if you need to use the function that takes this function pointer as a parameter, you can't do without writing an intermediate DLL and converting in there the callback into an occurrence or user event for LabVIEW. Rolf Kalbermatter

This looks pretty big and it would seem strange if you were not using some .Net, ActiveX, DDE , DAQ, GPIB, and DLLs/CINs in there somehow. Any of these and a few more can be a more or less big stumbling block depending on your experience in those areas. Rolf Kalbermatter

Of course not! Active X is based on OLE which is a proprietary MS technology and there has been no working replacement for ActiveX on non-Windows platforms (and even if there would be LabVIEW for Linux does not support it). Since MS Office applications before the latest Office version use OLE structured storage for their file format too, you are more or less locked into Windows until you decide to use other data formats. Rolf Kalbermatter

It's not exactly clear what you try to do? If I understand you correctly, you want to pass in a LabVIEW data wire into a DLL Node and not wire the right side of that terminal, but instead have the DLL pass that same handle through another terminal back to the diagram This is not only gonna create a memory leak but also crash too, sooner or later. The reason is as follows: If you wire in something to the left side of a terminal pair in a DLL Node and not wire the right side, LabVIEW has to assume that the data is not used anymore and dispose of it. This would make the handle you return through another terminal invalid. At the same time if you do not wire anything to the left side of a terminal pair LabVIEW will allocate the default data (for instance an empty array) for the specified datatype to pass to the DLL but since you overwrite it with the now invalid handle inside the DLL you loose that handle. This is all logical when you follow the rule that whoever allocates memory should be concerned about disposing of it. In this case LabVIEW did allocate the memory in the diagram to pass to the DLL and also is responsible to dispose of it after the diagram does not seem to use it anymore. If you try to do magic behind LabVIEWs back inside the DLL you have to be EXTREMELY careful what you do. In most cases it is not worth the trouble to even try to do such things. Rolf Kalbermatter

Contact Eurosys. They told me in the past to have some LabVIEW VIs. No idea how good they are though. Rolf Kalbermatter

What LabVIEW version do you have. This has been in LabVIEW since 7.0. Look at Application Control->Cursor. Rolf Kalbermatter

Importing from the DLLs (OpenCV exists of several of them) is really a nitty gritty and time consuming work but still by far not the largest part of such a Toolkit. Many datatypes with OpenCV are specifically C oriented and not suited for direct consumption in LabVIEW so you will have to do some intermediate DLL programming such as what has been done in IVision, or suffer terrible performance. Then you need to make the automatically created VIs use more appropriate controls, add documentation, icons and help information to it. Otherwise nobody is going to use it since it is way to hard to understand. And there is nothing worse than an Open Source library that nobody does use. Rolf Kalbermatter

That's right and the fact that CRLF is used as message terminator but can also appear in the message itself makes it a bit complicated. However there has to be some specific protocol specification. Either you read in one line and from there can know what will have to follow if any (so your receive loop already needs to know about the specific protocol) or you have an empty line added to the end of every multiline message, which will indicate an end of message. Rolf Kalbermatter

Nope, DSHandles are NOT automatically disposed other than at application exit. The same applies to AZ handles. If they would be disposed at the end of your VI execution you would have real troubles to return them to a caller. The difference between DS and AZ really only is that AZ handles are relocatible between calls, which means that you need to lock them explicitedly if you want to dereference them and unlock them afterwards. LabVIEW maintains all its data that get exposed to the diagram excpet path handles in DS handles. However all modern platforms really have no difference between AZ handles and DS handles since locked handles still can be relocated in the lower level memory manager of the system without causing general protection errors, thanks to advanced memeory management support in nowadays CPUs. I believe that the actual AZ and DS distinction was only really necessary to support the old classic Mac OS. According to some postings on Info-LabVIEW from people who should know no flattening is actaully done. Rolf Kalbermatter

Lucky you! You seem never have to worked with older Visual Studio software releases :-) Rolf Kalbermatter There are better ways to commit suicide Rolf Kalbermatter

Since it is a text file I think modification of data is not that bad, especially since the LabVIEW internal end of line indicator is LF too. If you want binary consistency then accessing the file as binary file might be more appropriate. Also the file itself won't change before you save it back. As such I do hate the right click popup options of all those new nodes and that definitely has to go away. It hides fundamental functionality from anybody looking at the diagram and "that is a bad thing" TM. Rolf Kalbermatter

This does work but probably not as you would expect. LabVIEW prepends information to variable sized binary data such as arrays that tell it how many elements follow. So if you read back your array you would have to read back two arrays now. The first read would read the orignal array written to the file and the next read will read the appended array. This is logical and the only way to make this work since binary means just really that, and not some metaformat that would handle such concatenations and other hairy operations transparently. Rolf Kalbermatter

#defines are proeprocessor keywords and not part of the actual C compiler. Having a fully compliant proprocessor and a complete C compiler together in one single tool is a major undertaking getting you almost to the point of writing a complete C compiler (well at least the complete parser for it). THis is highly recursive and hard to implement so I guess the developers of the import shared library tool made a few decisions to restrict the parsing complexity. The used OF() macro is from the zlib header file and is used to work around some very old non C99 compatible compiler issues. There are not many compilers that need that anymore but the developers of zlib want to be compatible to as many compilers as possible. Rolf Kalbermatter

No, all the other functions are private and undocumented unless you happen to be a member of the LabVIEW developer team. LabVIEW 3.0 shipped with a much larger extcode.h file where you could see the prototypes of all those functions exported at that time. BUT: still no documentation about the functions and more importantly the parameters and I think LabVIEw exported maybe 500 functions or so back then, some of them are gone completely, others have changed considerably in prototype and/or behaviour. Unless you have a year or so of leisure time to dig into this I would recommend to forget about these functions. Rolf Kalbermatter

At least if ping hasn't been disabled for that computer. Nowadays with security concerns all over the place this is not something uncommon to happen. Rolf Kalbermatter