Rolf Kalbermatter

The LabVIEW key handling will definitely not be based on DirectX access but directly work on the events returned by Windows in its internal GetMessage() loop. I haven't seen such an issue yet, but I'm not using Macs much, and definitely not with Parallels. I do use Virtual Box quite regularly but with a Windows host and Windows and Linux guests. Would love a Mac guest too but that is just to much trouble to get working reliably. And those VMs sure can do some weird things when passing down events and other stuff to the guest OS. For instance I can reliably crash my computer completely and without even any BSOD if I startup the Windows 7 64 Bit VM and my host Windows system has been operating for quite some time. After a fresh restart of the host it never crashes.

This thing doesn't exist and would be more or less impossible to compile as there are potentially many differences between LabVIEW versions. Basically error handling is best done on the principle, that if there is an error and it is not a very specific error you know about to be a legitimate error result in this particular situation (e.g. timeout when communicating with an instrument or over network) you should always assume a real error and bail out in one way or the other. Code that does extensive if (error == xx) else if (error == yy) is always going to be a pain when upgrading to a newer LabVIEW version (or just installing a new IO driver too) since these error codes can sometimes change (when for instance more descriptive error codes are introduced). That is my principle anyhow, maybe there are others, but I would consider them to be unmaintainable over a longer time. My code often does suppress timeout errors in the error cluster and detects the timeout case and then simply goes back into waiting for the next message. Also when you do network communication, you have besides timeout also other errors such as connection closed by peer, or similar, that are real errors in term of the communication link, but most likely should be handled explicitly by your protocol handler by closing the connection and reconnecting to the peer, without causing any error report to the higher hierarchy of your application. But in general unless you know a specific error should be handled in a certain way, you should treat any error as a simple indication to bail out and prompt the user or log the error or something.

Well you are right that Flatten Variant doesn't work. I was mislead by a quick trial and had no time to verify further as I had to leave for private obligations. However I can't accept defeat so I remembered another post where someone wanted to have an VT_NULL Variant and investigating into the solution I have come up then showed an easy and totally official way to do it. The VARIANT memory layout is fully documented on MSDN and the LabVIEW Call Library Node supports explicitly the ActiveX Variant type. So simply passing the Variant as ActiveX Variant pointer to a C function that looks at the first two bytes in the structure is all that is needed to get at the VT_ values. Enclosed are the VI to create specifically a VT_NULL variant and the VI to read the VT_ type. I haven't entered the entire range of VT codes into the enum and since those codes are in fact not continous it is probably better to use a Ring control instead but that is an exercise left for whomever is wanting to use this VI. Get OLE Variant Type.vi NULL Variant.vi

I haven't really the time to look at this right now, but I think Variant to Flattened String would allow to do what you need. Basically it returns as type for ActiveX variants the value 0x84 and then another int16 that is the actual VT_ value. So it should be not to difficult to extend the OpenG Variant tools to also be able to identify the subtype of ActiveX Variants.

I was thinking about creating both a 32 bit and 64 bit DLL but would like to keep one VI interface only. A fixed always 64 Bit integer would probably work except that it is not a normal integer but really a distinct datatype that should not be connected to anything else. The enum inside a datalog refnum abuse is a nice trick to ensure this, yet most refnums in LabVIEW (except the user refnum) are always 32 Bit entities so that would be not an option. I also need to pass out some kind of refnum to manage the message hook throughout the program. In practice this is the HWND of the hooked window too, but since this refnum is only supposed to be used with functions from that library there are several ways to deal with this in a transparent way as the user does not need to be concerned about what the refnum really is. However in the message structure I do not have that luxury. The only reason for it to exist in there, is to allow a possible user of the library to use it to do something on Windows API level with it and I have no intentions on providing any wrappers for any Windows API calls to work with a private version of this refnum. It may be a always 64 Bit sort of hack really that will be done similar to what LabVIEW does when dealing with pointer sized variables.

As I'm working on the sidelines on this I run into a difficulty. Windows handles are really opaque pointers and as such they are surprisingly 32 bits on Windows 32 Bit and 64 Bits on Windows 64 Bit. This is a bit of a problem as the original Windwos Message Queue library contains a Windows handle in its data structure, as it completely mirrors the MSG structure used in the WinAPI. There seems to be only one datatype in LabVIEW that truely mimicks this behaviour and that is the so called user refnum. That is a refnum that is defined by object description files in the LabVIEW resource directory and as such not documented at all. So the question is now, does anyone know of another LabVIEW datatype that is sure to be truely pointer sized when embedded in a cluster or alternatingly is there any objection to not include the Windows handle in the message structure?

You can't do that. The OS condition is meant to be a fixed value that depends on the selected target and nothing else. Allowing to override that would allow to cause all kinds of obscure troubles, as surely there will be people trying to click around in their ignorance. It seems you will have to revisit your software and change all the conditions into something that depends on a customizable project property.

Extra complication: The function may expect the array to be allocated by the caller too. If that is the case can only tell the documentation to that function. C is simply not detailed enough to describe the finer semantics of parameter passing.

