Rolf Kalbermatter

I have not looked at your VIs but this sounds like a familiar problem. LabVIEW does so called garbage collection on any and all refnums. The way this works is that as soon as the top level VI of a hierarchy, which created somewhere a refnum by opening an object, returns to its idle state, the refnum will be deallocated. So trying to store that refnum in a global to be used in another VI later on is simply bound to fail. By invoking your initialize routine over VI server from a separate VI you get in fact this situation. Another possibility is that by opening the refnum to your manager VI and closing it afterwards you really remove the entire manager hierarchy from memory and that should cause LabVIEW also to close refnums allocated by those VIs. You will have to make probably some modifications to your architecture to create a deamon of some sorts which is both responsible to load/unload the managers and also relays the execution of those managers to the interested clients. Your deamon must be running in the background as long as you want to make use of those managers or refnum objects created by these managers. Rolf Kalbermatter

I think this is a nocando even if you digup to your armpits into LabVIEW scripting. The context help is not yet included in the LabVIEW scripting object hierarchy and the context help window directly retrieves those text informations from the internal LabVIEW resources based on an ID of the object the cursor is on. This could only be solved currently by directly going into the LabVIEW source code and add an extra hook to the context help window. Rolf Kalbermatter

This VI calls directly into LabVIEW to call an internal C function. There is absolutely nothing you could learn from this VI other than that using a Call Library Node and entering "LabVIEW" in the livrary name you can directly call all exported LabVIEW manager functions. It is also this feature NI considers secret although they did forget in the past to protect a VI or two so the secret is not anymore secret. For us non NI people this is really limited to the functions documented in the External Code Reference manual but LabVIEW exports a lot more functions although without documentation, trying to call them is a 99.99999% chance of generating access violations and having to restart LabVIEW to continue. And no, don't expect NI to document those functions, a lot are only there for historical reasons, quite a few have probably quite a lot of undesired side effects if not called in a certain context or way and last but not least they cover areas very likely to be affected in the future by adding support for new platforms and documenting them would make it almost impossible to modify them when the need arises. Rolf Kalbermatter

Not all good things come for free ;-) But if your requirements are not that complicated you could probably get away with calling a command line tool for your favorite CD burning software through the System Exec.vi. Most CD burning packages come with an executable you can call with command line parameters to make it do certain tasks such as copying one or more directories to the CD, etc. How this is done is entirely dependant on your CD burning software and you will need to refer to your manual or online documentation or research that on the manufacturers web site. Unless your time does not cost anything I would however expect the price of that Toolkit to be less expensive than to even try to get your own solution working. Rolf Kalbermatter

In the icon editor category: If you have entered text and before you select another tool use the cursor keys to move the text around pixel by pixel to make it center nicely etc.

Theoretically you could try to interface to the Microsoft Office spell checker. At some point Microsoft did document how to do this, first by calling directly into the appropriate DLLs and later by interfacing to the Active X interface of this component. I'm not sure about the current status although I would assume that they do not promote it anymore or at least expect you to go into a license agreement with royality payements to be able to do that. Besides if Active X is the only supported interface nowadays expect to run into lots of versionening issues with different spell check libraries from the different Office packages.

I think you made a significant mistake in the calculation as you did not take into account your current time zone offset. I am not entirely sure this calculation holds true either but the result of 2082840000 would be more appropriate assuming both reference dates are supposed to be GMT which in general is the right thing. If you calculate the the quotient and remainder from this number with 86400 you get a quotient of 24107 and a remainder of 0, indicating that there are indeed exactly a full number of days in between. Attached is the diagram of the VI I used to calculate that offset. This should be independent of the time zone you are in.

