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

You could also have asked how to use a computer to create a program. Basically by learning the tools you have available for your use. LabVIEW DSC is specifically an add on to solve most of those problems a bit easier although it is by far not a requirement. But giving you here a run down of what to do would be mostly a copy of the Getting Started with LabVIEW DSC manual and I would assume you have that at your hands. Rolf Kalbermatter

You misunderstand VI server a bit here. VI server is the actual core functionality directly operating on the LabVIEW object hierarchy. LabVIEW objects have absolutely nothing to do with COM at all. LabVIEW to LabVIEW communication on VI server level happens through a LabVIEW private TCP/IP protocol and should support the same features except the ones that are limited on purpose for security reasons. The LabVIEW ActiveX server interface is just a wrapper around the VI server interface and I'm sure some of the COM concepts map better to the VI server object model than others. But considering your NI icon I would say you should definitely contact Lucyangeek aka Brian Tyler who is very proficient with .Net and ActiveX functionality and how it is implemented and used in LabVIEW. Rolf Kalbermatter

This last comment depends a bit I think. Yes I'm a bit a seasoned C programmer (but learned most of what I know about C after I learned LabVIEW). Having learned programming in Pascal might also have helped my tendency to opt for more functions than less. While applications tend to follow your screen hierarchy metrics somehow, that is not always the case with function libraries. I would agree that sorting out every wishy-washy into its own subVI is not very helpful both for maintenance and understanding of the code (and creating the extra icon and connector pane also needs some time) but I would say it is better to have a subVI to much than one to little. I really can't get happy when seeing someones code where: 1) a diagram that covers more than a screen size and is stuffed with all kind of code making it a major task to try to understand what the VI does. 2) or an application that has all over the place similar or the same code constructs implemented over and over again. That said the programs where various VIs are plopped into the diagram where the wiring and connector pane make it obvious that the VI was created with "Create VI from selection" without further edits to that subVI can make me even more sick. Or another bad design topic where many subVIs that all do more or less the same with slight differences are sprinkled through the entire application hierarchy. Rolf Kalbermatter

Well as far as C) is concerned: LabVIEW is smarter than that since I think at least 3.0. Since Array Size is a function that does not (re)use the array ever, LabVIEW always attempts to schedule this call before any other functions that use the branched array, in order to avoid unnecessary buffer copies. And here appearently happens the difference. Because Array Subset usually does modify the buffer passed in it does create a copy in D since the source wire has a branch. Since D is now a new buffer it can be passed directly to the subVI. In the second case Array Subset does reause the buffer but flag it as not clean, since it usually would have resized the array somehow, but in this case without reallocating the actual memory area. Since the buffer is not clean, LabVIEW create now a clean copy to pass it to the subVI. All this shows that analyzing for optimization is a difficult thing to do. In this case the first solution will be more performant since the additional buffer is only allocated once outside of the loop. Array Subset being a function that modifies the buffer is of course a nasty thing to analyze and as you can see optimizing the Array Subset here can actually have negative effects since LabVIEW has to consider many possible corner cases eventhough in this case the extra copy would not strictly be necessary. I'm also sure the entire story would look again different if you would add a shift register to the loop and pass the array into this, feeding it inside the loop from the left to the right shift register terminal. While this code may look useless it almost always helps LabVIEW to optimize the code in the best possible way, as the LabVIEW optimizer has some very smart shift register optimization rules. Rolf Kalbermatter

Very nice post! I feel almost bad not using a Mac currently! To bad Urs isn't much here on Lava! Yes I used Macs for most of the work I did until leaving NI in 1996 and have several times looked at buying one but never fully took the leap. There is also an Emac in the office since a coworker needed a machine to support an app. But that box is so damn slow that switching between applications makes you want to fetch a coffee every time and that is not so good for my blood pressure. But the Core Duo notebooks did make me seriously consider again :thumbup: , eventhough their price is a bit higher than other systems. Rolf Kalbermatter

