E. Gladyshev <[EMAIL PROTECTED]> wrote: > GUI objects generate events. What is the best design > for it? Should the events handlers be executed
I do not know what is best design, but here's what I think about it: - each "window" (or almost each - may it be widget, edit box, dialog, data view, or main application window, but maybe not static window) may own (but do not have to) its message thread; - if window owns its message thread, it will be able to receive UI events; - it window does not own its message thread, its UI events will be passed to its "parent" window (ie. window containing it; there may be windows, which does not have parents, like main app. window - in such case compilation error is preferred way to signalize that there's no thread able to handle window events); - window events thread must have signal/slots (or callbacks) mechanism, which will be used to call user-defined functions when particular event happens (lack of such mechanism should be compile time error) - user defined functions will be called in context of event thread, and will receive information about A. window (or widged) which fired event B. window, whose event thread accepted event (may be the same as A. or its parent, or its grandpa etc.). This way user will be able to register single function in multiple event threads (signal/slots mechanisms ?) and be sure, that while handling event from one window, the function will be able to accept event from another window (in another thread). On the other hand, window thread will be able to accept and process only single event at once, thus user functions should minimize time necessary to process event. - if user funtion needs to do some more processing for the event it received (thus blocking other events in the window which accepted the event), this function should postpone processing into another thread (created a priori or pooled ?). There should be some conveniant way of creating threads for this purpose. Thread function will be started just when user function leaves, and this separate thread will continue processing. In the same time, window which accepted event will be able to receive another event, and also receive (at some later time) notification about finished event processing. These are just ideas .... I do not even know how these ideas match to rules of GUI programming (if there are any). B. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
