Rolf Kalbermatter

Well, Swap Words swaps the two 16 bit values in a 32bit value. It has no effect whatsoever on 16bit values (word) or 8bit values (byte). So you do not need to apply the Swap Bytes and Swap Words to each individual value but can instead put them simply in the cluster wire itself. They will swap where necessary but not more. Rolf Kalbermatter

Adam, you did miss in your previous post that the original problem was not about interfacing a DLL specifically made for LabVIEW, but about interfacing to an already existing DLL. In there you have normally no way that they use LabVIEW data handles! Your last option is however a good one. I was missing that possibility since the Pass: Array Data Pointer for Adapt to Type is a fairly new feature of the Call Library Node. It seems it was introduced with LabVIEW 8.2. And there is no pragma necessary (or even possible since the DLL already exists) but the structure is using filler bytes already to align everything to the element size boundaries itself. The void arg[] datatype generated by LabVIEW is not really wrong or anything as it is fully valid C code, it is just not as perfect as LabVIEW could possibly make it, but I guess when the addition of the Pass Array Data Pointer to the Adapt Datatype was done, that person did not feel like adding extra code to generate a perfect parameter list and instead took the shortcut of printing a generic void data pointer. Rolf Kalbermatter

I tried to report http://lavag.org/top...dpost__p__63616 as possible spam but got that error message. And earlier in other sub forums with other messages the same. Rolf Kalbermatter Admin edit: The report didn't make it through to the report center.

Why not doing it in C if you are so much more savy with that? Rolf Kalbermatter

Hmm looking at the data I wonder if you mixed up Little Endian and Big Endian here. Especially since all other LabVIEW flattened formats use Big Endian. The first four bytes making up Num Levels do look to me in MSB (most significant byte first) format which traditionally has always been referred to as Big Endian. Of course adding a new datatype you guys would be free to decide to flatten its data differently but the example would point to the fact that you stayed with the predominant Big Endian flatten format as used in all other flattened data in LabVIEW. And therefore byte reversing would by now be necessary on any platform except the PowerPC based cRIOs. As to the padding of Pascal Strings, this has been traditionally padded to a 16 byte boundary in the past but I guess that was in fact a remainder of the LabVIEW 68000 platform roots, where 16 byte padding was quite common to avoid access of non byte integers on uneven byte boundaries. Rolf Kalbermatter

You can sure report it but I'm not sure it would amount to a real bug. Most likely the ActiveX control does do something with the container if it is activated so the message you get is most likely technically correct. Rolf Kalbermatter

No, the LabVIEW runtime does not stay in memory, but Windows does something called application caching. Applications and DLLs once loaded do stay in a special cache that can be activated almost instantaneously on subsequent launches. Without this Internet Explorer would be such a pain to use that nobody would use it anymore. In the case of IE, Microsoft cheats even more as most of the IE engine is part of the shell that gets loaded when you startup Windows and the Explorer instance that displays the desktop. Rolf Kalbermatter

I want to see an NI marketing announcement where they do mention anything else but the advantages of their product over competitors (besides of a feature list and one or more enthusiastic user comments) ! Rolf Kalbermatter

No scripting license from NI for LabVIEW < 8.6 and I don't expect that to come really. You can get it to work on non Windows versions by copying some files and editing the INI file but on Windows there is no way to get it to work without helping hands from NI to get the right license file and as I already said I'm not seeing that happen anytime soon, and with the next version of LabVIEW being just around the corner the chances for that get even smaller. Rolf Kalbermatter

It's obvious you are not a marketing guy . What marketing guy would post both advantages and disadvantages in the promotion of their product? But it is definitely a very sympathetic treat. Rolf Kalbermatter

Well if you talk with them and really want to get 100 or multiple of that license packs, I'm sure Irene would be more than happy to give you a substantial discount. Of course claiming you will distribute 100 of apps but really only want 2 runtime licenses now, but with the 100 license discount schedule anyhow, is always sounding a bit lame. Rolf Kalbermatter

I'm the same! And I know I'm getting old, which is maybe the main reason for being that way! Rolf Kalbermatter

