Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Feb 13 2007, 12:36 PM) No! I haven't looked at it yet, but before they tacked the LLB to the end of the executable stub and then added a small header (I mean tail) behind that that told the loader where the LLB was. I have a suspicion that they now add the LLB as a custom resource to the resource directory of the executable. Not really to dwart anyone to see the LLB but instead to allow signing of executables in VISTA. They just used that change to purposfully "forget" updating the exported LLB routines to look for an LLB in that place. Gave them some easy way of minimal obfuscation. And I still think anyone worrying about his code being picked from an executable in this way has a lot of other problems to deal with frist, some psychological ones not to be among the least ones. Rolf Kalbermatter

QUOTE(prayami @ Feb 11 2007, 12:23 PM) Well recompiling VIs is always necessary when you go from an older version to a newer version. That is completely independant of CINs. Any VI will prompt the user having loaded it in a newer version than what it was created in, to save that VI. And as said I compiled regularly CINs in LabVIEW 4 or 5 and they still load and run in newer versions. Abandoned CINs at around LabVIEW 6 as they are now considered legacy technology and don't really provide anything above DLLs but have quite a few drawbacks as far as maintenance is concerned. Rolf Kalbermatter

QUOTE(Val Brown @ Feb 13 2007, 07:14 PM) First with the exception when starting with VISA I haven't met anything that could have been done with legacy serial but not with VISA. I'm using it quite often for all kinds of serial communication and haven't seen serious troubles in quite a while also with USB to serial adapters. If you really need to do it otherwise your best bet will be to use Martin Henz's serial port library that you can download from http://www.mhst.de/downloads.html. But the only real reason so far for using that was that it is independant of NI licensing which used to be complicated and difficult in the past (but they fixed that in the meantime) and it's installation is not requiring a 100MB download from NI. No functional reason to use that so far. Rolf Kalbermatter

Definitely feels faster. Thanks Mike for giving us LAVA. Rolf Kalbermatter

It really depends! If you want to make an executable anyhow just build in some timecheck after which the application will refuse to run. Will obligate you to regularly create new trial executables. If you want to distribute trial libraries do the same in some essential VI that one has to use and make it display a dialog too. Password protect that VI. Any other means is probably more hassle than worth to do. In any case be prepared that a few people will download your software but you probably won't sell much. It is already hard to get a lot of people to use free Open Source libraries! Rolf Kalbermatter

These are typical Windows SDK types. But your header file does not include any other header files so it is syntactically not right. A C compiler could not understand it either without additional includes defining those types. Bascially that whole header file looks like a big mess to me. I'm surprised that Microchip does release something like this. There have been various posts here on LAVA and the Developer Exchange showing the actual type definition of those Windows SDK types. Adding them to the top of your header file seems to be the most simple solution. I do not understand your question about defining your own data. I would say no but can't be sure. Rolf Kalbermatter

Yes but!!!!! As long as this call is the only one to this DLL in your entire application you are fine. But if you ever decide to add this VI or another one calling into that DLL somewhere else in your LabVIEW program you are creating something I call "peut-

This header file uses a very strange and unusal way to define the function prototypes in the DLL. In fact it does not define any prototypes but just function pointer types. That's definitely not a standard way to incorporate this DLL into once own code even in C. Try to change for all functions DWORD (*MPUSBGetDLLVersion)(void); to DWORD MPUSBGetDLLVersion(void); basically removing the brackets around the function names and also the * in front of the function name and then try to import this again with the DLL import tool. Now it should work. Rolf Kalbermatter

I know about this technique and have used it infrequently in the past. But basically in order to be able to do that you need to know a lot about how you would do that in C and then it gets almost always as easy or even easier to just write a wrapper DLL that does the correct translation. It's definitely not for anyone that has trouble to understand pointers and references. So instead of mentioning that this can be done and have people ask me to do it for them I just say it can't really be done. The people that know how to do it or at least know enough to be able to figure it out can easily find it themselves and usually agree after the first trial that it's very frustrating work to do. Doing alloc(), memcpy(), free() through LabVIEW CLNs is while possible, a bitch to do and the diagram basically looks very soon like someone had a very bad programming day. Rolf Kalbermatter

