Rolf Kalbermatter

Well, LabVIEW has a LOT of error information and much of it has gotten fairly descriptive over time. So part of the problem may actually be the amount of error information that is already there and that makes identifying areas that can be improved a bit hard. Also maintenance of all that information has to be a real nightmare by now.

Just try to open a connection and possibly run a simple query on it. The failure that results when the server is not available should be evident.

Calling the SetCurrentDirectory() Windows API with a path you do not mind to be locked. The issue is that the Common File Dialog function in Windows sets this to the current path whenever it is dismissed with an OK click. So yes it is really a Windows issue. It happens with other applications too, that use the Common File Dialog but you rarely run into that issue there, at least I don't. The actual API seems to have a flag OFN_NOCHANGEDIR that prevents Windows from changing the current directory if the user browses to a different directory during the dialog, but it is not supported before Vista. So NI still would have to inmplement a workaround around the Common File Dialog call, which admittedly shouldn't be difficult, but it may have implications in areas nobody is thinking about at the moment. The other issue with files being locked by LabVIEW that another application opened I'm flabbergasted. Never saw that happen so far.

Please be more elaborate in what you are asking. Which memory is provided by the system when calling a DLL? The memory where the DLL resides in? The memory passed to the function as parameter? Some other memory? What do you want to count?

LabVIEW really does some custom stuff here as it is not Windows common behavior and not even supported by Windows out of the box. I believe what LabVIEW is doing here is simply detecting if another instance of the same LabVIEW version is running (how that is done is another question, possibly a shared global variable in shared memory or such) and on detecting that sending all its command line parameters to the other application instance through DDE. At least that is how it was done in LabVIEW 5 and 6. The LabVIEW DDE server supports passing commands to its system topic since that is the means File Manager used to pass file paths to an application and it is still the way Windows Explorer passes parameters to an already running application when you double click an application file.

No this was definitely something like LabVIEW 6 or even earlier. With ancient I did mean ancient! I haven't even started to do real project work in LabVIEW 2009 yet.

I believe that in order to start and stop a service you need to have administration privileges in Windows 2000 higher. Windows Vista and higher might even require specifically elevated privileges that an administrator account doesn't automatically grant to an executable, but requires an additional explicit User Authentification as administrator. It would be strange that CMD.EXE itself is requiring elevated privileges but it is the service manager start and stop command you try to execute in CMD.EXE that is barking on the to low privileges you have as normal user. .Net can't circumvent the privilege level control for the service control manager but it might have extra support to allow temporary privilege elevation for the current executable for execution of service control manager commands which would require at least the according admin login credentials somehow (and if they care about security it won't be a programmatic login but an interactive login).

I've seen that happening in the past with some application a few times. Not sure what was the fix as it is quite some time ago and involved an ancient LabVIEW version. I guess moving up to a newer LabVIEW version was the fix for that for me.

Yes the flattened data only contains the actual variant part of a control and not its invariant data type information at all. The Unflatten from String did not really take a type descriptor as it also needed to know the final data type at edit time. The Flattened String to Variant does take such an input but the entire type descriptor business got internally completely redesigned with LabVIEW 8 to avoid the problem of the 16 bit size limit for old style type descriptors and NI decided at that point that they are not going to expose the new 32 bit safe type descriptors to the LabVIEW diagram in any way. The old 16 bit type descriptors are still exposed since they are used in the OpenG Variant tools and many other projects but do crash on type descriptors exceeding the 16 Bit size limit.

Please post such questions in the future in the applicable section (External Code). The LabVIEW application Builder recognizes DLLs as dependant files and includes them into the build when creating an executable. The OpenG Builder might not do that. An additional feature of the LabVIEW application Builder is to also adjust the location of the VI Paths AND DLL Paths in the compiled version for the build application which the OpenG Builder might also not do for the DLL Paths. There is certainly a possibility to improve the OpenG Builder to also care about DLLs properly but that is not for the faint hearted. Once LabVIEW does not find a DLL where it expects it to be it tries once more in the directory where the project file is located (obviously not applicable for executables) and then simply passes the request with only the DLL name to Windows and then the standard search criteria of Windows apply: 1) already loaded into the application memory 2) the executables directory 3) the system directory 4) the windows directory 5) any directory mentioned in the PATH environment variable So your options would be several depending at which stage you want Windows to find your DLL. 1) Create a specific loader VI that locates the DLL and loads it into memory and also stays in memory and is run before your driver is loaded 2) - 4) copy the DLL in the according location 5) modify the PATH environment variable to point at the location where your DLL can be found

RTFM or in this case the online documentation. It is written in there for the table control.

Another problem I have seen repeatedly with people complaining that the constructor is not available in LabVIEW is when they try to use static objects. That are objects that do not need nor can't be instantiated to work since they do not hold onto any local data for their operation. For instance mathematical function libraries that always take all their data as method parameters. LabVIEW simply allows to call static objects by selecting them into a refnum and then selecting the methods for those objects in a method node.

You could help potentially others who might use the search function before posting, by posting an explanation of what caused your problem and how you resolved it, rather than just posting that you solved the problem. This last information is more or less meaningless to everyone here as it is not our problem so if you solved it or not has little importance to us, but how you solved it may be very interesting and helpful to others.

Knowing a bit about production quality insurance I think you are right that he did the work mostly on his own time, but that committing it to be part of an upcoming release, takes usually a multiple of the time, the actual development took. I can add most features to software in a very short time, but having them tested, documented and tested again, takes usually up a multiple of the time that was needed for the actual development of the feature.