Yes my error handling goes back to LabVIEW 5 or maybe even 4. So no events there. Instead I have a FGV that uses occurrences to do the event handling. The FGV has a method to initialize it, a method to post an event/error from anywhere, a method to poll the FGV, and a method to shutdown. All those methods are wrapped in easy to use wrapper VIs that hide the complexity of calling the FGV completely. A compromised overview what each method does: start: create the occurrence, set the log path where all events/errors get logged, prepare the message buffer post: it has two wrappers one trivial one to just log system events, such as when the application was started up or when a configuration was changed/save or anything else that might be interesting to protocol but does not indicate any form of difficulty/problem or such. The other wrapper is the most complex as it actually does all of the error handling VI and on first execution adding custom error codes from *.err files in a central location. The FGV method itself does format and add the message to the message buffer, does the logging to disk, and sets the occurrence. query: its wrapper comes into its own loop on the main diagram that does use a wait occurrence to wait for an update, it also returns the contents of the message buffer as a string to display in a log string on the UI if desired. The most important thing it does is dsplaying a non modal dialog for all errors if the actual option is enabled. The dialog contains a checkbox to disable that option to prevent error dialog flooding. A boolean output indicates when the FGV has been shutdown to terminate the error handler loop too. shutdown: sets the occurrence and the internal shutdown flag so the error handler loop will terminate properly. clear: clears all internal buffers (optional step and not really necessary) The addition of this to any application is fairly easy. It just needs a tiny little loop somewhere in the main VI and the initialization VI being called at application initialization. The event poster can be added anywhere and the error poster comes everywhere one would otherwise use the NI Error Handler VI. On terminating I call the Shutdown VI and the whole application terminates properly including the error handler loop. Here is a use in a fairly simple application: Rolf Kalbermatter

If the application is ActiveX or .Net and has the ability to be used as container object (contrary to being an ActiveX/.Net Automation Interface which only provides a interface that can be accessed through Property/Method Nodes), then you can do it through the according container element in LabVIEW. Otherwise there is only an obscure possibility to make the main window of the process you want to embed a child window of the LabVIEW window. This requires in fact only a few Windows API calls, but this is a rather obscure way of doing business, there is typically no way to control the application in any way, starting up the application and embedding it into LabVIEW is an ugly process as the application will first startup as independant process through System Exec and then suddenly get forced into the LabVIEW Frontpanel, and last but not least, depending on non standard menu and window handling of such applcations it can result in strange visual artefacts or even inoperability of the (child) app. While it is theoretically possible, the most likely reaction you would get from your users doing this is a big: WTF!!!!!!!! Rolf Kalbermatter

I don't think it is as much a legal problem as it is a technical one. Creating a file formaat is not something you can legally prohibit. Only copying it could be prohibited but this does IMHO not apply here. However there are many aspects of a VI that are not accessible even through scripting, so you can not create a fully descriptive alternate file format. And reverse engineering the original format, while IMO an exercise in vain already, would be violating your LabVIEW license you accept when installing it. Rolf Kalbermatter

Based on what criteria? I guess one of the LabVIEW style guides would be a good read for you. There are also books like LabVIEW GUI: Essential Techniques from David Bitter and many more on Amazon or your favorite bookstore. Many posts on the NI site can be found too, like http://zone.ni.com/d.../tut/p/id/5319. A google search with "LabVIEW (G)UI Design" will likely give you more hits than you can comprehend and most importantly while there are good basic rules, what is a pleasant UI is also to some degree a matter of taste and we all know that taste is something that can not always be argued about. Rolf Kalbermatter

I think it is not even possible currently as the number of available scales seems to be a compile time thing. So no way you can do that on a running VI nor in a built application. Rolf Kalbermatter

Better would be even if that menu was in the front panel too and of course disabled for controls that do not have an event associated. But for now this is something only NI can do in their LabVIEW C(++) code. Rolf Kalbermatter

