LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Micro-Nuggets !!! ~~~~ Post 'em if you got 'em

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.

Message 231 of 361
(2,653 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 232 of 361
(2,633 Views)

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.

 

Richard






Message 233 of 361
(2,612 Views)

Appreciate the feedback, thanks.

0 Kudos
Message 234 of 361
(2,568 Views)

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....

 

fast occurrence.png

 

Shane

0 Kudos
Message 235 of 361
(2,415 Views)

I would simply suggest not using occurences at all. I think they're only around for backward compatibility. You can get the same functionality using a notifier.


___________________
Try to take over the world!
0 Kudos
Message 236 of 361
(2,408 Views)

Not if the occurrences are already implemented in lots of dependent legacy code....

0 Kudos
Message 237 of 361
(2,406 Views)

@tst wrote:

I would simply suggest not using occurences at all. I think they're only around for backward compatibility. You can get the same functionality using a notifier.


I using occurrences for transferring notification from callback function, which is called in my DLL - this is really simplest way. Sure, this can be done also with notifier, but occurrences in this case much easier, because they are typeless - just call Occur function from DLL and it is. In case of notifcation I will need to code a little bit more code.

0 Kudos
Message 238 of 361
(2,399 Views)

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.

 

 

control position.png

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 239 of 361
(2,320 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 240 of 361
(2,218 Views)