Rolf Kalbermatter

Well I agree with both of your assertions about Irene :-) However the problem is not that your VIs "loose" the connection to their subVIs nor that VIs are usually referenced by an absolute path (absolut paths are only used if the volume is different and under Windows this means also a different drive letter) but that VIs located in the "standard" locations such as vi.lib and user.lib are not referenced by their full path ever but by an artificial path similar to "<vi.lib>/local path" LabVIEW recognizes the special path component <vi.lib> and will search in its vi.lib directory but the runtime system by default has not such a directory (nor has it any other standard search paths configured by default) and will fail locating the VIs in there. Rolf Kalbermatter

Well that is not exactly true but it is a bit of a pain and for reentrant CINs you really can be in trouble sometimes. The most reliable way is to add DbgPrintf calls into your code. That is a LabVIEW manager function just like the other xxPrintf function explained in the External Code Reference manual but the output goes to a debug console window that opens on the first execution of this function instead of a memory buffer address. Another one is to add a DebugBreak() call (Windows OS API, other platforms have different calls) into your source that will cause a user breakpoint exception and break into the system debugger if any is installed. Otherwise you get an Exception dialog. However newer versions of LabVIEW add exception catching around external code calls (at least for Call Library Nodes, have not done any CINs for a long time). You can disable this exception catching from LabVIEW 7.1 onwards by adding the extFuncCatching=False entry to the LabVIEW.INI file. This won't work in LabVIEW 6.1 or 7.0 so debugging external code really is a pain there. Note that if your CIN (or DLL call) is reentrant your are likely to run into a deadlock situation (at least with Visual C 6.0, not sure about other debuggers) with the debugger blocking on some GFL (Windows global f***ing lock) and also locking LabVIEW entirely. The only solution I have found so far out of this is Ctl-Alt-Del and then retry debugging with reentrancy disabled. Rolf Kalbermatter