The executable as is certainly won't run, since it is compiled for the x86 CPU whereas all WinCE devices I know of use some sort of Risc CPU. The PDA Toolkit would allow you to convert the LabVIEW VI into an executable for the WinCE platform. The way this is done, is basically that the PDA Toolkit contains an addition that creates specific WinCE C++ source code that then gets compiled into an executable by the also installed Visual C for WinCE cross compiler runtime, that NI has licensed to distribute with the PDA Toolkit. However the PDA Toolkit is not very well supported as it only supports fairly old versions of WinCE and I doubt NI will invest more time and money into it. The real killer is however probably that the IMAQ Toolkit contains native (compiled) code components in the form of shared libraries and is only available for Windows OS on x86 and x64. No other CPU nor platform, be it MacOS, Linux, WinCE, or whatever else you can imagine is supported by the IMAQ Toolkit.

Windows message hooks don't just "monitor" the message queue, they hook it. This means if anything in the hook does not respond properly, depending on the type of hook, the application in question can get completely locked up. Even in modern day multithreading and multitasking Windows, anything UI oriented goes through that message queue (and a lot of other things like OLE data marshalling, which is used by most ActiveX components too).

And here you are wrong. There is no message hook in LabVIEW or any application necessary. It's the event loop at the core of the application with GetMessage() that receives these events and then distributes it. And messing at that level with events is for sure going to open up a myriad of possibilities to lock up your application from the diagram completely. And a Mac application has yet another rather different type of event loop. And if they change that to work with Cocoa instead of Carbon, which is a prerequist to make LabVIEW work as 64 Bit application on the Mac, since Apple dropped the Carbon support for 64 Bit completely for anything UI related, then that is again a VERY different event paradigma. Not even starting to talk about X Windows events, which are very powerful, and at the same time VERY easy to break completely with different windows managers. There simply is no way at all to provide an interface to a message hook like functionality that is working on all platforms in the same way, does work uniformly on various platform versions, and supports the full power of message hooking of the platform. The best there is would be to extend the event loop to give more access to certain low level events like mouse move, common system management events like power saving events and such things but in a true platform independent manner like other LabVIEW features. Integrating native platform events into the event structure is simply a no go in my opinion. Such a core object like the event structure should not make an application break on non Windows platforms when being loaded. And message hooking is tricky at best and can easily create dangerous situations where you can lock up your application in very interesting ways that are almost impossible to debug without C source level debuggers.

The problem with this is that it needs to be working on all platforms if NI integrates it into the event structure. And that part is really not easily mapped into a generic scheme. Of course NI could implement just about all 500 Windows Message events and its 2000 variants of it in the event structure and try to find according X Windows and Mac OS events. But that would make the event structure absolutely unmanagable and it would still not cover the issue when you need to interface to software that uses windows messaging for interapplication communication. So a lot of work for little benefit, and that is a true killer argument for anything.

Not with the Windows Message Queue library as is, but the use of LVPostUserEvent() as mentioned by ned would certainly make that easy. I'll see if I can have a go at it. It would in fact simplify the DLL part enormously, since the whole queue handling in the C code can go away, as the user event will handle that internally.

What type of installer are you talking of? Is this an installer for a build app, or an installer for a development library? In the first case you normally don't have anything like vi.lib etc anymore since all the necessary VIs are packaged into the executable anyhow. In the second case you really should look into using VI Package Manager. This is the prefered way to distribute development libraries nowadays. Best would be probably to create a package for individual instrument drivers and create one or more other packages for your library and make them depend on the instrument driver packages. I find it troublesome to package everything into one big blob, if they are not very closely related to each other.

While using an external solution such as Windows authentication is sometimes an option it doesn't automatically solve most of the problems. If you intend to not just call a Windows login dialog itself, you still end up having the password in cleartext in LabVIEW anyhow, so most of the concerns still apply. And (ab)using Windows authentication for your own application is not as trivial as it may seem. There are differences about local logins and domain logins. While you can issue domain logins fairly easily using directory services, this proofs very difficult for computers that use a local authentication scheme or don't have cached domain login credentials and have to use local authentication as fallback. I have tried with .Net to get there, but the only way that works reliably both for domain authentication as well as local authentication is using a VERY involved Windows API interface, that I came across by accident somewhere. And it requires an external DLL, as the Windows APIs involved are really complicated, and need to be able to adapt dynamically to various availability of APIs, depending on installed Windows version and feature set. And then you are still screwed if you need to go non-Windows.

Industrial computers are usually more ruggedized and less state of the art. This has several implications: - They can operate in much less friendly environments. Normal desktop computers are not really designed to work in a dusty, oily, or high temperature environment at all. - Not using the latest hardware chips also means that standard drivers are much more likely to work out of the box, without requiring regular updates to various drivers to remedy crashes and other nasties. - If you have a 19" rack anyhow already, they integrate nicely into the setup whereas a standard desktop PC always will stand somwhere aside and use up space, standing in the way, or just laying ad hoc in the rack, possibly falling over or out of the rack. - The extra costs are usually negligible in anything but the most low cost hardware setup in comparison to the rest of the hardware and especially software application.

