Shaun Hayward

Are any VIs that include the Xcontrol (either as a variable, or on the front panel) loaded and/or open? If so, try making sure all other VIs are closed before you build - this solved an error that I had that looked similar (I cant remember the exact code). Shaun

My guess would be to create a boot-strapper app that is written in something other than LabVIEW - that could check for the presence of LabVIEW RTE / any other dependencies, and then, call your main EXE once it's checks are complete. This could probably be neater still if the main application was compiled to a DLL target instead of an EXE - then your users would just see a single EXE / point of entry to the app. (PS. I really hope there is a better way to actually get at the LV built exe's dialog directly, but I doubt that would actually be possible)

Maybe, when you initialize your active objects you could keep a registry (functional global / whatever) of the ones you launch? Then, you could use this whenever you want to do your action.

Could it be something to do with the "remove unused library members" option (or whatever it is called)? Maybe App Builder is trying to modify the library in the build and cannot because it is pwd protected?

I came across something once - basically, if you change a parent class's VI's terminals from dynamic dispatch to non-dynamic dispatch (I used the right-click-replace) then that VI will no longer be overridden-able... however, if you had previously marked that VI as "Must be overridden" then you will find out that the "must overide" flag does not get reset. The end result is a VI that simultaneously must be overridden and cannot be overridden = broken class. To fix it, replace the non dynamic dispatch with dynamic dispatch terminals, remove the "must overide" flag and start again.

There's a great free (although it also has a paid "pro" version) subversion server called VisualSVN Server (http://visualsvn.net/server/) - it is super easy to modify repositories, etc and even plays nicely with Active Directory if your on a Windows Domain setup. Shaun

