From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Quick Drop Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Quick Drop Keyboard Shortcut – Arrange VI Window


@felipefoz wrote:

 

Is there a way to know if something has really changed (programatically) and maybe discard the * ? 


I have some ideas, but no convenient answers. I haven't tested any of those.

 

  1. Consider saving the VI before running this QD, and comparing the VI before and after QD, using this post as a starting point. If VIs are different, delete the original. If VIs are the same, delete modified VI.
  2. Rearchitect the QD VI by splitting analysis and coordinate computation from scripting that moves objects around and resizes windows. Only move objects and resize windows if there are any differences between original and computed coordinates or window sizes.

I would expect the first approach to be much easier to implement, if you can fit the change with your tooling; the second approach would be cool.

Kosta
Message 41 of 48
(1,379 Views)

@Kosta  escreveu:

  1. Consider saving the VI before running this QD, and comparing the VI before and after QD, using this post as a starting point. If VIs are different, delete the original. If VIs are the same, delete modified VI.

Great idea, that would also probably work, I might try this approach first. It should be pretty quick and I might reuse that for other comparisons too.

 

2. Rearchitect the QD VI by splitting analysis and coordinate computation from scripting that moves objects around and resizes windows. Only move objects and resize windows if there are any differences between original and computed coordinates or window sizes.


That would be a perfect solution, but that is going to take much more effort, right now I am thinking of not modifying the shipped plugin.

We should consider an update of this QD in the long run. 

 

Thanks.

0 Kudos
Message 42 of 48
(1,376 Views)

I just create a VI to collect some VI Properties used in this QD plugin. There must be a better way or I am missing some property. At least I learned a bit about the QD plugin. 😃

Get Properties.png

  And the function which calls this VI is this one.

compare if plugin changed.png

Apparently is solving my problem, but it might have some gotchas there that I am not aware of.

 

Thanks for the help so far.

 

 

0 Kudos
Message 43 of 48
(1,357 Views)

@Kosta wrote:

@felipefoz wrote:

 

Is there a way to know if something has really changed (programatically) and maybe discard the * ? 


I have some ideas, but no convenient answers. I haven't tested any of those.

 

  1. Consider saving the VI before running this QD, and comparing the VI before and after QD, using this post as a starting point. If VIs are different, delete the original. If VIs are the same, delete modified VI.
  2. Rearchitect the QD VI by splitting analysis and coordinate computation from scripting that moves objects around and resizes windows. Only move objects and resize windows if there are any differences between original and computed coordinates or window sizes.

I would expect the first approach to be much easier to implement, if you can fit the change with your tooling; the second approach would be cool.


I feel like something much easier than (2) but along the same lines would be to make a VI that gets an ordered list of all pertinent object coords/window sizes, wire it so it runs right before any scripting happens and right after, and compare. Fail the transaction if equal, end undo if not equal.

 

Thanks for the plugin by the way, it's awesome 😊

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 44 of 48
(1,180 Views)

Hey all,

 

Using felipe's "Get VI Properties_LV2015.vi", I made an update to the QD plugin to fail the transaction if the QD is used on a VI and nothing changes. Tested on some basic VIs and saved in 2017. Cheers once again, this plugin has helped me so much with big cleanup jobs.

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 45 of 48
(919 Views)

I noticed that sometimes the Arrange VI plugin misbehave when aligning Front Panel elements.

These elements end up overlapping each other after running the script.

 

I noticed that it happened mainly when the VI FP was closed, this means, running the scripting part only and not using the QD plugin.

 

Right now I can't reproduce the situation anymore, but I believe I have seen more than once happening.

 

Any clues what it could be?

 

Using LabVIEW 2017 SP1.

0 Kudos
Message 46 of 48
(175 Views)

Felipe,

 

I don't know why some elements end up overlapping each other after running the script when the front panel was closed. I did not test scripting code without having front panels open. If you run into the situation again, consider, as a workaround, opening front panels using scripting before calling scripting code from this QD plugin.

Kosta
0 Kudos
Message 47 of 48
(169 Views)

@Kosta  escreveu:

Felipe,

 

I don't know why some elements end up overlapping each other after running the script when the front panel was closed. I did not test scripting code without having front panels open. If you run into the situation again, consider, as a workaround, opening front panels using scripting before calling scripting code from this QD plugin.


This workaround didn't work. I was faced again with this bug now. Unfortunately I can't share the VIs, however I am trying to create something I can share, but as of now I can share some of my findings:

  • The plugin works fine when using only on the offending VI.
  • It seems that bug shows after running on another VI first, so the offending VI is the second in the scripting path input array. If it is the first, then it works fine.
  • The issue seems to be on the "Arrange FP Controls.vi".
  • If I disconnect all terminals on the first VI (except error terminals), then the plugin executes correctly in the second VI.

My suspicious is that somehow it is keeping state somewhere between calls. I might be wrong of course. Can anyone help me with the provided information?

 

Using LV2017SP1 (reproduced also in LV2022Q3)

 

Edit: a workaround is to use call by reference. Make sure you close the reference, otherwise it will not work.

0 Kudos
Message 48 of 48
(80 Views)