LabVIEW
Micro-Nuggets !!! ~~~~ Post 'em if you got 'em
@Robert_J_Loomis_III wrote:
Probably a better way to do this, but I always set the front panel runtime postion to zero everytime I run my top level VI.
You are using a deprecated property. You really get the Front Panel reference to then get a reference to all of the panes (Panes[]) and then use a FOR loop to set all of the panes' origin to (0,0).
Also, wire up the error clusters to your property nodes.
Good point crossrulz, but his point is still a good one. When running from the development environment, some approach to acheive a centered GUI is a must. Other methods include sizing the screen to the largest decoration or content, easily done with the drop of a VI from Open G.... the VI's are
- Fit VI window to Content.vi
- Fit VI window to Largest Dec.vi
Also try RiteSize.vi by kDy automation.
Gah! Here's one that's been plaguing me for weeks until I had a real "aha" experience yesterday.
If you're going to use Occurrences, make sure they're valid before using the timeout function to stop a loop hogging CPU resources.
I had made the mistake of introducing a nice race condition in my code where I was initialising an Occurrence and writing it to a control (to allow VI Server access) and then using a local variable fo this control to pass the value into a loop timed via the timeout function of the occurrence. Problem was that the local was read before the control was written and I fed an invalid reference to the occurrence function in the loop. This ran as fast as possible (showing a timeout had occurred which was actually expected behaviour). IT was consuming my CPU completely and of course in debugging mode everything seemed normal. Only when in utter desperation had I performed an automatic "Block Diagram Cleanup" die I notice the race sondition. Fixed it and bang, no more CPU hogs. Given the absence of an error out, either make sure to always check for occurrence validity or use a different loop timer.......
Following loop will eat up the CPU but give little indication that there is a problem....
Shane
I couldn't find a modern discussion of how to get the screen coordinates of a control, especially if Panes are involved. The Panel to Screen coordinates Method does not take into account the menu and toolbars. But using the reference to a control you can get the panel and pane references and do the needed transformations to get the correct screen coordinates of any front panel object. I've attached a utility VI to do this.
I have to give credit to Darren for figuring this out with us at the CLA Summit. Sorry I never thought about making a nugget.
Ever wanted to place multiple controls on the front panel at the same time (like error clusters)? It turns out that you can. While editing your Controls Palette, insert a custom control. In the ensuing dialog, change the file type to "*.*". Choose a VI. VIs are defaulted to place VI contents when they are being put on the front panel.
So I took the next step and made my error cluster VI a quick drop shortcut as well ("ec"). So now when I create a new VI, the very first thing I do is Ctrl+Space, ec, and drop my two error clusters. I then have to move them to where I want them, but at least I'm not placing two error clusters down at a time.
Just for fun, I just tried to use Select a Control from my palette and select a VI. It doesn't work. It apparently only works for items in the palette.
