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.
LabVIEW
Annoying behavior LV 2018
Solved!
In LV 2018, when I drag a control around, LV 2018 wants to "try everything along the way", which includes trying to insert it into every control along its path as it goes by, sometimes resulting in a LV Crash - "We apologize..."
I'm guessing this probably happened earlier with the advent of real-time editing updates back in LV 2016, and can probably be avoided by turning that feature off.
Just ran across it now, so it must be some unique set of events. The workaround, of course, is to avoid the control that crashes it. 😉
I'm surprised someone actually replied to this. When I drag a control across the front panel, LabVIEW tries to be "proactive" and try to insert it into every cluster or array control that it passes over in "real time". Sometimes this leads to a LabVIEW crash. If you turn off the real time editing feature (I forget what it is formally called), it will show an outline around the control you dragged over, but it won't try to actually insert it.
To reproduce:
Drop an error cluster onto the front panel.
Create any kind of control.
Drag that control over the error cluster, but don't drop it. You'll see LabVIEW frantically trying to anticipate you dropping the control inside. The effect is a bit more subtle if you try to drag that control over an array.
Sometimes (although not in the example above) it will crash LabVIEW.
An option to wait until you drop the control for the recompile/redraw would be ideal.
If you're working on a 'busy' panel with nested tabs and controls, LabVIEW could be working a lot harder than its needs to.
I had a quick look for a hidden .ini setting and haven't found anything yet. Limiting compiler optimizations don't seem to have an effect either.
I'm curious about the real time editing feature you mention. Is it possible to disable this?
@pallen wrote:
An option to wait until you drop the control for the recompile/redraw would be ideal.
If you're working on a 'busy' panel with nested tabs and controls, LabVIEW could be working a lot harder than its needs to.
I had a quick look for a hidden .ini setting and haven't found anything yet. Limiting compiler optimizations don't seem to have an effect either.
I'm curious about the real time editing feature you mention. Is it possible to disable this?
I don't recall what the proper name for it is, but you know how LabVIEW used to just give you a dotted-line silhouette of what you are grabbing and moving (or copying)? Now it's "live", meaning the control you grabbed moves with your mouse cursor. Creating/deleting space on your FP/BD shows real time movement of the controls. You're supposed to be able to revert this feature. It probably would make the problem go away.
I see you understand exactly what I am talking about. I think sometimes LV works so hard trying to insert stuff in real time that it actually crashes because of it. Creating space in a busy BD could also cause a crash, which was why there was an option to revert in the first place. (I've never experienced a BD crash due to this issue because my BDs are never busy.)
It's cool to watch LV desperately trying to keep up with the insertions as you drag a control through an uber-cluster though. It deforms each of the cluster boundaries to try to capture your control until the control "leaves its air space", in which case it snaps back to its default dimensions. There must be some kind of cache that overflows when things get hairy and it crashes.
@Hamlet23 wrote:
Hey, billko
Seems to be okay for me (I am using LV 19 & 20 versions)
What version of LabVIEW do you use? Can you provide some video record?
With Best Regards,
The LabVIEW version is in the subject line. 😉 I'll describe in detail what happens because it's easier than making a capture:
As you drag the control over the error cluster, you'll see the error cluster deform to try to capture the control that you are dragging. Only after LabVIEW feels you aren't actually trying to insert the control into the cluster, the error cluster border snaps back to its original dimensions.
If you've disabled the real time updates, only a dotted line representation of the control you grabbed goes with your mouse, and the issue doesn't happen.
I haven't paid much attention to this for a while; I don't even know if it still happens in LV 2020. I guess I'll check it out when I get home.
I can't think of the exact term either.
I had a look for an INI setting and found this: https://labviewwiki.org/wiki/LabVIEW_configuration_file/Front_Panel#offscreenUpdates
That did...something. But not quite what I was looking for.
I also tried editor.liveUpdates
This did not seem to have any effect on the front panel.
I know this was first implemented in LV 2016. I also know there was a way to turn it off. I just can't remember how.