Your question is a little vague (kind of like asking "how much would it cost to develop a test system?) - It totally depends on what instruments you have, how you physically connect to those instruments, what APIs you are using, etc. In similarly vague terms, you could create a step to check the presence of your instruments, store the result in a variable and then use that value in your sequences as part of your logic (be it, warning your user or skipping steps when running sequences).

I achieved an effect similar to what you are describing by placing all of my charts in an xcontrol with appropriate, draggable splitters. Each chart was set to "Fill Control to Pane" and then, as far as the top level VI was concerned there was only 1 control to resize (which seems to work MUCH nicer).

Yet another casualty:

There's also a really handy function lurking in the comparison palette called "In Range and Coerce" which could certainly help you out a little bit: Shaun

LabWindows/CVI does not get used "in LV" but is an alternative, non-graphical development environment from National Instruments. It features an ANSI-C compiler and is basically a C IDE with a whole bunch of libraries to make creating user interfaces and handing measurement/test tasks (such as DAQmx) easier. As far as whether it's easier/more flexible / etc -> In my opinion that's more of a preference (unless your in a field that REQUIRES code to be developed in a textual language such as C), but for me personally, LabVIEW wins hands down.

If your using LabVIEW 2009 there is another useful tool to throw in the mix: This little guy, found in the File IO:File Constants palette will do one of two things: 1. In development environment it will return the folder containing your Project (*.lvproj) file 2. In a built application is will return the folder containing your application's EXE

Although, and I right in presuming that if one were using an object instead of a regular cluster, even if the defaults were large strings / arrays, the additional memory allocation would only be 1 pointer-sized int?

Is there any way to programatically point LabVIEW's lock elsewhere (ie without poping up a file browse dialog)?

I remember reading something about this a while back but cant seem to dig is up with the search.... I'm running into an issue whereby browsing to a file in a LabVIEW path control seems to stop me from deleting that folder from any other part of my program until (a) LabVIEW is closed, or (b) I browse to a new path with the control in question. As I said, I remember reading something, somewhere about the fact that LabVIEW keeps its current directory open (and therefore undeleteable) but I guess what I really need to do is point LabVIEW to a different current folder so I can delete the folder in question. Any ideas? PS. If it helps, my use case is this: 1. User has a data folder with a database file and a whole bunch of subfolders containing data thats too large for me to want to put in a DB record (such as hi-res images). 2. A User picks one of the files within the folder hierarchy to display in LabVIEW.... file is openned (file is also closed afterwards) and image data is displayed in a picture control. 3. User now decides that they want to move this entire dataset do wants to delete the database file and all associated content. 4. the LabVIEW move file/folder VI generates an error because it does not have permission to move the file 5. Trying to move the file in explorer also fails until LabVIEW either has a path control value change (using the browse button), or LabVIEW exited.

OK... I got intrigued by this whilst waiting for an installer test to finish running and came up with a little something that works: Hope this helps, Shaun

In that case, ignore my comments about the "must override" option -> this isn't available in LabVIEW 8.5. As an alternative, I often have my parent VIs return one of two error codes - one for the "you really must implement this VI" error, and one for the "this optional feature was not implemented error". The downside with this approach (when compared to LV 2009) is that you only find out about the missing important VIs at runtime. Here's a back-saved version of my example. Shaun Framework Example.zip

I've attached a little example of what I was talking about. LabVIEW does select the appropriate VI, but the raising of an error is used to tell the main application that whatever was requested did not get done because that particlar amp does not support the particular function. In the attached example, Apmplifier specifies that all child objects must override Init and Power On-Off, ie if they dont have these VIs then everything will be broken (this is a really nice improvement in LV 2009), however, the "Set Volum.vi" is "optional". The base class's version of this VI simply generates an error, so if a child classe does not replace this VI with something else, the error will be generated (if the VI is replaced, then the alternative functionality will be used instead). Hope this helps! Shaun Framework Error Example.zip

To work be able to wire your generic "Amplifier.lvclass" wires to the commands of the specific amplifiers, then yes, you will have to create the dynamic dispatch VIs in the parent class. One thing that I have done in the past for such "not always implemented" functionality, is to have the parent VIs raise an error for "unsupported function" (using whatever custom error code you feel like) - that way, if the specific child amplifier class does not implement a particular command, you will get a known error that can be nicely handled by the rest of your app. If your using LV 2009, this can then be nicely extended using the "must override" checkbox in the class "item settings" property to say that certain functions (such as init, or power on/off) must always be implemented (if those VIs are not replaced then you will actually have broken run arrows).

Do you have any OOP experience outside of LabVIEW?

Wow - thanks Tom! There's definately a lot there for me to chew over (and come up with some ideas)! Unfortunately, due to time / $$ constraints and the fact that I'm creating a new app that is going to be an upgrade to a very old and bloated LV 7 (if not earlier) app, I think for now I am going to have to stick with the depreciated events as they are so much easier to get the right look and feel. Still... next time I get a spare movement, I'm going to definitely have to look into this some more!

Thanks Ton - It seems that you are right, if I put in all of the drag and drop code manually with all of the events I might be able to get it to work with the non-legacy event structures.... However, I dont suppose you (or anyone else for that matter) know(s) if there is a way to get the visual feedback (or even something similar to) that one gets with the built-in drag/drop handling?

OK it looks like I've found a hack work around to the LV 2009 tree control drag/drop events: copy and paste a tree control and it's associated event structure (including "Drag?" and "Drop?" filter events from an application written in an earlier version of LabVIEW -> these *seem* to work, but as it's dinner time, I'll have to wait until tomorrow to give it some proper testing. PS> If any one else goes down this route, remember that if those "Drag?" and "Drop?" filter events are deleted they cannot be recreated in LV 2009!

This has been raised to R&D with a CAR of 202287. (If any of you have an idea for a work-around in the mean time I would greatly appreciate it!

I have a tree control that represents a bunch of data from a database. A user must be able to logically re-arrange that data using drag and drop. I therefore want to catch the drag / drop events to determine: 1. During the drag, is the current potential drop location valid? 2. At the end of the drag, was the database update successful? (if not, I want to discard the drag/drop action). I seem to be running into a big headache with the necessary tree control filter events in that: A. Adding a drag over event seems to be discardign the drag/drop action B. The drop filter event seems to be causing nodes to vanish. I have made a slimmed down VI (ie with everything but the tree control removed), and made two tree controls (one with the drag over event, and one without) to demonstrate the problem. I would really appreciate any ideas as to what is going wrong! (LV 2009) Thanks! Shaun (I have also put in a support request to NI, so if they come up with a solution, I'll be sure to post back!) Debug - Drag and Drop Test.vi