As long as those clusters to not contain variable sized elements (pointers, arrays with [] instead of [x]) you simply inline them into one big continous memory area. Actually you can keep the clusters in the clusters for better readability as LabVIEW does this same inlining too. The only problem you need to watch out here is possible byte padding. LabVIEW always uses byte packing without any padding but most external libraries nowadays use 8 byte padding. That means the offset of an element is always aligned to the smaller of the two values: 1) a multiple of the data type size 2) the alignment (here 8 byte) by adding extra filler bytes before that element to make it aligned. You can actually adjust for that too by simply adding the necessary amounts of uInt8 and uInt16 dummy elements before the aligned element since adapting to alignment with a packing compiler is possible but not otherwise. Rolf Kalbermatter

Hmm, you are right that property always returns 0. However defining 0 for the parent window for a dialog should make the dialog system modal. Hmm, hmmm??? Rolf Kalbermatter

I have nothing specific to add for the moment but I like the idea to get a more exception like mechanisme in LabVIEW error handling. That this would be possible with maintaining compatibility to the old cluster I hadn't even considered. At least NI has an internal way of mutating VIs automatically when upgrading them to a new version (the update specs are in binary format in Resources/vicnvrt somehow), but staying compatible would also allow to use such a mechanisme in older versions of LabVIEW. Rolf Kalbermatter

No I do not wonder at all and have full sympathy with you guys. I even made repetitive statements to that effect. Doesn't mean that I wouldn't sometimes like to get my hands dirty though. I have a strong experience with all kinds of crashes whenever trying to debug my external code projects so I can't really be shocked. Rolf Kalbermatter

Yes that is how I see it. I have always seen this use of LGPL as legal. It's the very fact why LGPL exists besides of GPL. Yes Linux is distributed under GPL but there is a special clause in the Linux license allowing to run applications on it, which in fact is nothing more than dynamically linking to the kernel. However you can't take parts of the Linux kernel and incorporate them in your own software and not distribute it as a whole under the GPL unless you get a compatible double licensing from the original author(s). Rolf Kalbermatter

Actually clusters are always passed as pointers. The "pointers to handles" and "handles by value" only refer to LabVIEW datatypes that are represented with handles such as arrays and strings and also only for the main datatype if it is such a handle, not for embedded handles in clusters, etc. And yes James what you show in your screen shot should work if you do it exactly that way. Rolf Kalbermatter

LabVIEWs refnum is not a Windows window handle. To retrieve the actual host window pointer/handle/etc (works on all platforms) you can use the private Application property Application.ParentWindowForDialogs. Refer to the scripting forum about how to get those private properties visible. But it is a good idea to disable them afterwards again, since the property and method pull down menus get really huge with them. Rolf Kalbermatter

I have had no trouble using CINs created in LabVIEW 5 in LabVIEW versions up to 7.1. Not sure about 8.0 but if I remember right the Luaview CIN created by my collegue Albert-Jan Brouwer is created with cintools from LabVIEW 7 and did run in LabVIEW 8.0 last time I checked. So I'm not exactly sure what is the issue about this. I do however remember a notice somewhere in some release document to use labviewv.lib or labview.lib instead of the other to avoid just this version difference problem. AFAIK this was not a problem in cintools prior to 8.0. Of course going the DLL path as suggested by others is the future proof way of working. Rolf Kalbermatter

Looks suspiciously like the 16bit typestring array in older Flatten to String functions. The first word 0x4070 is the actual type with the higher 8 bits being flags such as indicator/control etc, and 0x70 being the typecode for any LabVIEW refnum. Then follows a refnum type word and after that a variant (C union, not LabVIEW variant) construct depending on the refnum type. 0x001E seems to be the refnum type for LabVIEW classes. 0x0008 is for all kind of VI server refnums for instance. Rolf Kalbermatter