You need to also close the front panel as last action after the VI is finished and make sure you don't hold on to VI references anywhere too. A VI is kept in memory by either an open VI front panel or an open VI reference (that can be managed by the VI itself, either by opening such a refnum explicitedly or by passing refnum ownership to the VI when you launch it with the Run method. Once the last VI has left memory a LabVIEW application will terminate itself. If it doesn't you have either still open a VI somewhere, maybe as hidden front panel (hidden does not mean closed) or are most likely stuck in a synchronous call to external code, such as a DLL call. And here Quit LabVIEW can't help either as Quit LabVIEW has not have any more powers than the Abort button, and that one can't terminate stuck external calls either. Here a task kill is the only solution if you can't somehow persuade the external code to relinquish control back to the calling LabVIEW program.

Consider the abort button as a synonym to using a concrete wall to stop your car with. It works but can have undesirable effects!

While it seems like a bug, I would like to point out that "Quit LabVIEW" is almost never the right thing to do. If you build an application, this application will normally quit as soon as the last LabVIEW window is closed, either through the button in the right upper corner, or through a property or method node to close that front panel. You also need to make sure that you haven't somewhere hidden front panels but this is simply proper application development. Quit LabVIEW will tear down everything wherever it is and is similar to the abort button in the toolbar. While the abort button has some merits during debugging if you get stuck somewhere (and haven't locked yourself out by a modal dialog) the Quit LabVIEW node is always a runtime operation and designing the application to simply make sure to close all front panels when it should quit is much cleaner and allows the various possible VIs, including deamons running as hidden top level VIs to properly close down and release whatever resources they may have allocated. In the development environment Quit LabVIEW is a terrible thing! It will shut down LabVIEW which is never what I would want during development.

1) Is very difficult to maintain as LabVIEW does all the memory management automatically behind the scenes. In theory data is often reused but in practice LabVIEW tends to hold onto data if that wire doesn't get modified. So this would mean that you should definitely overwrite any wire that contains a password as soon as that password is not required anymore. And this would have to be a function that does some inplace operation to set the string contents to all spaces or something by checking the current string length and overwriting its contents and this VI needs to be designed in a way to make sure it operates inplace, so it should have a string input and output terminal and the string should be wired through in the top level diagram, so no terminals inside a case structure or something. Also all the VIs that operate on the password string to for instance calculate a hash, should be designed in the same way, with a password input and output and placing those two controls in the top level diagram and wire it through any case and other structures that may be there. If you use loops, make sure to wire it through a shift register just to be sure. 2) Is impossible in pure LabVIEW as at least the UI to enter the password will always contain that password. The Password display option does hide the password but doesn't change the string content in itself. So if you have access to VI Server AND know the VI name of the password UI AND the name of the control AND VI Server is configured to not disallow access to this VI you can get at the clear string at the moment it gets entered. Seems to me like installing a keylogger is a much more simple and universal way though. The key to solving 2) is in controlling what gets served by VI Server if any. A good approach would be to name all VIs that are supposed to be accessible through VI server with a specific prefix and then setup VI Server to only allow access to VIs with that prefix. Of course this means that your application INI file needs to be secure, but hey if that isn't the case you have many more serious troubles already. NOTE: An interesting tidbit: Try to make a string control to display as password display and then enter a string, select it and do a ctrl-c. Paste it someplace else! No joy, at least in more recent LabVIEW versions (checked it in 2010).

I didn't know either until I was going to look for the link to add in my post. My experience is with the older RTAD too and it worked fine.

That's only a feasable option if you have full control over the font used. If you plan to distribute the app to other computers, even if you are able to control their configuration completely up to what fonts get installed and what fonts LabVIEW defaults to, it's definitely a lot more hassle than you care to ever have.

You could also use an array of bytes to encode binary data, although it is a little more verbose than a base64 scheme stored as string. Unfortunately JSON does not seem to provide a standard for encoding numerics in a different than the decimal base. Or since a JSON string is actually 16 bit Unicode, you could encode it as a string of "\uBEAF\u1234\u.....". Still more verbose than base64.

Well as long as the API call doesn't run into an error, there is in fact not much which can go wrong in an application, depending how you react on the error output of that VI, of course. But likely you haven't really done anything with that. And the changes that GlobalMemoryStatusEx() encounters an error are not that big, respectively if it does you are likely to be in more serious problems already, than that worrying about the GlobalMemoryStatusEx() function return value will make much of a difference.

NI often seems to be a bit conservative in their estimated shipping dates. I remember my last cDAQ project where I needed 4 cDAQ-9181 and some modules. The cDAQ-9181 were quoted with 10 days delivery time on the website, when I ordered I got a call that they had production problems with getting some necessary parts for a production run and they estimated a shipping time of about 2 months later. You can understand my surprise when I got the product about 2 weeks later and it fully worked! It's all doable if you have access to the host itself. There is a Real-Time Deployment Library that allows to build in code into the host application, that can update, reset and restart a realtime controller from the host application at runtime. No need to have access to the cRIO over internet or to a LabVIEW development system on the host for upgrading the realtime part.