Well, I think it could be an interesting project, but I also think it is a project about the size of Comedi or similar. As such it will be a long time before there is something which can be used for serious applications and it always will require tinkering of some sorts to get it working on a particular system. While directly calling into the OpenCV shared libraries will probably allow you to have something working fairly fast it will proof in the long run to be disadvantagous and quite a bit of a hasslle to maintain. Last time I looked at that it seemed to me almost unavoidable to develop yet another intermediate shared library which takes on the task of translating stuff between the OpenCV environment and LabVIEW. And then you shouldn't forget that there is already IVision from http://www.hytekautomation.com. It does exactly what you are more or less trying to reinvent (though it isn't really free for professional use). This leaves even fewer people interested to spend an enormous amount of time for such a project. Most professional users will prefer to use IMAQ because it offers support, and a known communication partner to talk too. The few professional ones feeling IMAQ to be to expensive will probably go with IVIsion and then you are left with the ones doing it as a hobby or being in education and that usually turns out to be not enough to carry a project of this size and complexity (Call Library Nodes, C programming) for a longer time. Rolf Kalbermatter

The path in a Call Library Node should be fixed up by the application builder automatically when building the executable. Basically if the DLL path is absolute AND points outside of the Windows or System directory the application builder will automatically add the DLL to the support file group which gets into the data directory by default. The Call Library Nodes in the executable will be adjusted accordingly to search for the DLL in that directory first. The problem is if you use a relative path, which LabVIEW for some reasons does turn into an absolute path always but still remembers that it is relative it would seem to me. Then LabVIEW will search the directory where the VI containing the Call Library Node resides. If that doesn't bring anything it will pass the request to the OS which under Windows will search the directory of the executable asking for the DLL (e.g. the build application or labview.exe in the development system), then the Windows and System directory and last but not least any directory in the PATH environment variable for the current user. All DLLs to be found in the windows or system directory are NOT added to the application build. Rolf Kalbermatter

That's because the DLL does NOT expect a LabVIEW handle or even a pointer to such. Instead it expects a pointer to a C string. char somevar[] is equivalent to char *somevar as far as the C compiler is concerned. This is definitely a C string pointer. Configure the Call Library Node parameter accordingly and you should be fine. A LabVIEW string handle or pointer to such can only ever be used for DLLs which have been explicitedly developed to be called by LabVIEW. Rolf Kalbermatter

No, and without wanting to sound bad, I think this would mean that nobody except a LabVIEW programmer at NI might know if it is possible at all. I personally doubt it. Rolf Kalbermatter

This really depends on the version of LabVIEW you have. LabVIEW 7.0 and higher has a property FP.Behaviour which allows setting this at your whim directly. Earlier LabVIEW versions do need the Windows library, unless you have LabVIEW 6.1 and play with the ini file in ways as described in the scripting section. Rolf Kalbermatter

The only option would be to create an array of clusters with one array in them. However that is a rather inefficient way for LabVIEW to store data. If your arrays can get large expect a serious slow down of your application. Also wiring such data structures can get rather messy very fast since you need to have all those Index Array, Unbundle, Bundle and Replace Array nodes all over the place. You probably would be best of rethinking your strategy of storing the data if your arrays can get larger than a few 100 elements. Rolf Kalbermatter

