Quick Drop Keyboard Shortcut – Arrange VI Window

[Kosta]

---

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

[felipefoz]

---

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

[felipefoz]

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

  And the function which calls this VI is this one.

 

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

Thanks for the help so far.

[FireFist-Redhawk]

---

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

[FireFist-Redhawk]

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.

[felipefoz]

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.

[Kosta]

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.

[felipefoz]

---

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

[Darren]

FYI I think I figured out the race condition, and I posted fixed versions of the VIs to the Nattify plugin (which uses Arrange VI Window) here: Re: Quick Drop Keyboard Shortcut - Nattify VI - NI Community