Rolf Kalbermatter

What do you mean by a static class? Standard C has to the best of my knowledge nothing with that name and it rather sounds like a static C++ class you are talking about. And the Call Libary Node can not deal with anything that is C++ related. What you probably could do however is writing standard C function wrappers to all the methods of your static class and export them from your DLL. Rolf Kalbermatter

That is not a theory but a fact Rolf Kalbermatter

The __export is the Borland way of hinting to the linker that the function needs to be exported from the DLL. MS Visual C uses for that __declspec(dllexport). Another way of doing this is to create a .def file. But all of these things are highly compiler specific. The #ifdef __cplusplus extern "C" { #endif #ifdef __cplusplus } #endif are to tell the compiler to use standard C function name handling (disable C++ name mangling). You need to put these around the function prototype declarations of all functions that get exported from the DLL. Typically this is done at the begining and end of the header file(s) that define the exported function prototypes but for simple DLLs where you have only the C source file you can also put it around the function implementation itself. Please note that C++ name mangling is also compiler specific so if you want to create a library or DLL to be used in other compilers than the one that was used to create it disabling name mangling for exported symbols is usually a good idea. I'm sure 5 minutes of smart googling would have given you these answers too. Rolf Kalbermatter

While reentrancy is used here in both cases it is not exactly the same thing. Reentrancy for functions means just that they are basically protected from modifying parts that could collide if the same function is called again even before the first call has finished, including recursive calls. Reentrancy for VIs is a bit more complicated. For a start it means the same as for functions but in order to do that LabVIEW does quite a bit of extra resource handling. And this resource handling is quite expensive. Making all your VIs reentrant without need can make the difference between an application that uses a few MB of memory and one that uses 100s MB of memory, without being faster and possibly even getting slower due to vast memory usage. Reentrant VIs should only be made if a VI can have some lengthy operation that might actually wait (block on some external event or such) and should be able to be invoked multiple times in parallel. A VI that does execute fast or does not really idle in some ways for some time almost always will cause the performance of the application to be lower when it is set to reentrant execution. Another use of reentrancy for VIs is the special case of uninitialized shift register maintaining instance specific data storage instead of the application global data storage for normal VIs. Rolf Kalbermatter

This is really all about TCP IP routing tables and how they are setup. In your case using two exclusive subnet ranges the router has little problems to decide where a packet should go. You can easily influence the most simple routing by setting up according default geateway addresses for each interface so that addresses that do not match one of your subnets are all forwarded to a specific gateway such as a network router (or DSL modem). However once you have two different subnets that both can be default for certain adress ranges, not being the actual subnet itself, you won't be able to get things working right without explicite router tables. Setting up router tables in corporate network routers is a common task for network administrators but doing so in workstations is seldom done and in the case of Windows usally something to do on the command line. http://support.microsoft.com/kb/140859 might be a good starting point for that. Rolf Kalbermatter

SubVersion stores all file differences using a binary diff algorithme. And no, most diff utilities would not work when only getting the diff part from the repository. They usually need the full file for both the original and the modified version. Your guess that it only seems to return the binary diff part is quite likely correct. Why this is I'm not sure. It might indeed be a difficulty in setting up PushOK correctly to request the correct diffing result but I'm absolutely sure that this is configurable somewhere. Not using PushOK however I can be not of much help here. Rolf Kalbermatter

Sounds like a data corruption of your VIs and one I certainly haven't seen myself so far and most other LabVIEW users neither. So I really suspect something that is particular to your setup. Possible causes might be bad RAM memory or other hardware compenents such as slowly failing HDs. Another possibility which some people seem to underestimate is the fact that external code you are calling is completely free to overwrite memory that might be vital to LabVIEW and when you save back your VIs you might happen to save corrupted data. Unless you use self made external code (Call Library Nodes or CINs) or such things from not to official sources I would strongly suspect the hardware to be at fault. Rolf Kalbermatter

With LabVIEW 8 and 7.x too things are not as easy anymore. There is a lot that gets installed and a lot if it might be sometimes redundant but other times it can be absolutely crucial to your application. I guess NI had the choice to make this fully configurable with a 20 page dependancy chart that tells you which VI functionality requries which external module and which external module again depends on other external modules or create a more catch all installer system. The first choice would have caused a lot of documentation work, additional testing and such and prompted 90% of the LabVIEW users to complain that creating a LabVIEW executable installer is a pain in the a**. The other solution is simpler to deal with, needs less documentation, is MUCH easier to support for technical support, and costs a bit of media space. But with 500GB harddisks and 4.5GB DVD media currently that is a concern a lot of users don't even think about. As to VISA: No VISA32.dll is only a wrapper interface. The actual interfaces for the different VISA IO resources are in different other DLLs that need to be registered correctly for VISA32.dll to be found and there is at least one more VISA runtime support DLL that needs to be installed too. Also this does not include the lower level drivers such as NI-488, NI-Serial, NI-PXI etc etc which need to be installed too if you happen to use them and are usually part of a default NI-VISA installation too. And in order for you to configure the actual VISA resources at all you will want to have Measurement & Automation Explorer installed too, which is a rather big beast with quite some more dependancies. Rolf Kalbermatter

Hmm, I know having seen VISA returning me interface specific information. If I only knew where! I guess if you really want to go the Windows API route you will have to check into SetupAPI (no this is not pretty and an external DLL will most likely help faciliate that significantly) or you could try to look in the registry. A starting point here might be http://msdn2.microsoft.com/en-us/library/aa909922.aspx. 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