Jim Kring

I was just informed by someone at NI (thanks again, Darren!), that the LabVIEW documentation calls them Functional Globals. You can find this in the help, here: Fundaments >> Multitasking, Multithreading, and Multiprocessing >> Concepts >> Suggestions for Using Execution Systems and Priorities Synchronizing Access to Global and Local Variables and External Resources >> Functional Global Variables You can also find a few references to them in the help if you search for "Functional Global" (include the quotes when you do your search).

Because the Austin Convention Center is (probably) cheeper in August. The weather is very hot -- it can get up to 110 degF! And, it is easier for people to take a week off of work during the summer.

7.1 and 7.1.1 are compatible. However, they will be re-compiled when moved between these two versions.

I have created a poll. Let's find out what the consensus is.

Hey Jason. I don't see anything related to the Plot Area that shows any hope of changing the plot group title. I haven't had an opportunity to use the mixed signal graph, but I'm looking forward to it -- it's a pretty powerful UI component. The multi-plot cursor feature is very cool, too. Cheers,

Wrong. http://web.archive.org/web/*/http://lavausergroup.org

David, I use SnagIt.

Look deeper.

Hmmm... they are only functional or intelligent if you put some functionality inside of the case structure -- for example, by having operations besides Read Data and Write Data, such as Initialize, Do Task A, Do Task B, etc.. If there is no intelligent functionality in them, does that make them dysfunctional globals or unintelligent globals? I am, of course, being a little silly -- discussing LabVIEW should always be fun I think that I am leaning towards functional globals. This term just implies that they have some functionality -- I wouldn't want to put too much pressure on beginners by making them think they have to write code that is intelligent Thank you both, Philippe and Franz, for the ideas. I owe you each a frosty one :beer:

LabVIEW 2 Globals is a term used to describe the usage of uninitialized shift registers to store data in an application. This name comes from the fact that LabVIEW 2 did not have global variables and clever developers figured out that they could use uninitialized shift registers to store data, and make it globally accessible throughout the application. If you had to introduce this concent to a new developer, what would you call LV2G's? Obviously there is some historical significance to the name, but it doesn't do much to describe the concept. How about "Uninitialized Shift-Register Globals" or "Uninitialized Shift-Register Data Store"? Any thoughts? Cheers,

That's OpenG Commander. Read the Quick Start Guide for instructions on how to install and get the OpenG goodies into your system.

To start, visit the OpenG Commander page and see the usefull links to get to the Download, Quick Start Guide and Manual. OpenG Builder is also pretty well documented. It is a replacement for the LabVIEW Application Builder, but it does a whole lot more. You should note that you still need the LabVIEW Application Builder if you wish to build EXE's (OpenG Builder uses the LabVIEW Application Builder for this feature). OpenG tools are very well written, and can be trusted about as much (hopefully more) than stuff coming out of NI -- we even have packages that patch bugs in vi.lib (VIs developed by NI that ship with LabVIEW). And, if you have any problems we are more than happy to help get you rolling -- we have a support forum here.

G'day, Chris! Actually, my set up is a 1600x1200 and a 1900x1200 -- only 60 pixels (wide) shy of 2560

Now, that's big! Dell's new 30" Widescreen does 2560x1600 -- that's almost as good as two 1600x1200's side-by side.

You should check out the Variant Configuration File I/O VIs from OpenG. These can read and write anything to an INI file (clusters, arrays, etc.). Download OpenG Commander and make sure that the variantconfig package is installed.

LabVIEW does not support this directly. You will probably need to call external code to achieve this.

It looks like it might be a bug in the Read LabVIEW Measurement File Express VI. Can you attach and example of the file, and the VI that you use to read it?

There is a trick. In the menu activation event frame, you can obtain the tag of the item that the user right-clicked on. Use the Tree's Point To Row Column menthod: When integrated into your code, it looks like this: Here is your example, with my edits: Download File:post-17-1136743870.vi

Here is a quick update: there is a good discussion going on the cross posting I made to the NI forums. I got some very useful information from Jeff and Darren, two NI developers, including some information on some vi.lib/tree/ VIs in 7.x that provide very useful functionality, including that provided by the "Point to Row Column" tree method of 8.x.

I got a response from the developer at NI, who worked on the new drag and drop feature. This addresses all of my questions. Also, it was great to learn of the new Point to Row Column method of the Tree Control -- this is also present in Listboxes and Multi-column Listboxes, too! That's a feature that's been needed for quite some time.

There is an option in the VI properties dialog to hide the toolbar while the VI is running. File >> VI Properties... >> Window Appearance (category pull-down) >> Customize (button) >> Show Toolbar When Running (checkbox)

This is used for calling functions in shared libraries (DLLs, in Windows). There is documentation on this in the LabVIEW help.

I've got some concerns with drag and drop events and how they relate to the tree control. Here is a simple use case: drag and drop nodes in a tree control. In order to do anything useful beyond the degenerate case of allowing all nodes to be dragged and dropped on any other node, I need to know the Source Tag and the Target Tag (to both validate and process these events, I need to know which item was dragged and dropped onto which other item). In LabVIEW 7.1 Source Tag and Target Tag are available as event data. However, in LabVIEW 8.0 the new control drag and drop events supersede the tree control drag and drop events (the tree drag and drop events have been depreciated and a warning dialog will be displayed when opening 7.1 code that calls these events). OK, here is the problem... there are no longer Source Tag and Target Tag event data in any of the LabVIEW 8.0 tree control drag and drop events. I have found a work-around by writing a routine that calculates which element the mouse is hovering over, but this is very non-direct and a bit of a kludge. Another issue is that the source item disappears from the tree control after the drop event is processed. This is not the end of the world (I can recreate the deleted node and child nodes), but it is still a bit of a pain and I believe that this is a bug. So, am I off-track? Any thoughts? (I've cross-posted this question to the NI Forums, to possibly get a resonse from someone at NI)

In LabVIEW 8.0, the Flatten To String function has an option called Convert 7.x Data that causes the familiar type descriptor output to appear. According to the documentation... My question is this: If LabVIEW 8.0 and later stores type descriptors in 32-bit flat representation, how to we access LabVIEW 8.0+ type descriptors? Has anyone found a way to access and decode these? It seams like the documentation is recommending that we "rework" for this new format, but I can't seem to find anything that leads down this trail.

It was a rhetorical question.