LabVIEW
CTRL + Mouse Drag on FP Does Not Register as Event to be Saved
Looked for this in known issues and was a bit surprised when it wasn't there.
Issue:
When using CTRL + mouse drag to add space between FP objects (or CTRL + ALT + mouse drag to remove space), the action does not register as an event that needs to be saved.
Steps to Replicate:
1. Make a VI with two controls on it and save.
2. On the FP, use the CTRL + mouse drag action to add space between the controls.
Expected behavior: When closing the VI, there is a request to Save or Not Save
Actual behavior: There is no request to save the VI, and closing and reopening undoes the action
Using LV2017 and LV2020.
Doing the same thing on the BD results in the expected behavior.
I had a wire connecting them on the BD, if they are just floating by themselves I also don't get a dirty dot for the BD in 2017. But of course, straight up moving a control/indicator will trigger it, FP or BD, connected or not.
Not a huge thing, just noticed it after doing some code cleanup when the FP of one of my VIs hadn't saved (CTRL + drag was all I did on it, I do code cleanup in steps: all BDs, then all FPs, then all documentation, so on).
Figured I would mention it on here just in case it's an easy fix for the devs.
@JÞB wrote:
@FireFist-Redhawk wrote:
I had a wire connecting them on the BD, if they are just floating by themselves I also don't get a dirty dot for the BD in 2017. But of course, straight up moving a control/indicator will trigger it, FP or BD, connected or not.
Not a huge thing, just noticed it after doing some code cleanup when the FP of one of my VIs hadn't saved (CTRL + drag was all I did on it, I do code cleanup in steps: all BDs, then all FPs, then all documentation, so on).
Figured I would mention it on here just in case it's an easy fix for the devs.
WARNING. DON'T sip your coffee
I just have to mention that your workflow is backwards. You knew that was coming! The only time for the paper work to be done last is... yeah, I'm not going to straight up say it.
Hahaha, I get your meaning. My thought on the matter is that it's easier to think of a succinct description of a VI when you're looking at the cleaned up version of it than when looking at the somewhat messy version. In a perfect world, I would document while creating and make things look nice to begin with. But a perfect world this is not.
@RavensFan wrote:
You're right. The example I created for 2020, I just through some nodes on the block diagram and didn't bother wiring them. It did not trigger the dirty dot. Based on what you said, I wired a couple. Then stretching or shrinking on the BD did cause the dirty dot. But you're right, stretching or shrinking on FP does not trigger a dot.
I think it probably should trigger the dirty dot because you did explicitly make a change to the position properties of some of the entities.
Yeah I feel the same. Good thing it was one FP and not ten. Might have been a bit annoyed in that case.
It's easier to clean your room by cleaning up after yourself every time you make a mess, instead of waiting until the mess is intolerable. Why I do this with block diagrams and not my room is beyond me.
