LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug? - Loosing focus when changing control <Description> property

Hi,

 

I found a weird behaviour in LabView (ver 2014, but might be also in newer versions) - when changing programmatically the property <Description> on some component the focus on other components is lost. Spent some time to pinpoint the problem and wrote the following sample code to highlight it

Focus error.png

After you run the VI select the text in one of the edit boxes and you'll see that each 2s the focus is lost, exactly when Description on LED component is changed. If you continue typing in the box you'll notice that in one moment you exit the edit mode (control not anymore on focus).

 

Is this a bug or the expected behaviour? Thanks

 

0 Kudos
Message 1 of 5
(378 Views)

@peter111 wrote:

Is this a bug or the expected behaviour? Thanks


Those are not mutually exclusive 😁.

 

FYI, It's still there in LV20.

 

I don't see a way to not get this behavior, except to avoid it programmatically.

 

A crude way (sorry, can't make LV14 snippets):

Skip Description if String Has Focus.PNG

This isn't exactly the same of course. There might be better solutions, but that all comes to details of what you want exactly (and why).

 

You'll have more options if you have an event driven program, but it won't be pretty nor perfect.

 

For instance, in stead of updating the description constantly, you can buffer the description and set it when the user right clicks the control to get the description. This won't update the context help though.

0 Kudos
Message 2 of 5
(367 Views)

Hi,

Thanks for the idea.

What you suggested is to prevent updating of the Description property if any or some of the controls were focused - it can be used as a patch in some cases. As I was in hurry I changed the code not to use the Description anymore .

 

Description property can be very useful when dealing with single event from multiple controls - you can place into individual control's description properties any values (including flattened arrays or structures) and then get this data out in the event. Description property reminds me on Tag property in Delphi.

 

The bottom line is - this is a LabView bug, right? Nobody is expecting to change some "innocent" component property and to loose the focus on the panel.  

 

 

0 Kudos
Message 3 of 5
(357 Views)

@peter111 wrote:

Description property can be very useful when dealing with single event from multiple controls - you can place into individual control's description properties any values (including flattened arrays or structures) and then get this data out in the event. Description property reminds me on Tag property in Delphi.


That is creative...

 

You'd usually use labels to find out which control was triggered.

 

You can use captions if you need the text to change. Or use a shift register to store this info. Or actual tags (enable scripting or use some unexposed lvlib VIs).

 

You can compare\search a reference (from an event) to a list of static references to find the used control.

 

Lots of alternatives.

 


@peter111 wrote:

The bottom line is - this is a LabView bug, right? Nobody is expecting to change some "innocent" component property and to loose the focus on the panel.  


Bug implies unexpected behavior, not (just) undesired behavior. The behavior probably is 'undefined', so undesired behavior is hard to qualify as bug...

 

Even if it becomes a bug, it's been there for 25 years. I don't think it will get any priority.

Message 4 of 5
(348 Views)

As description property is a string (array of bytes) it's up to the user to place any functionality he desires - commands, setup arrays, flattened data for events, etc. It's also convenient way to store this data in the VI and doesn't need to be updated during VI execution. In my case I tried to exchange and keep track of simple data when events occurred, but seems that setting dynamically the description property yields focus problems. 

 

>>Bug implies unexpected behavior, not (just) undesired behavior. The behavior probably is 'undefined', so undesired behavior is hard to qualify as bug...

 

I like this "Jesuit" explanation for the term "bug". I have to agree that nowhere is stated that changing the description property may or may not change the focus, so technically this is "undefined" behaviour and hence is a "feature" instead of a "bug". Also description property is used very rarely and is under rated, that's why this issue never came to the surface.

0 Kudos
Message 5 of 5
(321 Views)