Rolf Kalbermatter

I think there are such VIs on the NI site. Try to locate them there. I haven't used them but a collegue got them in the past. They were limited in the data types supported but adding new datatypes didn't seem to difficult with a little digging. Rolf Kalbermatter

I don't think LabVIEW will add support for modyfying it's toolbar anytime soon. But with the new splitter pane you can create your own very nice toolbars in LabVIEW 8 quite easily. Rolf Kalbermatter

Wow LabVIEW contains actually a reverse compiler . Now everyone that saves his VIs with password or no diagram at all is simply buggered ;-) Hmm, not sure how that differs from the first really. Still needs a reverse compiler and I just so much like this new extraSuperSecretTool. Naaa! This last one is to simple. It can't possibly be this! ;-) Rolf Kalbermatter

The latest news I heard are the same. NI seems to have dropped the idea to think about how to commercialise the Cubix platform. So it's a nice idea but it will probably never be sold in that form. Maybe an opportunity for a third party. With the LabVIEW Embedded Developer platform this would be very feasable, although I wonder about the commercial benefit of such, if even NI doesn't sees a chance to make it a profitable thing. Rolf Kalbermatter

This is only really true for modern hubs. Older dual-mode hubs frequently had trouble to auto negotiate the correct speed and/or handshaking too. Rolf Kalbermatter

Changing the global cursor is not such a simple exercise. Basically Windows maintains a cursor state for each application and changes it accordingly whenever the cursor changes into a screen area owned by a different application. And in the case of LabVIEW it gets rather nasty for the application cursor. LabVIEW has the habit of resetting the cursor frequently to what it thinks it should be. But if you use LabVIEW 8 then you have already functions in the palatte to change the cursor state for at least LabVIEW. To change the global cursor consistently I'm afraid you would end up having to write some hook function again. Rolf Kalbermatter

Maybe that would be a chance to learn C? It's still THE engineering programming language and won't go away anywhere soon. Having some knowledge about C programming will always be an added bonus in almost any engineering profession where you even remotely need to get your hands on a computer. I'm not volunteering to write this thing for you, sorry. It's going to be a time consuming exercise in any case and to get it work exactly as you envision it will probably get a hard exercise for someone else than yourself. Rolf Kalbermatter

Maybe not Most of people at the NI marketing department used to be female back when I was in Austin some 14 years ago, and they were very nice folk to be with . Not sure if that has significantly changed. Rolf Kalbermatter

The file IO APIs the Large File package uses are standard Windows 32bit APIs. The only reason this might not work is that the underlying RT OS and its WinAPI implementation does not support files bigger than 2GB at all. If that's the case there is absolutely nothing you could do in the application itself and maybe that is why HDF5 is not supported. Rolf Kalbermatter

I haven't played with the watchdogs on cFP and don't have one handy to play with but I'm afraid there is only one wtachdog hardware resource on the cFP. Either trying to open more than one will not work at all or if it does it may reset the watchdog on every access which means you would only fail if ALL your loops stop. A better aproach may be to wire up a small LV2 style global that allows your loops to open a reference to some internal state (an array index might work). On every reset store the actual timestamp in the apropriate index and evaluate all timestamps to have not elapsed more than your set value. The whole thing might be a little bit involved in logic to make sure to reset the actual watchdog apropriately but it could definitely be made to work. Rolf Kalbermatter

In principle LabVIEW should only use XWindow and therefore should be independant of the Window manager and Desktop environment used so should run on any system that has an XWindow server. There have been however some trouble in the past letting LabVIEW run on dummy XWindow servers that only provide some sort of text output (to save resources for applications that could run as headless systems) and I'm not sure there has been any work done to improve on that. Rolf Kalbermatter

Inlined means that a C compiler will simply reserve the necessary amount of bytes for any fixed size data element in the structure itself. An example struct { int val1; int array[]; } will represent a structure with 8 bytes length first the val1 integer and then a 32 bit pointer struct { int val1; int array[100]; } will represent a structure with 404 bytes length, again the val1 integer and the 100 array elements directly following. Similarily an array int arr[10][10] inside a structure will represent a memory area of 400 bytes (10 * 10 * 4 bytes) directly in the structure. In LabVIEW you would create a cluster of 100 integer elements for this. An array int arr[][] would really mean a pointer to an array of pointers instead. In C multidimensional arrays are a little bit strange if not to say inconsistent. As you can see fixed size arrays look in the organization similar to what the data area of a LabVIEW array does (but a LabVIEW array is always a handle to the data) while non-fixed size multi-dimensional arrays are really hard to deal with.

