On 14.01.2008, at 12:34, MacArthur, Ian (SELEX) (UK) wrote: > >> >> I did not test with windows.. will try that a bit later. I >> hate turning >> on my windows box. It's always.. aggravating. > > I tried this on WinXP this morning. Didn't work at first, due to some > oddness in the way the events are received, I think. > > Basically, the handle method sets the class variable "evt" to record > the > last event received - this is later tested in dnd_cb() to make sure > the > last event was an FL_PASTE when receiving the dropped data.
Several things come to mind: we cannot do many assumptions about event variableas except during the handling of the event during handle() or a callback. This means that Fl::event_text() at FL_PASTE is only valid during FL_PASTE. There is no guarantee that it will have any meaning after returning from FL_PASTE (which implies that Fl::event_text() must be saved at FL_PASTE time if it needs to be used again later). Similarly, we can not assume that and Idle or Timeout after an FL_PASTE will still have Fl::event() set to anything meaningful. All Fl::event*() variable are meaningless outside of handle() or callbacks. Sometimes this is the case because FLTK changes or adds events. For example, moving the mouse into a subwindow casues FL_LEAVE, FL_MOVE, and FL_ENTER, even though a subwindow may have no meaning whatsoever to an underlying OS. Some OSs (MS Windows, for example) don't differentiate between sending events and calling the event handler directly, circumventing the event queue. This (and a full event queue) may cause multiple events to be handled before Idle or a Timeout has a chance to be called. So if dropping a DnD while moving the mouse may generate sequences like this: FL_DND_DROP, FL_DRAG, FL_RELEASE, FL_PASTE, FL_MOVE... . Matthias ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