While I can see your point of view to a certain degree I think it is not exactly helping. If you typecast refnums and then try to access a property that does not exist in the original object you usually get a runtime error in the error cluster to that effect. So it does appear that the property node does do some runtime property lookup or something and only references the object data field from there. Seems quite safe to me! If you want to brandish the person having implemented that, you should also and even more so do so with the person having forgotten to add the TextField property to the String Constant. And there are many inconsistencies like that in the LabVIEW object hierarchy (without even looking at the super private and more obscure things) although I do understand that maintaining that and keeping it complete is a thankless job. Rolf Kalbermatter

Well being myself in the business of developing drivers for a living among other LabVIEW work I can't really feel sympathy for your problem. Maybe that is because of the first A in LAVA? Rolf Kalbermatter

You might have forgotten a piece that was omitted in the original post. If your application is called MyApp.exe create an ini file called MyApp.ini in the same directory and add: [MyApp] server.tcp.enabled=True server.tcp.access=+* Bascially the exact settings can be best configured in the LabVIEW development system and then copied over to your ini file but it is important to adapt the ini file header to match your application name. Leaving the VI server open entirely does not seem to be a very good idea to me. Rolf Kalbermatter

Well it is possible. But instead of an array place 8 uint8 elements at the end that will correspond to the 8 bytes of your data array. This array being fixed size is not treated as an array anymore really in C but really corresponds more to a cluster in LabVIEW containing the exact number of elements in it. And byte alignment is not a problem for this structure. See other posts for all about byte alignment but basically LabVIEW always uses 1 byte alignment while most C libraries use some other alignment such as 4, 8 or 16 byte. The alignment only says that the start address of a data element in a cluster is always set to a multiple of the lower of the two values being either the size of the element itself or the byte alignment. So LabVIEW uses really so called packed memory structures while most DLLs would place an int32 on a multiple of 4 for instance adding 0 to 3 filler bytes if the previous element would not end on this memory address. The alignment of data elements in structures can be set the by the DLL developer at compile time but for normal 32 bit DLLs nowadays under Windows you can assume 8 bytes if the library documentation or header file (look for #pragma pack(x) lines in there) doesn't show otherwise. Rolf Kalbermatter

Well Option 3 is not exactly undoable but pretty useless. All office formats with exception of the latest use the so called "structured object storage" format that MS actually has documented partly in the past. It is basically streaming of OLE objects into a binary stream of data. Now the difficulty is about figuring out the actual object elements in this stream for the different Office applications and reverse engineering is definitely possible. Open Office has done that. But it is basically useless because Microsoft has changed the object hierarchy with every new Office version in the past and with the newest Office even moved away more or less entirely by using XML instead. Dealing with these version differences is a nightmare, and reverse engineering such a format without an entire OpenOffice developer community is doomed to fail as you will be starting to figure out the actual workings of a format just about at the point where the next version is due. Rolf Kalbermatter

That would make sense! "Tax the bastards that can not appreciate our fully bundled lock into one provider packages". You also need to consider the extra testing necessary for customized CDs for the European market. Or wait it is a way of driving off European businesses to use Linux more, since they are going to do that anyway, so get from them what you can as long as you can! Rolf Kalbermatter

An image is not a control! An image is an image is an image and simply nothing more. As such it is just a decoration. Using the control editor in LabVIEW you can modify existing LabVIEW controls to use images from the image navigator as sub parts of that control. Each LabVIEW control consists of at least one subpart (simple boolean button) or more (for instance the housing, slider, increment/decrement arrow, filler, etc for a slider). The LabVIEW control editor is accessed by selecting a control with the right mouse button and then selecting Advanced->Customize Control. Beware the control editor is some sort of graphics editor but with limited customizing (you can only change the face and size of parts not more) and it is sometimes a little jirky to use, but if you invest some time you can really get very nice controls done. Rolf Kalbermatter