[LV2013] Events ordering (mouse down vs. value changed) ?

[Kochise]

Hi,

I've encountered a problem with my real-time behaving UI.

The event distribution mechanism registers several events

linked to various UI controls.

Two of them are set this way :

String control: value changed

Tree control : mouse down

The problem is that the String control is used both to display

and modify values within the tree. Click an item, its name is

displayed in the String control, modify the String control, the

new value is reflected into the Tree control.

The issue is when I edit a string inside the String control and

click another item in the Tree Control, the first event fired is

the Mouse down event on the Tree control. Then only the

Value changed event is fired.

What happens is that case is the value edited in the String

control gets overwritten with the new clicked item's value,

then it is saved inside the previous item's value.

Is there a way to give a kind of priority on some events

rather than others ?

David Koch

[dan_u]

I think there isn't. The mouse down on the tree will remove the focus from the string control and thus trigger the value change on the string control.

A possible workaround might be to select the "Update Value while Typing" option for the string control, so each keypress will trigger a value change event.

[Kochise]

I just tried, that worked pretty well but that's a

kinda rather pathetic solution to what looks

like a bug.

I can understand that the Mouse down event

triggers the String control's loss of focus, but

the chain of events should be reversed from

inside out, starting with the deepest implicated

events then process back to front the queue

to finish with what started it all.

I guess that it could also provide a way to filter

out the other events, yet since there are little

ways to access Labview' internal event queue

to cancel them upfront, I see no point keeping

things the way they are.

BTW, I cannot accept this as a solution since

the refresh of the tree is also mirrored in a DB,

hence the delay updating things at each key

press would soon become a burden as the

tree would grow.

Thanks anyway for the offer.

David Koch

[dan_u]

I don't think you can modify the chain of events, so you will need to implement a workaround. There are several possibilities.

One of them is to read the Text.Text property of the string control in the Tree mouse down event. The property will return the current value even if the value change event has not been triggered. You can compare the text to the previous value and update the previous tree item if necessary.

[Kochise]

Well, I lied to you, there's not just a single String control,

the whole right part of the panel is composed of controls

being saved on the Value change event :

Hence as soon as I click the Tree control on the left, the

value being edited is overwritten. Nasty nasty Labview.

David Koch

[dan_u]

What about checking for modifications in the tree "mouse down?" filter event and writing back to the tree/DB if necessary? The same code (subVI) could be used in a string value change event.

[RavensFan]

How is LabVIEW "nasty, nasty"?

While it isn't doing what you want for your particular situation, it is doing exactly what it is supposed to do and is pretty logical.

1.  You are in a control.

2.  That control's value isn't update until you leave it.

3.  Your method of leaving the control is by clicking on something else  (the mouse down).

4.  The mouse down is what happens first, once LabVIEW detects the mouse down on another control, it then says, okay, now I need to take the focus from the first control and place it here.

5.  It is the loss of focus from the first control that is what fires the value change event on the first control.

So the precise order of events is:

1.  Mouse Down event on control 2

2.  Value change on control 1

and that makes perfect sense.

Your idea of reversing the order of events does not make sense to me.  I want LabVIEW to enqueue events as they happen, not rearrange them.  Supposed some other part of your VI is simultaneously issuing another value change event, or a user event.  Where should that event fall into the queue related to the other events you've had LabVIEW rearrange?

From what I've seen from this message of yours and others in the past is you get quite upset when LabVIEW doesn't conform to your vision of the world and rather than figuring out how LabVIEW works and how to work with it, you try to fight how LabVIEW works and then take to the forums to complain.  If that is actually picture of you in your user icon, then that is exactly how I envision you while you are working on the computer.

[Kochise]

Not right so, it's how Labview works from a different

perspective of how other programming languages

works. It's how you have to discover, understand

and adapt to these particular changes that makes

me rather angry. And the inability from Labview to

be more confortable and adapt to the programmer,

not the other way.

I can work with Labview, but we have to find tricks

to get things done the way WE, as paying customers,

wants the product to work. 

If you've read my message above, I've figured out

how Labview manage its event queue. But it is sad

that the Value change event to processed so late.

Also from what you might have read in my previous

message where I complain quite a lot, Labview is

unflexible, full of hidden methods and properties,

with a pretty oldschool UI. However I tend to succeed

everytime, and even share my finding, but it's often

a great loss of time if I've figured it out sooner.

David Koch

[Ben]

Just to add another idea for others approaching similar challenges...

Using dynamic event registration lets us tun events on and off. WHen combined with "mosue enter" and leave we can switch what events are active when.

Additionally...

Event are serviced in the order they are registered with firs the static and then the dynamic.

Just trying to add another angle...

Ben

[Kochise]

Focus idea exposed 8 years back :

http://forums.ni.com/t5/LabVIEW/Key-Focus-lost/td-p/474059

Some similar problem posted 2 years back :

http://forums.ni.com/t5/LabVIEW/Key-focus-behavior-of-controls/td-p/2534522

Behavior found strange on Lava 2 years back :

https://lavag.org/topic/17798-mouse-down-filter-event-focus/

BTW, focus acquire/loss idea already in the

Idea exchange pipe for more than 4 years now :

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Key-focus-Event/idi-p/1418878

You rage, you loose 🙂

David Koch