Ton Plomp

Using the OpenG Variant Tools, you can investigate the contents of any variant. Using this data I have written a XControl that presents the data inside a variant on a tree. Ton

If you don't use native Windows code (.Net, ActiveX) you can easily port your code to Linux. Few things to mind: DLL, if you have a DLL, and you have a compatible .so file you should configure the calling to use foo.* instead of foo.dll. Just place them in the same folder and the transition should be smooth. Path seperators. On Linux (and Mac) there is a different path seperator (/ instead of \), if you use the build path and strip path functions there should be no problem. I think that if you contact your local NI office you will be able to have an evaluation version of LabVIEW for Linux. Ton

Sorry to hear that, I wouldn't ask them about using vi.lib stuff (and just ask the lawyers if they use template letters). What I would like to do (and most of the time do), is keeping the source of the library under SCC, and make a build that namespaces the product. Essentially that is the important thing, your reuse library is a product! And you are it's prime client, so treat your reuse library like you would treat your commercial products. Keeping the source and the built version seperated means I can edit the source and run tests on it without breaking existing code. Another point is recompiles, these happens quite often in LabVIEW (a .x.1 release, patch, new .Net interface) and you will get a lot of commits that are essentially useless. Using a distribution makes it also possible to move the code in a good way to another computer that is not networked or even from a client. You could even use NIs installers to distribute your reuse code. Ton

Well your code needs more structuring. One example is where you store the data inside a daily file. I would advice the following sub VI: Where you open a file based on the day. Some other improvements: The code above and under the line should be the same. Using less nodes should make your code better readable. In the same way I have the feeling that your write actions could be sub-vi'd Ton

I should have make it more clear but the XControl I linked to uses the windows messages for this.

I know that someone posted an xcontrol with this functionality. ton

How are you dealing with multiple LabVIEW versions? Ton

What I have done in the recent betas (8.6 and 9.0) is testing my own tools that I (daily) use, and look at the discussions in the beta forum. Also checking out some of the new features is something to doe. I don't have a set of tests/code that I use for evaluating the beta. Hopefully NI has allready sifted out the biggest misses, however we all know they can't cover everything. I have hardly seen issues like Rolf describes them but if I understand it correctly recent versions of toolkits will be better multi-version ready. Ton

If there is an event structure (maybe only when an event is registered for a control Ton

You probably have two webservers active on the same port (80 the default), try changing the port on either one (development environment or executable). Ton

<br><br><br> <br>Well I have sort of the feeling that the mechanism is broken.<br>The bug list is impossible to maintain, very hard to search.<br>The known issues list is <b>incomplete</b>, and I don't really feel like nagging about the list of issues I have. I pay a good deal of SSP, and I hardly use support, so I prefer them to use that money to fix stuff (I know a single SSP is hardly enough to investigate a bug), that's why I don't really like the new 'ideas exchange' I see a lot of 'nice to have' features that cost resources that can be used better (in <b>my </b>opinion).<br><br>Since we can't look into the CAR database we cannot see what the status of an issue is. <br>I know LabVIEW isn't open software but something better traceable would be very nice.<br><br>Ton<br><br>

With the LabVIEW embedded module you can create ANSI C code from your LabVIEW code, however a lot of functionality is not avalaible. Why do you need your code as C/C++? You could build a DLL from your VI and call that from C. Ton

In response to a LabVIEW feature request I was exploring an LVProject file for the build path. And I noticed LabVIEW supports some symbolic elements: The element NI_AB_PROJECTNAME is the actual project title. I wonder if there are more of these options available. Ton PS this was seen in LabVIEW 2009

Scripting is not meant to be used in an executable, since in 99.9 % of the cases it needs VI to be recompiled, a function not available in the Run Time Engine. Please mention any cross-posting you do Ton

Hi, you should place the vi/probe in the 'LabVIEW Data\Probes' or in the 'user.lib\_probes' to get the probe in the menu. In the '2-Controls' option you can also select the browse option. Ton

Are you sure it is the NI community spell checker, and not Google or some other browser plugin? Ton

Since you don't want to learn LabVIEW I would stay with Signal Express. for your acquisition. If you want to stay in LabVIEW (and don't want to learn) I would never do what you did, take an Express VI and convert it to editable code. Just try to reconfigure the Express VI. Ton

Nope, you set the reentrant type of the deamon VI, however LabVIEW 8.2 only supports plain reentrancy (reallocate), so you need to remove this property from you 8.2 version (I don't see any real harm done by creating a specific clone per structure, it is in a VI always active, and it will be killed when the VI is closed (I hope). However I couldn't find the rename option (8.2), how should I do a rename? I was hoping for F2, or a right click option. Ton

So what you did is writing an extension for LabVIEW, and now you can't afford LabVIEW anymore. That is what it basically sounds like. If your customers want you to do support/development you can force them to pay enough to get you a LabVIEW license. Or you get a debug license for them. If your product is unique enought (and you protect your IP well) you can ask anything you want. However I can see the reactions of your clients if you go that route, Maybe the alliance partnership is of interest for you, I believe you get some discount per sold item. Try to make your value valued! One question why do you need to keep up with the latest version of LabVIEW? You can develop the code in version 7.1 for instance and when a new version comes out, download a trial version and see if your code still works. Ton

A twist might be the following scenario: Using OGPB, use a pre-build VI, this pre-build VI will alter some values in a pre-install VI (the installation directory for instance), and will save these values as the default. This Pre-build VI is not included in the OGP file. VIPM definitely supports pre/post install VIs. Ton

I have had it installed with the Beta, so I think the released version will work as well. Still have to make the official transition. Ton

Any status updates? In the meantime I configure my RSS reader to keep 'old' messages in memory. Thanks, Ton

I checked the source code of the OGPB and the pre and post-build VIs don't get any parameters. I think it is quite save to say that nothing is sent in the other VIs. Checking the pre- and post - install VIs should be done with the source code of OpenG commander. However I think that VIPM tries to read the 'error in' and 'error out' controls if they are available. Ton

Even better is the 'Edit Cell?' event. You can discard the actual editing before the characters are shown. To be fancy I would sound a 'beep.vi'. Ton

At least DAQmx has a property that returns the version of the daqmx driver, I suppose the other drivers have similar interfaces. Ton