Timer fires during trigger processing on web

Question

I was looking for a way to augment the default behaviour
of a hierarchical tree. The trouble is clicking in a tree can fire various combinations of WHEN-MOUSE-CLICK, WHEN-TREE-NODE-SELECTED, WHEN-TREE-NODE-EXPANDED,
WHEN-TREE-NODE-ACTIVATED, WHEN-MOUSE-DOUBLE-CLICKED. I wanted to trigger some action after they had finished firing but as I didn't know which would fire last, where to put the code ?
The solution I found was to start a 1 ms timer in WHEN-MOUSE-CLICK (which always fires first), gather information from the other triggers into a variable, and do my processing in WHEN-TIMER-EXPIRED. This worked fine on client/server but when I deployed it on the web I found the timer expired between WHEN-MOUSE-CLICK and WHEN-TREE-NODE-SELECTED (triggered by a single click).
My understanding of timers is that, however short their duration, they should not expire during trigger processing. Have I got this wrong or is this a bug ?
It seems to work OK with 5 ms but I would like to know what is going on.
(f6i patch 7)

Answer 1

All,
as promised, here's an answer from development. Duncan said it already, but here's the long version
1). Regarding timers in general. 1ms timers fire on the server (effectively,
at the time the timer is created in a trigger, we put a timer macro on the
stack so that that next time we go for input (after we've processed all
of the events we've already gotten at that point), it will act as if the timer
has expired. This, as you know, prevents us from doing round-trips to the
client when people are simply creating a timer to get around some of the
restricted built-in/trigger issues. Any timer of longer than 1ms will get
created on the client and thus cause round-trips. We have no plans to
bump that threshhold up, so people could use 2ms timers if they wanted...
2). Regarding timers expiring during trigger processing. It is true in both
client/server and web that we will not expire a timer while a trigger is
firing. However, the order in which the user will see events (and thus
which triggers will fire in) can vary. In the example that was given,
the user (double)clicks on a node in the tree on the client. The first
mouse click causes a message/event to be sent immediately to the
server, which ends up causing the when-mouse-clicked trigger to fire.
As soon as that message is sent, the server starts processing that
trigger. In the meantime, the client may decide that it needs to send
other messages (such as when-node-selected, etc.). However, until
the server sends a return-message to the client asking for more input,
this won't get sent. Now, the server fires the when-mouse-click trigger,
and as part of it a timer gets created. There are two possible scenarios
here.
In the first scenario, the timer is 1ms, and thus is handled on the
server. Thus, when the trigger ends, the server sees if there is any more
input to be processed, and sees that the timer has expired (because, as
I explained above, this gets put directly onto the macro stack). Thus, the
timer expired trigger fires. After that trigger fires, the server sees that it
has no more input waiting, and sends a message to the client telling it to
send more input. At that point, the client can send whatever other events
it has queued up (such as the when-node-selected) and we carry on.
In the second scenario, the timer is more than 1ms long. In this case, when
the trigger says to create a timer, the server queues up a message to send
to the client telling it to create a timer. When the rest of the trigger is complete
and the server sees that it has no more events to process, it sends this timer
creation message to the client at the same time it asks the client to give it
more events. The client sends the when-node-selected event, the server
processes it, and eventually asks the client for more input. By then, the
timer has expired and then the timer message gets sent to the server.
In neither of these cases does the timer trigger fire in the middle of
another trigger that is already firing, it is simply that the separate triggers
might fire in a different order because of the order that the underlying
events are processed. In client/server, the process is effectively the same
as the 2nd scenario above, because the timer is handled by the toolkit, just
like the other events, and thus the message for the timer expiring will get
sent to Forms after any of the events related to the mouse click. But again,
the rule about timers firing during trigger processing is not violated, it is just
that there is a break between triggers that can allow a 1ms timer to fire
'sooner' on the web than in client/server.
Fran