LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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


@JÞB wrote:

 Exactly. 

 

The context in which the process runs and NOT the OS bitness.  


Err?? Yes I use the context in which the process runs but only if the executable is a 32 bit program. Otherwise it is clearly a 64 Bit OS. If the 32 bit process runs in the SysWOW64 context, then it must be a 64 bit system too. Only if SysWOW64 returns FALSE, is it a 32 bit OS.

 

I do use the context but conditionally!!

 

Basically:

 

if (process == 64Bit)

    return 64_bit_OS;

else if (SYSWow64 == TRUE)

    return 64_bit_OS;

return 32_bit_OS;

Rolf Kalbermatter
My Blog
Message 331 of 361
(1,647 Views)

Facepalm


"Should be" isn't "Is" -Jay
0 Kudos
Message 332 of 361
(1,635 Views)

@JÞB wrote:

Facepalm


If it makes you feel any better, I was very much tempted to "fix" the VI after having it downloaded and looking at it. Only after thinking it completely through and running it to verify the fix and finding that it worked wrong, did I realize that it had been correct before! Smiley Very Happy

Rolf Kalbermatter
My Blog
0 Kudos
Message 333 of 361
(1,624 Views)

 


@rolfk wrote:

@JÞB wrote:

Facepalm


If it makes you feel any better, I was very much tempted to "fix" the VI after having it downloaded and looking at it. Only after thinking it completely through and running it to verify the fix and finding that it worked wrong, did I realize that it had been correct before! Smiley Very Happy


Yes, I got caught with the similities to the gem and totally missed the minor but somewhat pointed difference


"Should be" isn't "Is" -Jay
0 Kudos
Message 334 of 361
(1,615 Views)

On to the next nugget, please! 

 

How's this?:

 

Control-double-click a VI's icon to open its block diagram.

 

This can be useful for closing hung VIs during development:

 

If you have a VI that is hung but has not crashed LabVIEW, and the VIs stop button is not shown, you can quit the VI by opening a new VI, putting the hung VI on the block diagram, and control-double-clicking the icon to open the hung VI's block diagram. Press stop.

_____________
Creator of the BundleMagic plugin for LabVIEW!
Message 335 of 361
(1,557 Views)

@littlesphaeroid wrote:

On to the next nugget, please! 

 

How's this?:

 

Control-double-click a VI's icon to open its block diagram.

 

This can be useful for closing hung VIs during development:

 

If you have a VI that is hung but has not crashed LabVIEW, and the VIs stop button is not shown, you can quit the VI by opening a new VI, putting the hung VI on the block diagram, and control-double-clicking the icon to open the hung VI's block diagram. Press stop.


Here is a "force multiplier" for the micro-nugget.

 

That will also work from the VI Hierarchy screen and if you hit "ctrl-a" it will also show re-entrant VIs that where launched dynamically and running top-level. So your trick will let you open the diagram of the one instance you want to investigate.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 336 of 361
(1,547 Views)

You can use the CTRL+Double click on running VIs as well, but you need to turn auto tool off since CTRL functions differently when it is on, switching to the breakpoint tool.  As for aborting running VIs I use my LabVIEW Tray Launcher which (among other things) has a way to abort all VIs, in all versions of LabVIEW, except for asynchronous clones at the moment.

0 Kudos
Message 337 of 361
(1,528 Views)

I use this vi that I found a while ago. Simply run this (double-click it) whenever needed.

 

I take no credit for it whatsoever. If it is yours, I salute you and would like to say a big thank you for it. It has got me out trouble quite a few times during development. I hope you don't mind me sharing it here.

0 Kudos
Message 338 of 361
(1,493 Views)

@sebster wrote:

I use this vi that I found a while ago. Simply run this (double-click it) whenever needed.

 

I take no credit for it whatsoever. If it is yours, I salute you and would like to say a big thank you for it. It has got me out trouble quite a few times during development. I hope you don't mind me sharing it here.


CAUTION: the attachment above is saved with "Run When Opened"=True!


"Should be" isn't "Is" -Jay
0 Kudos
Message 339 of 361
(1,442 Views)

Apologies!! I forgot I had it set that way when I saved it on my system for ease of use.

I've re-saved it with this option set to False.

Message 340 of 361
(1,430 Views)