I think a somewhat smarter way for ini files (and XML files are just as simple) would be to add an extra key such as SecurityHash=AB123FE45... Calculate that hash using all the key names and values of that section in a deterministic way combined with a hardcoded private key and a hash function such as MD5 or maybe better SHA-1. On load read that key and verify it. If failed use default data instead. After having had to enter a complete configuration two times most users will probably stop altering files (or be so pissed off that they won't use your application anymore ;-) Rolf Kalbermatter

Well, yes if you are not familiar with DLL development (and shared libraries on other platforms than Windows) you won't get far. Basically you need to implement most of the lvsn... functions from the lvpython.h (lvsnapi.h in the newest CVS version only) header file and then drop that dll in the Resource/script folder inside your LabVIEW folder. As to the Node.vi there is no mystery. It is all documented albeit not well known. You create a VI that contains the preconfigured diagram and then creating a VI palette icon in the palette editor you enable the Merge VI option in the popup menu of the icon. With merge enabled LabVIEW will drop the diagram in your diagram instead of the entire subVI. Read in the LabVIEW documentation about how to create your own menu palettes if you haven't done so yet. Rolf Kalbermatter

Checkout VISA properties. If you have a VISA refnum you can get various properties for that and the Interface Information->Interface Description should contain extra information in the string for other than built in serial ports. Rolf Kalbermatter

I'm afraid this won't work. Since the operation you try to abort is most probably not asynchronous but just waits in the VISA driver itself for the complete or timeout event and is therefore synchronous in nature. Your best bet is to write a VI that does a VISA read in a loop with short timeout instead until data has been returned OR another error than timeout is returned OR your long timeout has elapsed and abort that loop through a global when you need to do so. A tiny bit of programming and thinking but an absolutely fail safe solution that depends nor on external code, nor on specific LabVIEW hidden or version dependant features. Rolf Kalbermatter

I just append an improved version of the _browser WREG Read Key.vi here that is used by above mentioned Open Document on Disk.vi. I'm almost certain I had put that up somewhere already but may not remember right, so I do it now here. This VI takes into account extra registration of applciations for a certain file type and treats them the same way explorer does. The old way opened the last registered application for that file type. It is LabVIEW 7.1 format and the latest LabVIEW version might already contain this improvement, I didn't yet check. Rolf Kalbermatter Download File:post-349-1159618597.vi

I think it is amazing they even got it that far. As to supporting any and every header file format, this is going to be impossible. The windows.h header file hierarchy is so complicated, riddled with almost magic macros and other compiler specific stuff that to get this done you would have to create a real compiler. And that together with writing an OS is one of the things you absolutely do not want to do in LabVIEW. Every C compiler out there comes with its own platform SDK header files in order to support the specifics of that compiler. To try to compile with the original Windows SDK headers with another compiler than Visual C is almost impossible and a sure way to go insane, while you try to figure out which modifications need to be done to the several 100 headers to get them to not cause compile errors anymore. In addition there are several more or less commonly used C features LabVIEW simply can't deal with (yet), such as function pointers and complicated structures. Rolf Kalbemratter

This is not C++ and the DLL importer couldn't deal with C++ at all. It's standard C and defines a function pointer that can be used as callback parameter to another function. As such it is an advanced C feature a lot of people have trouble to understand. Worse it is not something LabVIEW could do directly for you, so if you need to use the function that takes this function pointer as a parameter, you can't do without writing an intermediate DLL and converting in there the callback into an occurrence or user event for LabVIEW. Rolf Kalbermatter

This looks pretty big and it would seem strange if you were not using some .Net, ActiveX, DDE , DAQ, GPIB, and DLLs/CINs in there somehow. Any of these and a few more can be a more or less big stumbling block depending on your experience in those areas. Rolf Kalbermatter

Of course not! Active X is based on OLE which is a proprietary MS technology and there has been no working replacement for ActiveX on non-Windows platforms (and even if there would be LabVIEW for Linux does not support it). Since MS Office applications before the latest Office version use OLE structured storage for their file format too, you are more or less locked into Windows until you decide to use other data formats. Rolf Kalbermatter

It's not exactly clear what you try to do? If I understand you correctly, you want to pass in a LabVIEW data wire into a DLL Node and not wire the right side of that terminal, but instead have the DLL pass that same handle through another terminal back to the diagram This is not only gonna create a memory leak but also crash too, sooner or later. The reason is as follows: If you wire in something to the left side of a terminal pair in a DLL Node and not wire the right side, LabVIEW has to assume that the data is not used anymore and dispose of it. This would make the handle you return through another terminal invalid. At the same time if you do not wire anything to the left side of a terminal pair LabVIEW will allocate the default data (for instance an empty array) for the specified datatype to pass to the DLL but since you overwrite it with the now invalid handle inside the DLL you loose that handle. This is all logical when you follow the rule that whoever allocates memory should be concerned about disposing of it. In this case LabVIEW did allocate the memory in the diagram to pass to the DLL and also is responsible to dispose of it after the diagram does not seem to use it anymore. If you try to do magic behind LabVIEWs back inside the DLL you have to be EXTREMELY careful what you do. In most cases it is not worth the trouble to even try to do such things. Rolf Kalbermatter

Contact Eurosys. They told me in the past to have some LabVIEW VIs. No idea how good they are though. Rolf Kalbermatter

What LabVIEW version do you have. This has been in LabVIEW since 7.0. Look at Application Control->Cursor. Rolf Kalbermatter

Importing from the DLLs (OpenCV exists of several of them) is really a nitty gritty and time consuming work but still by far not the largest part of such a Toolkit. Many datatypes with OpenCV are specifically C oriented and not suited for direct consumption in LabVIEW so you will have to do some intermediate DLL programming such as what has been done in IVision, or suffer terrible performance. Then you need to make the automatically created VIs use more appropriate controls, add documentation, icons and help information to it. Otherwise nobody is going to use it since it is way to hard to understand. And there is nothing worse than an Open Source library that nobody does use. Rolf Kalbermatter

That's right and the fact that CRLF is used as message terminator but can also appear in the message itself makes it a bit complicated. However there has to be some specific protocol specification. Either you read in one line and from there can know what will have to follow if any (so your receive loop already needs to know about the specific protocol) or you have an empty line added to the end of every multiline message, which will indicate an end of message. Rolf Kalbermatter

Nope, DSHandles are NOT automatically disposed other than at application exit. The same applies to AZ handles. If they would be disposed at the end of your VI execution you would have real troubles to return them to a caller. The difference between DS and AZ really only is that AZ handles are relocatible between calls, which means that you need to lock them explicitedly if you want to dereference them and unlock them afterwards. LabVIEW maintains all its data that get exposed to the diagram excpet path handles in DS handles. However all modern platforms really have no difference between AZ handles and DS handles since locked handles still can be relocated in the lower level memory manager of the system without causing general protection errors, thanks to advanced memeory management support in nowadays CPUs. I believe that the actual AZ and DS distinction was only really necessary to support the old classic Mac OS. According to some postings on Info-LabVIEW from people who should know no flattening is actaully done. Rolf Kalbermatter

Lucky you! You seem never have to worked with older Visual Studio software releases :-) Rolf Kalbermatter There are better ways to commit suicide Rolf Kalbermatter

