Mohsan Khan wrote:
>I've tested my events just with print() now and they seem to catch up with
>my quick moves :-)
>I did get a double dragEnter() maybe out of 50 tries.
>But as you mentioned, the other events may have gotten lost.
>
>Is it possible to not loose an event, and have it called when it possibly can?
>That no matter what it will always be called, maybe not on time but it will.
One strategy is to create and start the animation thread before accepting
any drag-n-drops at all. It can wait() indefinitely, and the dragEnter
handler then just has to notify() in order to start the animation.
Similarly, dragExit or drop would not cause the thread to terminate, only
reset its frame-counter and return to its idle wait() state.
This would only work if the animation is always the same, and not dependent
on the dragged object. If it is dependent on the dragged object, then a
FIFO queue of actions serviced by another thread might be needed. Then the
handlers just queue an action (or a token signifying an action) with the
drag-object parameter, and return. The queuing should be written to take
as little time as possible, which means not creating big or complex
objects. All the "heavy lifting" is to be done only by the servicing
thread, who takes things out of the FIFO and performs the actions they
represent.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