There is a VI File Info.vi in the OpenG Toolkit file package that allows to change the modification date and creation date of a file provided the current user has enough privileges for the file in question. The prototype you are showing in your VI is VisualBasic syntax and not very helpful for LabVIEW purposes. LabVIEW is strictly typed just as C is and needs to be configured to match the expected C types exactly. If I remember right then FILETIME is a 64bit integer or a long long. This can be achieved directly in LabVIEW 8 with the (u)int64 but in LabVIEW before 8.0 you would have to create a cluster of two (u)int32 and pass that instead. Rolf Kalbermatter

The SetWindowsHookEx function takes as one of the paramaters a callback function. This is a function pointer and can only really be confortable done in C so you will have to write a DLL in C that does the hooking. The callback function will inspect the message passed to it and either modify some parameters, deny handling of the message altogether or allow handling of the message unaltered. The return value of your callback function determines if the message should be further handled or not. It's a low level work area and if your callback function does the wrong thing you can get your Windows system in a rather hard to control state. (Ctrl-Alt-Del) may be your only friend then or the reset button. Rolf Kalbermatter

As Chris said demand is the key issue with NI. But another issue is that OpenOffice was not a well known topic at all back when the report generation toolkit was created. Otherwise chances are that at least a basic interface to OO may already have been built into by an enthuastic NI developer. Several of the example libraries and toolkits started out as a private pet project of someone inside NI and sometimes even outside of NI. Rolf Kalbermatter

As far as I'm aware a large part of the find uitlity is not exposed at all to the LabVIEW diagram. Maybe that changed in LabVIEW 8 but in earlier versions the Find utility was a LabVIEW internal dialog that had direct access to all internal methods of LabVIEW without having to go through a VI server interface. Rolf Kalbermatter

Nice work from JdP indeed. This is what most Windows programmers do not seem to like very much but which is very common on Unix. Just call the other program directly with some parameters. It keeps everything rather simple by using standardized interfaces, leaves specific functionality to the tools that can do them best and follows the KISS principle. Right, I undersign the (someone else ) part! I'm not a masochist and doing Active X on MS Office applications is aiming for a moving target! Not much fun at all! Rolf Kalbermatter

Some very minimalistic Vision VI functions are installed by NI-IMAQ the driver software for National Instruments image acquisition boards. Those functions allow NI-IMAQ to give you an image back into LabVIEW but that is about it. The Vision Development Toolkit is a much broader library that contains all the VIs that you could possibly dream of. Rolf Kalbermatter

You got quite a bit wrong here! First the arrays you have are all fixed size so they are inlined as such and represent nothing like a pointer. You would need a cluster with following setup: int32 num cluster of 4 uInt8 name cluster of 16 int32 dnum uInt8 flet cluster of 16 * 256 uInt8 aname Especially the last one is not very convinient to do and I personally would treat the entire structure as an array of unsigned bytes passed as a C array pointer and write VIs that insert an retrieve the according information from that byte stream. Rolf Kalbermatter

Capturing events from other applications is something only doable with Windows API programming and with some involved ones too, using callbacks and such. Search MSDN for filter hooks such as the SetWindowsHookEx function does. Basically you have to install a global filter hook for the events you want to block, implement the callback function that receives the redirected events and discards them depending on the passed parameters etc. Doing this for LabVIEW will absolutely positively mean that you have to write an intermediate DLL. Rolf Kalbermatter

I'm no expert in c++ but LabVIEW will only be able to handle standard C types. They also are the only types that are really standard across C compilers. I think the best is to declare your function prototype as standard C such as: #if defined(__cplusplus) || defined(__cplusplus__) extern "C" { #endif int MyFunction(double array[], int length); <other function protoypes you want to export from the DLL > #if defined(__cplusplus) || defined(__cplusplus__) } #endif This should tackle most of the problems with C++. Rolf Kalbermatter

I'm pretty sure MAX is not a LabVIEW application. Probably not even a LabWindows CVI one. Rolf Kalbermatter

That is what you get when playing with forbidden toys ;-) Sincerely I haven't used this method at all but the host window is the window handle of the window you want to be the parent of your VI. This handle is the platform specific window datatype such as HWND under Windows or WindowPtr under MacOS. As you can probably see it is not so much meant to embed VIs into other VIs (Subpanels do generally a good and often even better job in this) but to embed a LabVIEW frontpanel into a non LabVIEW window. That said I doubt you can embed windows across process bounderies so this method has probably mostly only limited value for some obscure projects NI has been working on. Rolf Kalbermatter

I know this might be a moot point with LabVIEW 8 only supporting 2000 and XP anyhow, but there are many people still running on older LabVIEW versions and Windows OSes. And for them .Net is not just an inconvinience but simply an impossibility. So why use a high tech laser cutter for something where a simple pocket knife will do more than well enough? Rolf Kalbermatter

Hmm, if you would want a complete one it would be more something like a few 1000 I'm afraid. And if you only want a subset you open all doors for a fight about which are important: VISA, IMAQ, Database, Internet Toolkit, IVI, Active X, .Net, etc, etc? Better don't go down that path ;-) Rolf Kalbermatter