While there is no consistent implementation of refnums in LabVIEW there is one specific thing an LVRefNum has always been, and most likely stays in 64Bit too, and that is its implementation as a MagicCookie as shown in the LabVIEW CINtools headers. Here you can see in extcode.h typedef uInt32 MagicCookie; completely independant of the bitness of LabVIEW so it seems to be a safe assumption for now that the data part of refnums correspond always to a 32Bit value. There is of course a wrench with this, since the so called Tag based refnums, like VISA, DAQmx, etc refnums also consist of a string part identifying the actual resource a refnum refers too, but even those refnums use internally a MagicCookie too.

LabVIEW doesn't tinker with TCP/IP options a lot. It sets everything that is needed to make asynchronous sockets work reliable and leaves the rest at whatever the OS chooses to create a socket with.

I wonder if the LabVIEW General board should be locked for newbies to create new threads in. Almost everybody seems to post nowadays only there creating a long stream of completely unrelated topics in it, while most of the topics clearly belong into one of the sub threads in LabVIEW (By Category).

Why is everybody posting into LabVIEW general nowadays. This and most other topics here are clearly posts that should have been placed in the relevant thread under LabVIEW (By Category)! Just because it doesn't crash during debug run does not mean everything is right. The symptoms you describe clearly point into one of these directions. 1) You have setup an output parameter (a buffer parameter where the DLL function is supposed to write data into, such as an array or string) but forgotten to allocate memory for it before passing it to the function. While LabVIEW's automatic memory management takes care of everything as long as you stay in LabVIEW, there is no way for LabVIEW to know how big a buffer it should preallocate when calling a C function. Therefore it doesn't and relies on you to do so. You have two options here, in LabVIEW 8.5 and higher you can define the minimum size of elements LabVIEW should allocate for such a parameter in the CLN or you can do it explicitedly by using the Initialize Array function. The reason it doesn't always crash is that by not allocating (enough) memory for the buffer, the DLL function will write into some memory area anyhow. This can overwrite information that is vital to LabVIEW but sometimes also information that does not immediately lead to a crash. In an executable most diagram and other information removed and only the runtime data remaining, chances are higher that it will touch vital data so a crash is more likely but that is not a rule. It can also be opposite, or depend on the moon phase or anything else rather esoteric . 2) You configured the parameters not quite right. 3) You pass data to the DLL that trigger a bug.

Calling C++ functions gets nasty if you have several variants of the same function with different parameters since you have to figure out which decorated function name you want to access for a particular parameter version. And the decoration while logically corresponding to the parameter list, is anything but easy to decipher (and varies between C compilers too). Accessing methods and member elements of objects will only be doable with C wrapper interfaces though.

All the types ending in numbers are LabVIEW platform independent types defined based on precompiler macros in extcode.h or actually more exactly fundtypes.h included in extcode.h. Aside from the already mentioned short and long types and the signed and unsigned type specifiers he is also missing char. Also the int is not as the list would indicate equivalent to an int16 but really an int32 in any version of LabVIEW. int == int16 was only true on 16 bit compilers. Other variants that do exist are long long (except Windows which uses an internal type _int64) which is int64 and long double which corresponds to extended floating point format on platforms that support it (again with exception of Windows which has no compiler built in type for extended flaoting point). Basically; char == int8 (or sometimes uInt8 if the compiler treats char as unsigned byte, sometimes also possible to change by a compiler switch). short == int16 int or long == int32 long long (on Visual C: _int64) == int64 single == float32 double == float64 Basically parsing C types is quite a complicated business since various compilers do not understand exactly the same for certain types. So LabVIEW header files (and many others) have various definitions based on precompiler definitions that are defined by a compiler directly or through project settings and other included header files. So your parser should be able to define built-in defines to simulate a certain compiler to be able to process C header files. And since C headers usually include other C headers, it needs to handle embedded includes too. Of course if the idea is only to allow a C like definition of types rather than processing existing header files then the task gets a lot easier and you can define whatever subset of the C syntax you are comfortable with to implement.

My experience with logging lots of events is that it is almost impossible to find the interesting needle in the haystack. Logging events and especially errors should be normally the exception, not the rule, otherwise you can just as well throw them away anyway, since nobody is ever going to try to look at the log.

While I understand the reentrant advantage I'm not sure that is such a big deal here. I use a similar error/event logger scheme as yours (from like written 12 years ago or so) (and yes I wanted to redesign it a few times since but it just sits there and works so the need never really pressed itself upon me). In general if you happen to have an application that produces errors so fast that the non-reentrancy of the AE starts to be an issue, of course assuming that you did decouple the actual action properly, then I feel one has a much bigger problem to solve than the possible blocking of other threads by the still busy AE from earlier errors. That said I use the same silly AE based event/error logging system on all my systems including RT apps.

I see no connection between your first post and what you reference here And while LabVIEW PDA supports Mobile and Windows Mobile is the successor to Windows CE, I indeed doubt that LabVIEW PDA goes as far as supporting CE releases. And your original problem of not being able to install a new Windows CE release onto your smart phone points much more basic problems than being able to run LabVIEW applications on it. Sorry.

Wouldn't count on that. In the begin days of the password protection they did that sometimes but after some time they cleanly discontinued that service for all and everyone, because it was unmanageable, unmaintainable, legally very questionable (how to proof that you are the one owning the copyright to it, etc). and simply a to big support burden. Would be surprised if they came back from that decision since. Of course if you do know someone at NI and know their weak spot the above may not apply.

How big is your number then? As you can see 66 years (1970 - 1904) corresponds roughly to 2*10^9 seconds. From your 300 year difference I would guess you are not getting the number of seconds but rather something else such as the number of ms, since that ominous 1970 date.