> > Sometimes you want your events to be called > > instantaneously (clear > > paintdevice before drawing on it) and sometimes you > > will want to catch and > > forward them elsewhere (i.e. keystrokes). You need > > both. > > I guess what I am trying to say is that I'd prefer a > single underlying event generation/dispatching > mechanism. You could have both (instaneous and asynch > behaviors) with just one underlying mechanism. > If we are to use threads then the instant event would > be emulated by waiting on the completion. If we are > to use single-thread message pumps (like Win32), the > asynch event would be emulated by a post function. If > we select the first option, the gui library must be > thread safe. >
Yes. The single technology that delivers both behaviours sounds easier to deal with. A couple of thoughts on event generation/dispatching and some previous comments to do with lack-of-developer- commitment-to-state-machines. 1. events are very much part of the state machine issue. i mean, what is receiving the events and how do they respond to the events (at different times)? i think you stated intention to avoid state machines (laudable) but getting tangled in event generation/dispatch is possibly the same thing. 2. is there potential to identify a "generic state machine" that can be part of your gui templates/library without getting tangled in the application specific machines. i wondered about this because MFC implements (very loosely) a state machine but it doesnt know anything about actual app-events, i.e. it builds and dismantles dialogs with controls (a stately process), but it doesnt itself know what needs to be done on click of some application button entitled "Run". SW _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
