05-06-2007 01:53 PM
hei,
i am getting in over my head, and i probably miss something.
but something bothers me: i dont think the dynamic event behave weirdly: each time an event is created, either one of the 2 loops uses it, and then flush the whole event structure. up to now no problem. on next event the choice is made again. i guess one would have a problem only if the 2 loops would react on the same event.
at least that is how i would like it to be.
in this special case, that means to me that the behavior presented here is a bug.
05-06-2007 02:23 PM
@tst wrote:
@Jim wrote:When an event structure executes, it flushes all events in the registration (subscription queue) that are not handled by the event structure.
That would make sense when you think about it, but is this documented anywhere?
I don't see how that would explain the behavior I described, though.
05-07-2007 12:13 PM
@Gabi1 wrote:
each time an event is created, either one of the 2 loops uses it, and then flush the whole event structure.
Not exactly. According to the documentation, it's not either of the loops, but at least one of the loops. The same event could be handled by more than one loop, because the loop only flushes the queue after it finishes executing the event case.
In any case, this behavior is different from the behavior of standard events, where events are queued from the moment the VI with the event structure entered one of the run states (even if it's not actually running) and where events are never flushed. It also does not appear to be documented.
Basically, as was said, the registration should be done with a seperate node separate each event structure.
BTW, just to be annoying - I found out that it IS actually the event structure that gets stuck and not just the UI by enqueuing the messages from the value change event and dequeuing them in another VI. I'm guessing that it is possible that the locking of the UI also locks the UI thread, preventing the Value Change event from being fired, but that would seem a bit weird.
05-07-2007 01:31 PM
@Jim Kring wrote:
When an event structure executes, it flushes all events in the registration (subscription queue) that are not handled by the event structure. This is necessary, in order to avoid a memory leak where the subscription queue grows because there is no event structure dequeing the events, especially since there is no way to explicitly manage the subscription queue.
05-07-2007 02:28 PM
Jason, this should not be documented only in the caveats section (which people would only read, if at all, when starting to use the event structure and not when starting to use dynamic events), but also in the Register for Events help (which I know is already quite long). This should probably be in bold font.
I realize that the UI locking should not actually lock the UI thread (which is why I said it was weird), and I only offered it as a possible explanation to why the event structure gets stuck, since this stops happening when you disable that option.
I still don't understand why the event structure gets stuck. The closest I could find was when I looked in the LV help just now and found that the help for Unregister for Events says that
"If you do not unregister for events, LabVIEW continues to generate and queue the events ... which... can hang the VI if you enable front panel locking for the events".
I can understand why it would hang the UI, but why would it hang the VI itself?
As I said in my previous post - I checked. The ES itself is locked, not just the UI.
So either whoever wrote that knew what they were talking about or they meant that the UI of the VI would hang. Either way, the original question still remains unanswered.
BTW, you can't quote multiple posts. You either have to manually copy and paste or reply several times. You can reply to each specific post by clicking the reply "button" in its top left corner.
05-07-2007 02:59 PM
@tst wrote:BTW, you can't quote multiple posts. You either have to manually copy and paste or reply several times. You can reply to each specific post by clicking the reply "button" in its top left corner.
Jason, this should not be documented only in the caveats section (which people would only read, if at all, when starting to use the event structure and not when starting to use dynamic events), but also in the Register for Events help (which I know is already quite long). This should probably be in bold font.
@tst wrote:
I realize that the UI locking should not actually lock the UI thread (which is why I said it was weird), and I only offered it as a possible explanation to why the event structure gets stuck, since this stops happening when you disable that option.
I still don't understand why the event structure gets stuck. The closest I could find was when I looked in the LV help just now and found that the help for Unregister for Events says that
"If you do not unregister for events, LabVIEW continues to generate and queue the events ... which... can hang the VI if you enable front panel locking for the events".
I can understand why it would hang the UI, but why would it hang the VI itself?
As I said in my previous post - I checked. The ES itself is locked, not just the UI.
So either whoever wrote that knew what they were talking about or they meant that the UI of the VI would hang. Either way, the original question still remains unanswered.
05-07-2007 03:39 PM - edited 05-07-2007 03:39 PM
@Jason King wrote:
By "hang the VI" it means that the front panel UI will become (or appear) unresponsive, as the front panel will be "locked" ...
Regarding your specific case, it sounds like the Event structure is not getting "locked" or "hung" in any way. It is simply not responding to an event when you expect it to (this may be a bug - I'm not in a place to be able to look into it currently), and thus the first event it "sees" is a timeout, in the absence of any other event. Your diagram is still executing, the the ES can still execute. It's just not executing in response to an event you expect it to, it sounds like. Is this correct? I just want to make sure i understand, and that we're speaking the same language here.
Loop A has two cases - the one you see and the stop case.
What should happen is this - when you press the OK button, loop B fires the event. Loop A receives it and fires the value change event, which is processed by Loop B, so for each click on the OK button, the iteration display should increment twice. This works fine if you click the OK button once.
If you click it in rapid succession, though, the UI will freeze as if one of the locking events started execution and did not finish. It will only unfreeze when the timeout event executes and then it will keep executing the remaining events in its queue (during which time it could get stuck again).
Message Edited by tst on 05-07-2007 11:43 PM
05-07-2007 04:15 PM
Hi Jason,
@Jason King wrote:Jim: Of course you know you can get the behavior you want by passing all events from the ES into a queue and enforce a one item cap on it. Yes, this takes more code and extra memory, but it seems like an uncommon use case. I'm curious what types of applications would benefit from that behavior?
05-07-2007 04:41 PM
@Jim Kring wrote:
Tracking a mouse-move on a picture control: I move the mouse over a picture control -- I want to draw an item under the mouse and have the item move beneath the mouse as the mouse moves. I want to register for mouse move events, but I don't really care about getting every event
Definitely a good idea and something I wanted for a long time. This should also be available for static events. The way this should be defined is basically for us to be able to define some minimum bounds for firing events and a timeout. The minimum bounds would determine when events will be fired (e.g. I moved at least 10 pixels) and the timeout would determine when to fire the last event (the one which brings you to your target but which doesn't pass the minimum requirements). This would be the same for a value change on a slide (although that's easier because you can always compare to the current value).
I realize that we can do this in code, but it is very cumbersome.
Ideally, this would be dynamically configurable using the event structure nodes, but I can see how that could create a problem with backward compatibility.
05-08-2007 10:58 AM
@Jim Kring wrote:
IMO, event consumers should be able to define whether they want all events or just the latest (that's why we have notifiers, in addition to queues). Here is a simple example:
Tracking a mouse-move on a picture control: I move the mouse over a picture control -- I want to draw an item under the mouse and have the item move beneath the mouse as the mouse moves. I want to register for mouse move events, but I don't really care about getting every event -- this brings my application to a crawl, as I get an event for every pixel that the mouse moves over. Rather, I want to only get the latest event to know where the mouse is currently located.
I know that I can solve my problems using Queues and Notifiers -- I am stuck and I don't need a work around. I want to use Event Structures (and User Events), but I think that they have some limitations that could be easily overcome.
@tst wrote:
The way this should be defined is basically for us to be able to define some minimum bounds for firing events and a timeout. The minimum bounds would determine when events will be fired (e.g. I moved at least 10 pixels) and the timeout would determine when to fire the last event (the one which brings you to your target but which doesn't pass the minimum requirements). This would be the same for a value change on a slide (although that's easier because you can always compare to the current value).
I realize that we can do this in code, but it is very cumbersome.