LabVIEW
[Bug] Window move within undo transaction
Hi fellow developers,
I was developing a quick drop that, among other things, sets the FP/BD windows bounds of a VI based on their content.
Since it is a quick drop, I would like to wrap all the scripting inside an "Undo Transaction" to allow the user to undo the modifications.
Just with these simple requirements, I noticed several unexpected behaviors with the scripting:
1. FP bounds change not correctly included in undo transaction:
If you write "FP.WinBounds" or "FP.PanelBounds" properties right after the "Transaction.Begin Undo", it is not actually enclosed within the transaction like the rest of your scripting. Instead, it is aggregated with whatever previous action the undo stack contained (which may have nothing to do with your scripting). Then, if you undo both your scripting transaction and the previous action, the window is only resized to its original size, but not moved to its original position.
> Workaround: insert a dummy scripting action (like set all panes to their origin) between the "Transaction.Begin Undo" and the writing of the FP bounds.
2. Undoing a transaction than contains an FP bounds change can cause graphical glitches or a LabVIEW crash:
Even if you use the workaround from (1.), undoing an FP bounds change can also cause graphical glitches (FP not drawn correctly) and even crash LV in the worst cases.
> No workaround.
3. Undoing a transaction than contains a BD bounds change does not undo it:
It seems a BD window move/resize is completely ignored by the undo stack (either programmatically or manually).
However some built-in IDE functions that change the BD bounds CAN be undone. For example: Window > Tile Left and Right, Window > Tile Up and Down, Window > Full Size, ...
> No workaround.
(1.) and (2.) clearly seem like bugs, (2.) being the most critical, while (3.) may be a design choice (but I would still like be able to undo a BD bounds change!).
While I am reporting this to NI, has anyone found a workaround for (2.) and (3.) ?
Tested and reproduced both with LV2020 (32bit) and LV2025 Q3 (64bit).
Attached are code examples to reproduce each issue.
Regards,
Raphaël.
