Re: [perl-win32-gui-users] Accelerator bug?

Glenn Linderman Wed, 21 Jan 2004 13:28:52 -0800

Thanks Steve. I hadn't gotten as far as trying to change one... since Icouldn't retrieve the current one, I never tried to change it... you'vealready carried the analysis further than I had!


On approximately 1/21/2004 12:42 PM, came the following characters from
the keyboard of Steve Pick:

Ah I understand now. I don't believe one can even change the NEM handlers
once set -- correct me if I'm wrong. So what we're looking for here is:
1. A way to change NEM handlers to something else.
2. A way to retrieve NEM handler coderefs.

I will poke around and you should see this in my next commit.

Steve

----- Original Message -----From: "Glenn Linderman" <[EMAIL PROTECTED]>

To: "Stephen Pick" <[EMAIL PROTECTED]>
Cc: <perl-win32-gui-users@lists.sourceforge.net>
Sent: Wednesday, January 21, 2004 6:41 PM
Subject: Re: [perl-win32-gui-users] Accelerator bug?

I guess I didn't describe the condition well enough.  I'll try again.

The reason to obtain a handler, is if you want to augment the handler to
do more stuff, behind its back.

So WinSize.pm tries to write a Resize handler that when a parent window
is resized, resizes and repositions all the children according to
user-specified rules.  It also remembers the last window position and
size for the next time that window is created.

To do this, it needs to intercept the Resize event and the Terminate
event, and do some processing before calling the user's _Resize and
_Terminate functions.  In OEM, if the user has them, they are defined in
the global symbol table, and can be replaced.

In order to do this in NEM, one needs a function to obtain the user's
defined coderefs, before replacing them, so that the replacement
function can call the user's function.


On approximately 1/21/2004 1:54 AM, came the following characters from
the keyboard of Stephen Pick:

Hooks were always after the regular handling code, except now they're
after WM_PAINT and a few other events too.

While it is not possible to retrieve the coderefs for specific NEM
events, the only time I can imagine you wanting to do this would be to
find out a handler that a particular gui object is using and call it
with your own arguments. I can't see that that would be a good plan or
any particular practical use for it. An example would be nice.

The other points, I'm looking into.

Steve

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Glenn Linderman
Sent: 21 January 2004 01:39
To: Steve Pick
Cc: Jez White; perl-win32-gui-users@lists.sourceforge.net
Subject: Re: [perl-win32-gui-users] Accelerator bug?

Back when I tried to convert one of my applications from OEM
to NEM, I
discovered the following problems.  Perhaps some of them have
been fixed
by now.  Perhaps some of them were user error.

1) The subroutines defined for pop-up menu click events never
got called.

2) Accelerators didn't work.

3) It wasn't possible to obtain the "old" event reference, so
that event
references could be stacked or nested.

The latter item blew away NEM for me, as I wasn't able to port Harold
Piske's WinSize module in a reasonable fashion.  I didn't really need
accelerator keys on that project, but they are handy on all projects,
and I prefer to have them available, so that was a negative.
And that
project used lots of pop-up menus, and when the Click event
subroutine
doesn't get called, that is a problem.

So those are the reasons I gave up on NEM for now.  1) May have been
user error... anyone have a code sample in that area?  2) is still a
problem, and 3) might be solvable via hooks... but I think hooks
executed before the event is seen by the regular handling
code would be
more effective, and they just got switched to after the
regular handling
code.  Being able to obtain the old code reference would be a handy
feature, though, even though hooks do exist.

On approximately 1/20/2004 11:01 AM, came the following
characters from
the keyboard of Steve Pick:

Aldo's been silent for a while.

Exactly what events are missing? We're running out of space


in the NEM to

add new events (checking if events are set is based on a


32-bit mask, and

most of the bits are used), but I'm sure that's easy to get round.

The NEM is probably faster than the OEM, though I've not


run any benchmarks.

I would no longer even consider using the OEM, having


looked at the code for

it (mind you I'm hardly in a position to comment on code


clarity :) ).

Steve

----- Original Message -----From: "Jez White" <[EMAIL PROTECTED]>

To: "Stephen Pick" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<perl-win32-gui-users@lists.sourceforge.net>
Sent: Tuesday, January 20, 2004 11:20 AM
Subject: Re: [perl-win32-gui-users] Accelerator bug?

I'de like to use NEM more - but I am finding some events


missing. So it

the

NEM slightly "faster" as well?

Aldo was talking about another model - is this just an


enhancement of NEM?

jez.
----- Original Message -----From: "Stephen Pick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;


<perl-win32-gui-users@lists.sourceforge.net>

Sent: Tuesday, January 20, 2004 10:58 AM
Subject: RE: [perl-win32-gui-users] Accelerator bug?


Yes, I use the NEM heavilly. The OEM is a really ugly way of doing
things and basing things on references is much safer and much more
elegant. Every other perl module that needs to do callbacks uses
references (see.. well.. anything, err, LWP for example). This is
because you can check that references are safe to call, whereas with
non-references you have to eval() and then you open up


security holes.

Steve

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]


Behalf Of

Glenn W Munroe
Sent: 20 January 2004 10:52
To: perl-win32-gui-users@lists.sourceforge.net
Subject: RE: [perl-win32-gui-users] Accelerator bug?



Just out of interest, is anybody really using the NEM? Are


there any

major advantages to it? I admit it is quite elegant to


have a one-line

subroutine defined as an -event option, but in practice, most event
handlers will consist of more code than I would like to
define that way
and the handler would just end up being another subroutine call.

IMHO, the two major advances in this module recently have been
accelerators and hooks (I'd say we're approaching GUI
nirvana), so if at
least one of them doesn't work in NEM, that knocks it on


the head for

me.

Glenn

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]


On Behalf Of

Glenn Linderman
Sent: Monday, 19 January, 2004 21:52
To: [EMAIL PROTECTED]
Cc: perl-win32-gui-users@lists.sourceforge.net
Subject: Re: [perl-win32-gui-users] Accelerator bug?

Glenn,

Sorry for the delay, I was not monitoring this email address

from 1/15

until now.


On approximately 1/16/2004 8:28 AM, came the following


characters from

the keyboard of Glenn W Munroe:

Glenn,

I haven't really used the NEM much yet, but when I knocked


up a small

test script this morning with the new model I found that


accelerators

didn't work. Had you noticed this or can you confirm it? If


so, is it
a

bug with accelerators themselves or some underlying


"feature" of the

system?


Indeed, I think it is just a missing feature in NEM.  When I
looked at
the code inside Win32::GUI for accelerators, I was able to


figure out

and fix accelerators for OEM, but I think NEM has much


more code that

simply isn't there for accelerators.  This is one reason I am still
using OEM.  (OEM = Old Event Model, when it takes a break

from meaning

Original Equipment Manufacturer :) )

Regards,
Glenn Munroe


--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users


--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users

--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users


--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-users] Accelerator bug?

Reply via email to