hello people :-)
On Mon, 2004-02-16 at 13:53, Stephen Pick wrote:
> Hello,
>
> Looks like menus are indeed a little busted. You can't use both
> event models on a menu. You can use either the NEM or the OEM, but
> you can't selectively use NEM here and OEM there. If you add a menu
> to a window that is using the NEM and your window uses OEM, your menu
> won't work. Your menu's event model must match that of the window
> you're adding it into.
as I said a lot of time ago, the current OEM/NEM interoperability
implementation is going to die. there's too much broken code in there,
and I thought of a way to simplify things a lot (but they will be
managed a little bit differently).
the last time I wrote here, I promised a document describing the new
architecture that I'm going to implement, but in the mean time a damn
stupid 120 GB external USB HD ate my development directory. more than 1
GB of stuff, more than 6 years of development, sigh :-(
so, the whole thing exists only in my mind now.
basically, the idea is the following: there will be a single messageloop
for each window (including controls), which, in pseudocode, should do
something like this:
if(event_model & BYREF) {
if(window->eventmap(event_id)) {
event = window->events{get_event_name(event_id)};
fire_event(event);
}
}
if(event_model & BYNAME) {
event_name = window->name . "_" . get_event_name(event_id);
if(event = perl_get_cv(event_name)) {
fire_event(event);
}
}
the biggest implication is that the OEM (BYNAME event model) will
probably result a little bit slower: that's because each message to each
control will trigger a perl_get_cv call (which is orders of magnitude
slower than a C instruction). on the other hand, every control will have
the whole range of events (eg. MouseMove, MouseClick, etc.) enabled by
default.
event_model in the code above is a global variable in C which will be
controlled by a method (Win32::GUI::SetEventModel or something like
that) or by a directive in use (eg. use Win32::GUI EventModel =>
'BYREF').
I'm a little (oh, well, a little is not enough :-) behind with the
situation on CVS, but I'm ready to implement this architectural change.
should we branch the CVS repository (or create a new module, which
sounds better to me) or is the current status quiet enough to begin
working on this for the next release?
cheers,
Aldo