Since it is a text file I think modification of data is not that bad, especially since the LabVIEW internal end of line indicator is LF too. If you want binary consistency then accessing the file as binary file might be more appropriate. Also the file itself won't change before you save it back. As such I do hate the right click popup options of all those new nodes and that definitely has to go away. It hides fundamental functionality from anybody looking at the diagram and "that is a bad thing" TM. Rolf Kalbermatter

This does work but probably not as you would expect. LabVIEW prepends information to variable sized binary data such as arrays that tell it how many elements follow. So if you read back your array you would have to read back two arrays now. The first read would read the orignal array written to the file and the next read will read the appended array. This is logical and the only way to make this work since binary means just really that, and not some metaformat that would handle such concatenations and other hairy operations transparently. Rolf Kalbermatter

#defines are proeprocessor keywords and not part of the actual C compiler. Having a fully compliant proprocessor and a complete C compiler together in one single tool is a major undertaking getting you almost to the point of writing a complete C compiler (well at least the complete parser for it). THis is highly recursive and hard to implement so I guess the developers of the import shared library tool made a few decisions to restrict the parsing complexity. The used OF() macro is from the zlib header file and is used to work around some very old non C99 compatible compiler issues. There are not many compilers that need that anymore but the developers of zlib want to be compatible to as many compilers as possible. Rolf Kalbermatter

No, all the other functions are private and undocumented unless you happen to be a member of the LabVIEW developer team. LabVIEW 3.0 shipped with a much larger extcode.h file where you could see the prototypes of all those functions exported at that time. BUT: still no documentation about the functions and more importantly the parameters and I think LabVIEw exported maybe 500 functions or so back then, some of them are gone completely, others have changed considerably in prototype and/or behaviour. Unless you have a year or so of leisure time to dig into this I would recommend to forget about these functions. Rolf Kalbermatter

At least if ping hasn't been disabled for that computer. Nowadays with security concerns all over the place this is not something uncommon to happen. Rolf Kalbermatter

I don't think compiler building is the way to make money in the future. I'm focusing here on C/C++ since that is what I know most and is also by far the most widly used development system to develop applications: The biggest compiler system (GNU) nowadays is open source and is not something to make money with from itself. MetroWorks didn't fail because it was bought by Motorola, I rather think they might have failed earlier without. They got quite some business out of supporting just about every Motorola CPU, and their main business supporting Macintosh development would have been probably dwarted by now quite a lot as Apple decided to use GNU C instead of anything else for OS X and considering they used an Open Source kernel that would seem like a smart move to me. Borland has a track record of making bad decisions at the wrong moment about great products. Symantec has aside from the starting years never been a company doing products for the user but was only about making money. Watcom was quite successful but were in a specialized business niche, enabling technologies that got easier to do with the year on just plain MS Windows and now most of what Watcom was is Open Source too. Leaves only really MS Visual C and Intel C as currently still active commercial compilers. MS Visual C because it is from the makers of MS Windows and Intel C because they know how to tweak the latest ns out of their CPUs. Basically I think GNU C has over the years made the idea to sell C compilers rather unattractive. I do not see how it could be in the financial interest by NI to promote a GNU Graphics Note: G is already taken as a programming language name and not for LabVIEW so I will refrain from using it here.Dataflow IS LabVIEW. Taking it out of it creates something that is anything but LabVIEW. So I think this settles this. The biggest power of LabVIEW is dataflow but that creates limitations at the same time such as difficulties or almost impossibilities to create a really object oriented system with inheritence and all this, or generic references to speed up large data access. On the other hand dataflow does allow seemless parallelisation of code execution for users that do not understand anything about multi-threading. This same advantage makes implementation of references in a thread safe manner almost impossible without dwarting the perfomance improvements these references are supposed to bring. Exactly and in doing so it would be mostly getting useless for what we are doing with it. I think there is not much of a problem to try to get your own graphical programming environment started then and put it out as Open Source project ;-) if you abtain from using dataflow and a few specific graphical contructs. I know NI has patented many things but some of them are so general that there is certainly proof of prior art or it is so logical to do that alternatives are not even imaginable. A system to configure hardware resources in a certain graphical representation borrowed from MS Explorer is not something I would consider patentable ;-) Others could be interpreted to patent the idea of an API. Rolf Kalbermatter

Because it is asynchronous. The execution of the property Node does only post an event to the UI thread to refresh that VI front panel next time it gets around to be scheduled by the OS to execute. It then continues to execute the diagram and changes the other property nodes too. At some point the OS decides that the current thread has had enough of a time slice, interrupts it and eventually passes control to the UI thread which then does proceed to do whatever it needs to do according to the current properties for that window. This can mean that you still might see flicker on a very slow machine. Nothing to do about this. Rolf Kalbermatter