While LabVIEW only opened 1 thread per execution system before version 7.0 it does in version 7.0 and higher open 4 threads for each execution system except the UI system. And that means that LabVIEW will switch to other threads when one is tied up by an external call to a reentrant DLL, reentrant CIN or an Automation server. The problem with Active X is a different one. First Active X can either be a control or an Automation server and sometimes both. A control is placed in the Active X container and inherently opened by this control. A control executes ALWAYS any method and property node in the UI thread for safety reasons. An Automation server is always opened explicitedly through the Automation Open function and does not incoporate a user interface as far as LabVIEW is concerned. Those nodes CAN be called in the actual thread but only if the Automation server is marked as multithreading safe. Most Automation servers however and almost all Active X controls require Apartement threading which means the Active X control or automation server must always be entered from the same thread to work properly. In LabVIEW 7.x this is a problem as LabVIEW might enter into an Automation method or node from any of the 4 threads assigned to an execution system and if you even happen to manually assign different execution systems to different VIs, calling methods or property nodes of the same Automation server control, LabVIEW even in version 6.x has absolutely no way to avoid disaster. So LabVIEW seems to call those Automation servers from the UI thread too which is the only safe thread system to guarantee what the Automation server object told LabVIEW it would require. Solutions are: Since only the UI thread is really locked the rest of LabVIEW diagrams will actually continue to execute. No updates on the user interface will occur though and calls to non reentrant CINs and DLLs will also block here as they are also forced to execute in the UI thread. So the processing of your application really doesn't need to be affected unless you set front some panel controls to update synchronously for whatever reason as that will force the diagram to wait until the UI can be updated. IMO1: employing a hardware dongle protection will cost you more money and user credit than it can ever return in additional sales for typical LabVIEW applications. You really need to sell 1000s of copies of an application to even remotely justify use of dongles. IMO2: Using Active X for this kind of thing is the worst choice one can do. It is a very complicated technique which adds an extra layer of point of failure you will have to support in your future users environment. And believe me end user support for dongle protected applications is always a very significant part of your support cost. If I would use dongles, which I probably never will, I would simply call into the DLL provided by the dongle manufacturer using the Call Library Node. This adds as little complication to the entire system as is possible and will minimise your support significantly. Rolf Kalbermatter

It depends on your LabVIEW version. Inport an Outport since LabVIEW 7.0 can also run on a NT based system. Before LabVIEW 7.0 you had to install an accesshw.zip library you could download from the NI Developer Exchange. You might also want to try the portIO library from OpenG. You can download it using the OpenG Commander. Rolf Kalbermatter

Greg McKaskle, yes the famous one, has mentioned on InfoLabVIEW some time ago that he has a string based math library which can work with arbitrary size of numbers. Since it is string based I would guess it is not for performance junkies, but it has no other limitation in number format than what the computer can provide on memory. I think he offered this library to interested people and he may even have put it up on the Developer Exchange at some point but I'm not sure about this last point. Rolf Kalbermatter

Under modern OSes you do not deal with allocating and configuring DMA channels on your own anymore. The problem is likely that different DAQ boards have different numbers of DMA channels built in. Basically the more expensive ones have more DMA channels. Timed analog input as well as timed analog output requires usually a DMA channel. There are some boards where a missing DMA channel can be substituted by Interrupts but they can't get the data as fast into the computer and are a much higher burden to the CPU, than if DMA could be used. Most likely you have a low cost DAQ board with only one DMA channel and therefore you get into trouble trying to do timed ananlog input and output at the same time. Maybe that the people from National Instruments technical support can help you with your particular board to get one or the other operation use interrupts instead. Rolf Kalbermatter

I agree too with this. Opening a dialog with a string control set to have the keyfocus is a very universal way. The user can have a barcode scanner attached through a keyboard wedge and just use that (configure the barcode scanner to append a carriage return to each barcode send and then check for that to autodismiss the dialog) or if there is no barcode scanner present for whatever reason he can type in the ID over his keyboard and press the OK button to close the dialog If you really need to do background barcode scanner input this is usually done through a serial port barcode scanner (or with the new USB scanners through a driver which installs as serial port driver instead of plugging into the system keyboard queue). These barcode scanners are typically a little more expensive as they are not sold in the same numbers. Rolf Kalbermatter

