Unexpected event order when changing from a control to another

[Jolaf]

Lets draw a panel with two buttons, say A and B.
Now switch mode to "operate".
Click on button A, to initiate the problem.
Now hit the "tab" key.
Event order is Keypress, lostfocus(sent to button A CBfunction), gotfocus (sent to buttonB CBfunction)
Now click on the A button.
Event order is LeftClick, commit (sent to button A CBfunction), lostfocus (sent to button B CBfunction), gotfocus (sent to button A CBfunction)

The commit event to the A control is sent before the lostfocus is sent to the B control which is paradoxal to me
With the "operate" mode of the uir design tool, it is the case 100% of the time.

During real operation, it seems that it is not the case 100% of the time.

To me the right order should be Leftclick, Lostfocus, GotFocus, Commit .

Is there a way to order the events ? with someting that a priority property ?

Best regards,

Pierre

[JonathanN]

Hi Pierre,

To answer your direct question of "is there a way to order events", the answer to that is no.  We don't state that events will always fire in a specific order because they don't and because of that, your code shouldn't rely on any specific order.  I think its fine that you expressed your opinion of what you believe the order of events should be.  Really the order of events is arbitrary and thus could be argued either way.  When we first started CVI, we of course had just a few events but over time that number has greatly increased and so having a "specific" order really doesn't make sense, at least from our perspective.

If you are having a specific issue with regards to when events fire, please let me know and we can provide some suggestions to resolve your issue.

Just as a side note, the only type of documentation that we mention that is similar to this is the topic entitled Precedence of Callback Functions which describes the order of how events trigger callback functions.

Thanks for your thoughts.

Best Regards,

Message Edited by Jonathan N on 01-30-2008 01:49 PM

[Jolaf]

Hi Johnatan,

You have perfectly understood my problem.

But I don't agree that radom event generation is not an issue.

From one action (the button click) there are several consequences which depend on each others, thus the order is fixed !

If I click on an other button, the click event can be send to the control wich has focus. As a consequence of the fact that another button will get the focus, the first buttons losts the focus, then the new button gets the focus (the reverse order would imply that two controls may have the focus at the same time !!) : the order is lostfocus to the old control, gotfocus to the new (or click event to the new control and got focys.
The commit event corresponds to the activation of the main control function. Thus for a button, it is a press and a depress with the mouse pointer above the button. In my case the commit event arrives before the new control even has focus ! This is a paradox !

You should agree that this is a completely deterministic sequence. So where do the "random" comes from ?

Here is my problem :
My program communicate using RS232. I have several buttons that do automated things, and a console to enter random commands.
When a specific control gets the focus I activate a callback to automatically receive RS232 messages and display in the console. When this control losts the focus the commCallback is deactivated.
Sometimes, when I click on another control that use RS232 comm, the RS232 comm callback still is called. causing interference, and when the lostfocus event is handled, It causes crash because some pointers (passed as callbackdata) points nowhere (dealocated).
While investigating I discovered that issue (at least to me)

Can I expect a fix for 8.6 ? or at least a constant order ? and an order which is the same in the operate tool and in real panel operation ?

Regards,

Pierre

[JonathanN]

Hi Jolaf,

Let me first clarify what I meant by events not always firing in a specific order as it can be a bit confusing.  The order that events fire should be consistent relative to an exact specific  action but can change depending upon what other actions are taking place at that time.  So what does that exactly mean?? Well, let’s say that you simply clicked on a button and you received an EVENT_LEFT_CLICK, EVENT_COMMIT, EVENT_LOST_FOCUS and EVENT_GOT_FOCUS in that order. Then I would expect if you did the exact same action of simply clicking that button, you should receive those events in that order. The order of those events could change if you had other actions taking place that could affect these events. 

Now with regards to my comments about event order being arbitrary, let’s take the EVENT_LOST_FOCUS and EVENT_GOT_FOCUS example.  It wouldn't make any difference if we fired EVENT_LOST_FOCUS first and then EVENT_GOT_FOCUS or the opposite of that. Because events are synchronous in our UI (i.e. our UI is single-threaded), only 1 event will be sent to a callback function at a time (i.e. 2 events can't be fired at the same).  So this means that for example, if the EVENT_LOST_FOCUS event fires first, then at a given time no controls have focus because the EVENT_GOT_FOCUS event hasn't been handled.  If we swapped the order of these events with the got focus event firing first, then at one point, we would have 2 controls with focus which is really "illegal". So this is what I mean event order is arbitrary.

Now that we have cleared that up hopefully, as far as why you are seeing is a crash with that specific order of events doesn't make a lot of sense to me right now.  Could you perhaps post some example code that I could look at that to see how you are handling those events? Or if that's not possible, maybe some pseudo-code on how you are handling the events right now (i.e. please be specific with regards to which events you are working with; LEFT_CLICK, GOT_FOCUS, etc). Having something to look at will help me figure out what scenario you are in. I don't want to make too many assumptions since I'm not clear on your exact setup.

Best Regards,

[Jolaf]

Thanks for the quality of you answers !

Don't worry about my problem : I applied a simple solution to my problem I check if my pointers have been deallocated and, if so, just return from comm callback function doing nothing. Later, the lostfocus will remove comm callback handling.

I think I've understood what you explain in your first paragraph. If I had to sum up, I would say that events are sent in a constant order, but since events occurs randomly, callback sequences can interlace, giving the "random" aspect. But if event A and event B occurs, the callback queue should contain all the event A related callback, then the event B related callbacks. Is there a document that goes deeper in describing the internal mechanisms ?

I still think that commit event happening before the control gets the focus is a paradox (lets open a poll !!!).

If I sum up the problem that lead me to tell you this, I would say that :
Control A gets a ressource when it gets the focus, utilize this ressource each time it is commited, and frees the ressource when it losts the focus.
Same thing for control B.
This mechanism can not be utilized since control B commit event can occur before control A lost focus => conflict !

Pierre

[JonathanN]

Hi Jolaf,

It seems as if you are wanting all of the events for button A for example to fire and then all the events for button B to fire. CVI isn't designed in this fashion and for good reason.  For example, the easiest example I can give is that we allow users to swallow events.  This means that if for example, you swallow the right-click event in the control callback, the control itself will not be able to perform its default action upon receiving that event. At that point, it’s as if the user had never clicked on the button.    We couldn't have this feature if we followed the pattern of executing all of "button A's" events first and then button B's.  

As far as documentation on these internal mechanisms, we have other 30 events and we just can't document every single combination of actions and their corresponding order of events.

Now as far as your specific scenario of utilizing/sharing resources based off when events occur, this really isn't a common use-case we thought of and it’s actually the first time we've heard of somebody doing this.  Since you are going to need to work with our current CVI design, I would suggest basing your code always off the EVENT_GOT_FOCUS event and when that occurs to steal the resource from "button A".   You just can't depend upon button A firing the  EVENT_LOST_FOCUS event before button B's focus events and commit events occurring.

Best Regards,