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

There is no way to fix that really as far as Windows goes. The reason is the limited file association based on file endings instead of Meta data as was used in the old Mac OS Classic Desktop interface. I think Mac OS X still supports that but they also went the path of basing most of the launching on file endings instead. The registry defines which program should be started for a specific file ending and obviously you can not really register more than one primary application for a single ending. The specific problem you see is that the actual launching of a file in an already launched application is done through DDE. The registry defines for the file type a DDE server name and an application topic and the Windows shell (the part that basically sits above the actual Win32 API and where the File Explorer is the UI of) attempts to contact the registered application through DDE and if that succeeds it passes it the file path to open. On failure it launches the registered executable passing it the file path as argument instead. LabVIEW uses the same DDE server name in all versions. You could say that this is a bug but unfortunately since the whole file association in Windows is based on file endings only and therefore a file traditionally only has one association there was very little use in trying to be smart and use versioned DDE server names. Recent Windows versions added a possibility to register multiple applications for the same file type but this is in fact at best a hack IMO. Microsoft itself does discourage to use DDE since about Windows NT4 for anything, although it is still the standard way of launching files into a running application. NI probably never has looked much into that anymore since it is both unsupported technology as far as MS is concerned and the registration of different LabVIEW versions for the same files would be mostly a hack anyhow as it is only a UI feature of the Explorer where you get multiple sub menu items under the Open right click menu. There is really no way to version automatic file launching for the same file type, simply because you can not do a 1 to n selection automatically. The Datact version chooser in my opinion would have a chance to do the right thing although it is by far not trivial. The solution would be, and I was under the impression that was what it did, to use VI server to launch the file in a specific LabVIEW version. There are a few difficulties with this. The first is that someone would have to configure the actually installed LabVIEW versions somewhere although I think VIPM is currently able to do that automatically for most standard installations. The second is that the VI server protocol did have a version chance between 6.x and 7.0 and there was a limitiation that only an old client could connect to a new server or vice versa (I'm not sure anymore which direction it went). The principle would be simple. When the user selects a specific version do launch a file in the Version Chooser it would try to contact that LabVIEW version over VI server (each installed LabVIEW version would need a different VI server TCP/IP port) and if that fails it would launch the executable and connect to it again. After that it would send the open command over the VI Server interface. Rolf Kalbermatter

In my case I have a big hole in the third from the bottom. Does that mean I never can make it better than "How can I pass-by-reference?" I think we could also have something like "Go with the (Data)Flow", "Looping forever", or maybe "Globals are Evil", "Modular Hierarchy", or "LabVIEW The Force". Rolf Kalbermatter

QUOTE (empstar @ Jun 9 2009, 06:45 PM) Sorry I'm not a magician and my crystal ball does currently not work . Translation: I have no idea! You could have not initiliased the camera correctly, your camera is defect, your driver not installed right, your computer flaky, the moon phase not in the right place, etc. etc. I can really not tell you more with the information I have. Correction: Looking at the original function prototype I see the parameter is actually a pointer to a pointer to a pointer!!!!!!!!!!!!!!!!!!!!!!!!!!! This can not be done in LabVIEW. A wrapper DLL written in C is the only solution here. Rolf Kalbermatter

QUOTE (empstar @ Jun 9 2009, 10:20 AM) Why use MoveBlock?? The data is there in the byte array already so no need to move that to someplace else. You just have to decode the array data correctly :-) Basically you want to Typecast that array in an array of 16 bit unsigned integers pass it through an Swap Bytes function to correct the endianess correction the Typecast does and resize it to a two dimensional array of 1000 by 1000 Then you also grab the subset from offset 2000000 (not 0x2000000) in the original array to the end and get there the additional array. Not pretty and certainly destroying some performance with it, but the alternative is to write a DLL wrapper in C which separates out those data parts into more LabVIEW friendly data types. Rolf Kalbermatter