You do have a little problem here. The actual control label information is stored in a different place than the data a control contains. Just because you find the word "password" in the binary data, does not mean that the actual default password data is directly adjecent to this string. In fact it is not. LabVIEW stores its files in a resource format very similar to the MacOS resources. That while a logical format, separates different aspects of a VI in seemingly unrelated areas in the file. So the fact that you see a password string in a file would indicate that you might try to search any other string to try to figure out which of them could be a password but it will not show you easily which of the numerous strings in a VI file is the password. Of course, why would you store a password in a VI? Passwords are to be chosen by a user and remembered by those users. Storing them anywhere basically makes passwords quite useless anyhow and you could simply forget about the hassles altogether for everyones benefit. All my VIs which contain a password control would not give you any password at all. Their default data is an empty string and it is meant to be a parameter passed from higher level functions and ultimately coming from the user itself. Any passwords I might store in an application (usually in a config file) are stored as a one way hash such as MD5 or SHA of the original password. On verification the user enters his password and the same hash is calculated and if the calculated hash does not match the stored hash, the password was not valid and access is denied. The actual password however is never stored at all. This means that if the user forgets it not even I can get it back, but its either that or you don't need a password verification at all. Rolf Kalbermatter

Why? The only sure why that your super findings can not be stolen by anyone with bad intentions is to lock them in a safe, throw away the key and destroy any notes and software code you happen to have done during development. Once you distribute it, there will be always a way to get at that information more or less easily. So you may just as well forget the pretense to have your code securely distributed and live with it. Give me a compiled DLL and unless it is code which on puropse has been obfuscated with self modifing assembly routines, I have the complete code reverse engineered in less time than it would take to just figure out how to call diagramless VIs to get at sensitive data. Does this mean that anybody using Visual C, Borland C, Delphi or whatever does not have anything to hide in comparison to a LabVIEW developer? Cool down and see the things in respective. Rolf Kalbermatter

While this type of recursion is a nice thing to show that it can be done, it has some serious drawbacks. Invoking reentrant VIs through VI server recursively is a very time and memory intense operation. Such a recursive algorithme is ALWAYS much slower than one which does the recursion through a stack based algorithme. As long as the recursion is only a few levels deep this probably won't make a to big difference but for deep recursion it is definitely a bad choice. There are several threads about factorial VIs on NIs Developer Exchange LabVIEW forum. Some show this example but there used to be a challange at some point which showed the other aproach which can calculate !3000 without taking 100ds of MBs and half of the life of the universe to get the result. ;-) Rolf Kalbermatter

The 3D graph is an Active X control and the LabVIEW implementation of the Active X container does not support transparent or overlay mode. This is partly because ActiveX initially didn't allow for that and many controls don't support it properly anyhow. If your graphic you want to display is not to complicated you could try to draw it in the Picture Control which is a native LabVIEW control and can be overlaid as desired. Rolf Kalbermatter

Early versions of LabVIEW can make copies of data where it isn't necessary. But at least since 5.x it does not generate data copies when merely passing out a variable from a subVI to its caller. This does of course require a few clarifications: If your frontpanel is open, then LabVIEW will create a copy of the data for the internal data buffer of each control. This is logical as the control needs to maintain its own copy to be able to (re)display the data as needed. In LabVIEW 5.0 and 5.01 (and probably 6.0) where some issues where passing out arrays stored in shift registers could either create unnecessary copies or much worse under certain circumstances: reuse data from earlier loop iterations which resulted in wrong behaviour. This is however not a problem which would appear in a wrapper VI but in the actual LV2 style global itself, so creating a wrapper had no influence on this nor a worse performance. In current versions of LabVIEW passing in large arrays into subVIs to be worked on in there (and preferably through shift registers in the subVI if a loop is present) and then passing them out of the subVI again to the caller does not create data copies at all, unless absolutely unavoidable because of the data manipulation inside the subVI. So this architecture is much more performant than simply branching of from the array to be passed to a subVI for operation on that array. This is since branching a wire to be passed to a subVI will have to create a copy of the data, while by simply passing it though the subVI where no branches of the wire occur can completely reuse the original buffer. Rolf Kalbermatter

You could always select the checkbox in the File Dialog "Save a copy without updating callers". Rolf Kalbermatter

I didn't want to spoil your proudness, but I created such controls back in LabVIEW 5.1 after seeing one in an NI application. There also was some discussion including a step by step description on Info-LabVIEW back then. Rolf Kalbermatter