> Apologies, I haven't read your code yet, so I might have asked something
> obvious in the below. You are "on a roll" Laurent! It all sounds good!
>
> On approximately 3/21/2004 11:02 AM, came the following characters from
> the keyboard of Laurent ROCHER:
>
> > I continue my work on refactoring Win32::GUI code.
> > I have made lot of change :
> > - Add some more methods for controls
>
> Would this happen to include RightClick and DblRightClick ?
Yes those events are handle for control supporting then.
Generaly, Common Control (TreeView, ...) support them via standard notify
code (NM_RCLICK, NM_RDBLCLK).
Basic control (button, label, textfield, ...) have sometime specific message
for that but don't work for every control.
However, all control receive standard window mouse event (WM_MOUSEMOVE,
WM_LBUTTONDOWN, WM_LBUTTONUP, ...).
Those events are handle by MouseMove, MouseDown, MouseUp event.
It's possible to add RMouseDown, RMouseUp, MMouseDown, MMouseUp for Right
and Middle button click.
Click/DblClick event are different than standard mouse event, it's control
dependent.
Event name isn't unified, for sample :
- Graphic generate LButtonDown instead MouseDown and have a RButtonDown
event didn't exist for other control.
- Listbox have a Click event when receive LBN_SELCHANGE. A Change event
should be nicer.
I don't change this for compatibility reason.
>
> > Each event is fire by a unique DoEvent method (same concept
DoEventNEM
> > with arglist).
> > DoEvent handle NEM and OEM event call. (UEM?)
>
> This sounds more efficient. UEM doesn't exist yet, it is what I named a
> concept that would seem to unify OEM, NEM, and Aldo's next generation
> event model.
Yes all event firing code using only one function (easier to change, add
model event).
>
> I think the big interface change with Aldo's next generation event model
> was the addition of the window widget object reference as a parameter to
> the event sub. Neither OEM nor NEM passed that, so you can't add it
> easily without being incompatible. It would be useful, though, to have
> the object reference as a parameter but would require a new flag to
> indicate that the -on* and -event defined subs were expecting the new
> parameter (which should probably be the first parameter).
>
> So I'm not sure if you should call your new DoEvent UEM quite yet, but
> it seems a good foundation step in that direction.
NEM event always send window self reference as first parameter.
I don't think it's usefull for OEM event because function use window name.
It's a good reason to use NEM event ;o)
But, it's possible to add a new event model option switch for do that.
Something like -eventmodel => [both, byref, byname, byname_self].
byname_self is same than byname but with a self as first parameter.
A global SetEventModel can be usefull for setup default event model (actualy
it's BYNAME by default).
> > - Try Write code for NotifyIcon and Accelerator NEM handling (not
tested
> > yet)
>
> Thanks, I'll take a look at this when I get a chance. Since I'd gone a
> certain distance in converting to NEM in my project, and didn't want to
> back-out all that code, I had actually implemented a couple "wrapper"
> functions that searched for -on* and -event, and processed them in Perl,
> using eval to create NAME_EVENT (OEM style) subs that call the NEM
> subs, and then eliminated those parameters (-on* and -event) from the
> calls to Win32::GUI, resulting in OEM. Well, the upshot is that I am
> using NEM style calls, and converting them to OEM on the fly, so I
> should be able to quickly flip-flop my application between using OEM and
> NEM. Which might help in my testing of your additions, if I get time to
> do that.
Ok, i understand why you want self in OEM ;o)
I have same problem with my TabFrame package (NEM didn't exist when i write
it).
I need to keep all instance in a global hash, doing something like that :
# Keep object reference
$Instance{$options{-name}} = $self;
# Add Click Event
eval qq(
sub main::$options{-name}_Click {
return Win32::GUI::TabFrame->ClickEvent($options{-name});
}
);
sub ClickEvent {
my $class = shift;
my $name = shift;
my $element = $Instance{$name};
...
}
NEM, it's easier for that ;o)
Actually, with new event model handling, NEM and OEM work in concert (adding
a new event handle, it's handle in both mode).
Laurent.
