Leaderboard

Any control represents as many as 5 copies of the data. Default value -- the value of the control by default. Operate value -- the currently displayed value of the control. Execute value -- the value actually in the FPTerminal. This may update several times before the data is passed to the control itself unless Synchronous Display is enabled. Transfer value -- the value last moved from the FPTerminal to the Operate data. The transfer data copy is made by the executing thread so that the execution isn't locked by a transfer to the UI thread. Can't copy directly to Operate data since the UI might be in the middle of a redraw when the transfer occurs. Extra value -- created only when VI Server Value property or a local variable gets involved trying to copy the data back out of the control. The comments here are talking about the extra data.

http://current.com/items/90435278_russians-refused-to-shake-obama-s-hand.htm

ILFree() was an undocumented shell32 function since Win95 and Microsoft documented it after the big monopilist case they got into, which was I believe after Win 2000 was released. Those undocumented functions were exported by shell32 but not by name but only by ordinal instead. The ordinal number for ILFree is 155. And now the nice part: The Call Library node supports importing by ordinal. Just enter the number into the library name field. PS: ILFree is indeed just a wrapper around CoTaskMemFree even on older platforms. Rolf Kalbermatter

Paint.NET (Windows only) is a simple yet fairly powerful app. GIMP is the classic example, but has a higher learning curve and a UI which requires getting used to.

Ano, I don't have 8.2 installed anymore (and if you have any chance to upgrade to 9.0 you should so I haven't been able to test it. But here you go. No wrapper DLL's involved. BrowseForFolderG.vi

Look, a LabVIEW byte array (string) is like this: typedef struct { int32 len; uInt8 elm[]; } **LStrHandle; So you hav a number of problems to pass this as a C String pointer. 1) The actual character array starts with an offset into the real memory area. 2) The LabVIEW string is a handle (pointer to pointer) 3) Last but not least LabVIEW data can be "hyperdynamic". This last one is very important! LabVIEW reserves the right to manage its memory in anyway that makes sense to it. So if you create a string containing a set of characters, then run some magic like memcpy() (I prefer the LabVIEW manger call MoveBlock() for this) through a Call Library Node to get at the pointer that points to the actual string and try to pass that pointer to another Call Library Node to your API, LabVIEW might have reused, resized, or deallocated the original string already at the time your API is called. This in the best case could mean a simple Access Violation or crash or if you are unlucky a much less noticeable effect such as strange interactions with other parts of your code that operate with the reused memory, where your API now tries to write something into (or the other function reusing that memory writes something in and your API reads suddenly gibberish). There are tricks such as making sure the original string wire runs through the diagram without any branching to some place that due to dataflow dependency will execute after the call to your CLN API, to hopefully make LabVIEW retain that string memory until after your API executes. However while this did work in older versions, there is always the chance that by new and improved optimization strategies in newer LabVIEW versions, this suddenly might fail. The reason this works until now is that LabVIEW does not usually do diagram optimizations across structure boundaries, so if you run your string wire to a sequence structure border that depends on your CLN being called and finished too, you are nowadays safe. But if you just wire that string wire to the border without using it, there is a good chance that a newer LabVIEW version with an improved optimization algorithme might realize that this string is never used after your memcpy() hokuspokus call and suddenly the string is gone anyhow, at the time your API call tries to access the pointer that you retrieved with so much virtue from the LabVIEW string handle. Rolf Kalbermatter

You can not pass LabVIEW clusters containing variable sized elements such as strings or arrays to a C function. LabVIEW stores its arrays (and strings which are in fact just byte arrays too) very differently than what a C API function expects. So the best apparoach is usually to write a wrapper DLL with a function that takes the elements in the cluster as individual parameters and constructs the C structure to pass to the real API. There is in principle also a way to do it all in LabVIEW, but to be able to do that you need to know a lot more about C programming and its datatypes than you will need to write a wrapper DLL in C. Rolf Kalbermatter

Most likely you have the classical problem of C runtime library support. You are developing your DLL in some Visual C version such as 2007 and then distribute the DLL and your LabVIEW code to another computer than where you created it. Since Visual C defaults to link with the multithreaded DLL runtime library your DLL load will fail on a computer that has not installed the according Visual C runtime library. You can either use an older Visual C compiler that uses runtime libraries that are guaranteed to be available on all modern computers (I use for instance still often VC 6 for that reason, which creates DLLs that would even run on Win95 with any IE version installed. Another solution is to distribute the VC runtime distributables that come with your VC installation on all computers where you want to run this DLL on and the last solution is to change the compile time settings to use the static (non-DLL) version of the runtime libraries. This last one will blow up the size of your DLL a bit but will avoid exactly this problem once and for all. Not sure about your Waveform. You say there is no problem if you do not use waveforms but I would guess this has more to do about using specific runtime functions in the case when you use waveforms. Also the LVCluster datatype you show in your code example is not really aLabVIEW Waveform but simply a data structure. The native LabVIEW Waveform data type is as far as I know not document since it is a special form of LabVIEW variants which are nowhere documented in terms of their C interface. Rolf Kalbermatter