Yes! The icon resource format used by LabVIEW originates from the original Macintosh OS icons. They have no explicite color table but instead use the application color table initialized by an application at startup and LabVIEW simply adopted that idea and ported it to all platforms. Changing that now would be a bit of a difficulty although I guess they could add a new million colors icon format to the internal resource table. But that would be a lot of work since quite some low level routines would have to be updated and retested (where I think the LabVIEW developers would rather not use that resource format anymore if they could), the icon editor would have to be seriously overhauled, quite a bit of bitmap handling would have to be adapted to support that new icon format and last but not least the color picker tool itself would need to be taken care of too. And I have some feeling that there are quite a lot of other projects on the todo list that have a higher priority and would require less work to do than this and with a lot less risk to break existing code. I do think that the original color picker from older LabVIEW versions which had the actual colors in the 6*6*6 matrix was better for the icon format but they had to update it to support the color box which could take millions of colors. Rolf Kalbermatter

Argh! I forgot about that. They changed that with I think LabVIEW 7. Before only the BW icon was used to compute the transparency mask. Rolf Kalbermatter

But your use of "Or if this is all you need..." implies a certain simplicity to me that I really can't see Rolf Kalbermatter

Well, that or it is indeed a group of hobby freaks wanting to do that in their closed group. Whatever, with such an attitude it is quite likely doomed to fail even if some commercial interests and agenda is involved. I would estimate some 10 man years of development before one can present a system with an architecture that is stable enough for future enhancements and that does some more than what LabVIEW 1.0 could do. If I would setup such a project I would go for a common UI widget Toolkit like QT with an architecture to add special plugin widgets for new types of controls such as waveforms etc. That would require C++ (I don't think any other programming language except C is up to the task) but since my C++ is bad I would not be able to participate to much. One difficult part is the compiler in LabVIEW but it might be interesting to go for a JIT implementation instead, although that technology in itself is not really easier than a normal one pass compiler. All in all LabVIEW itself has probably some 1000 man years of engineering invested into it and doing it all over from scratch you might get away with 100 to get to a level that can remotely do what LabVIEW can do nowadays. But that would not include LabVIEW realtime or FPGA or embedded. Rolf Kalbermatter

No not exactly. The 256 color palette LabVIEW uses actually comes from the Macintosh as a lot of other things that are in LabVIEW since version 3 :-). That this color palette closely correlates witht the web standard does basically just show that Apple as so often had a bit of foresight when doing their user interface guidelines. That or they had a secret time machine and just stole all the things that got later standards:-) Yes icons in itself have no transparency. The tranparency is done by a mask and this mask is in LabVIEW automatically computed from the BW icon. With a resource editor that understands LabVIEW's file format (in older LabVIEW versions you could simply use a Macinbtosh resource editor on the Mac version of LabVIEW) you could manipulate that mask to use something different than the automatically computed mask. Any bitmap in LabVIEW can have 24 bits. And for importet bitmaps that are only imported to be placed on the front panel for instance, LabVIEW even allows transparency (GIF, PNG). Last time I looked (LabVIEW 7) the Picture Control itself did not support an Alpha channel (32bit bitmaps). Rolf Kalbermatter

You all take the front panel to literal. You seem to assume that this is the front panel of your main screen but in LabVIEW the front panel is the second window besides the diagram window that EVERY VI has. So the course information says you need to have this on the (any? I really get a hunch that this quote was taken out of context and was actually in the chapter about creating an application and where the inclusion of an About screen was explained!!) front panel and the license agreement specifies that it has to be in the About screen. Seems very simple to me: What legal verbage do you trust more? Yes the license agreement! Is the course information wrong? No not really just not very clear. However I don't think that an invisible or unreadable copyright notice would stand in court if it ever got there. Rolf Kalbermatter

I don't think LabVIEW in itself supports marshalling of arbitrary COM interfaces through its ActiveX interface. That would be a whole bunch of extra code to make it generic enough to support all possible datatypes. Rolf Kalbermatter