The UI thread is most likely the main thread that gets started up by Windows when the LabVIEW process is created. This thread then creates additional threads that are used for the different execution systems. The UI Thread is actually the thread that drives the Windows message loop. As such it is in fact responsible for distributing all Windows events to LabVIEW (Windows UI) and it is also the thread LabVIEW uses to draw to the screen for any and all of its windows (so it is the LabVIEW UI and the VI(s) UI too. Also some other things that need to be synchronized with Windows are done there and also anything the LabVIEW programmer assigns to that Execution System. LabVIEW is responsible to assign code fragments to the various threads and put them in active and passive state as needed. Windows does the preemptive switching between the active threads (and other tasks/threads in the system). Rolf Kalbermatter

The OpenG LVZIP library also contains a sub library called macbin. In there is a VI MACBIN Open Resource Fork that should allow openening the resource fork of a Macintosch file and use the resulting file refnum with the normal LabVIEW File IO nodes. At least that is how it did work until LV 7.1. Haven't tried that on newer versions. Rolf Kalbermatter

I very much doubt it. The Control Editor predates the VI server by several LabVIEW versions and it is a rather archaic piece of code. One of the original writers of that code has once stated that she felt rather bad that it was still in LabVIEW unchanged. Also newer controls do not always support customization by the control editor. In my opinion this all points to one conclusion. Accessibility of Control Editor functionality through VI server is not only not visible but likely almost impossible to implement. Rolf Kalbermatter

No, I do not think so. First there are no such things like DAQ thread, etc in LabVIEW. There is a DAQ Execution System and some others too, and each of them exists of usually 2, 4, 8 or more threads allocated at startup of LabVIEW. In newer versions the number of threads is even dependant on the number of cores the machine has. LabVIEW simply allocates those threads at startup and the OS provides them but the OS has no idea what they are used for. There is possibly one exemption which would be the UI Execution System with always only one thread and this is the initial thread that was implicitedly created by the OS when the LabVIEW process started up. This thread is priviliged in Windows terms in many ways as it is for instance the thread that is used to dispatch any Windows events to the application and many technologies like DDE, ActiveX and such in Windows rely on this thread being responsive in order to work properly since the synchronization (for RPC for instance for Remote control of ActiveX) is going through the message dispatcher. It's a piece in Windows that is in fact amazing to work and keep working over all the different Windows versions. And I have not seen any methods in LabVIEW that would return more specific information about the different threads such as the Windows Thread ID, which could be used to identify the different threads. Windows itself with the exception of the UI thread and that also only by implication, has no idea about what thread would be assigned to what execution system. Rolf Kalbermatter

Of course you have it if you have a recent Windows machine. How to use it I wouldn't know myself. As to the OGIC supporting SSL: Forget it! Implementing SSL is a very serious project in itself, with many implications. Doing that in LabVIEW is a complete nogo, not because it would not be possible but because of a number of other reasons, two of the most prominent are: 1) It is a huge undertaking that would require man years of work. 2) Encryption software is a difficult business that can only work if there is peer review by a broad community or at least by a panel of real experts on this subject, and guess what those experts wor mostly for profit within specific companies. The only feasable option would be to use an existing software such as OpenSSL and link it into LabVIEW. However the OpenSSL API is not really meant to be linked into a system like LabVIEW, requiring things like callbacks and such which makes an interface to LabVIEW a lot more complicated than just implementing some Call Lbrary Nodes. The easiest thing I have found to do (still not trivial) is to actually use an external application like putty to implement the SSL connection and then connect to it through the OpenG Pipe library from within LabVIEW. Rolf Kalbermatter

It could be that the Cleanup Tool does not know the inplace structure. In this particular case the inplace structure is completely useless anyhow. A simple Replace Array Subset will do the same with no performance degradation of any kind I could think of. Rolf Kalbermatter

The Call Library Node does not directly support to pass complex datatypes, resp. it does using the Adapt to Type but this passes an array as a LabVIEW handle which is absolutely not the same as a C array pointer. So you will have to trick this a bit. First configure the parameter as an array of bytes (8-bit integers). Then allocate a byte array of enough length with the Initiliaze Array function and pass this to the Call Library Node. The returned byte array can then be typecasted to a LabVIEW array of clusters and should after that be routed through a Swap Bytes and Swap Words node when you are on Windows. Alternately in LabVIEW 8.2 an newer you can use the Unflatten from String function (convert the byte array first to a string) where you set the endianess input to little endian, or even better native, host order, and the "data includes array or string size? (T)" set to false. With this you replace the Typecast and Swap Bytes and Swap Words. You will have to create a cluster that is compatible. For the char name[32] and char pad[3] you can NOT use a LabVIEW string but must instead insert another cluster of 32 resp. 3 8-bit integers. The get the length of the entire byte array typecast this entire cluster to a string and get the string length and multiply it with the number of struct elements you want to pass to the DLL function and then pass this value to the length input of the Initiliaze Array node. Rolf Kalbermatter