From: Stephen P. <Ste...@uc...> - 2004-01-20 10:59:06
|
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: per...@li... > [mailto:per...@li...]On Behalf Of > Glenn W Munroe > Sent: 20 January 2004 10:52 > To: per...@li... > Subject: RE: [perl-win32-gui-users] Accelerator bug? >=20 >=20 >=20 > 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=20 > define that way > and the handler would just end up being another subroutine call. >=20 > IMHO, the two major advances in this module recently have been > accelerators and hooks (I'd say we're approaching GUI=20 > nirvana), so if at > least one of them doesn't work in NEM, that knocks it on the head for > me. >=20 > Glenn >=20 > -----Original Message----- > From: per...@li... > [mailto:per...@li...] On Behalf Of > Glenn Linderman > Sent: Monday, 19 January, 2004 21:52 > To: gw...@fo... > Cc: per...@li... > Subject: Re: [perl-win32-gui-users] Accelerator bug? >=20 > Glenn, >=20 > Sorry for the delay, I was not monitoring this email address=20 > from 1/15=20 > until now. >=20 >=20 > On approximately 1/16/2004 8:28 AM, came the following characters from > the keyboard of Glenn W Munroe: > > Glenn, > >=20 > > I haven't really used the NEM much yet, but when I knocked=20 > up a small > > test script this morning with the new model I found that=20 > accelerators > > didn't work. Had you noticed this or can you confirm it? If=20 > so, is it > a > > bug with accelerators themselves or some underlying "feature" of the > > system? >=20 > Indeed, I think it is just a missing feature in NEM. When I=20 > looked at=20 > the code inside Win32::GUI for accelerators, I was able to figure out=20 > and fix accelerators for OEM, but I think NEM has much more code that=20 > simply isn't there for accelerators. This is one reason I am still=20 > using OEM. (OEM =3D Old Event Model, when it takes a break=20 > from meaning=20 > Original Equipment Manufacturer :) ) >=20 > > Regards, > > Glenn Munroe >=20 > --=20 > Glenn -- http://nevcal.com/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > The best part about procrastination is that you are never bored, > because you have all kinds of things that you should be doing. >=20 >=20 >=20 > ------------------------------------------------------- > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >=20 |
From: Stephen P. <Ste...@uc...> - 2004-01-21 09:54:49
|
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: per...@li... > [mailto:per...@li...]On Behalf Of > Glenn Linderman > Sent: 21 January 2004 01:39 > To: Steve Pick > Cc: Jez White; per...@li... > Subject: Re: [perl-win32-gui-users] Accelerator bug? >=20 >=20 > Back when I tried to convert one of my applications from OEM=20 > to NEM, I=20 > discovered the following problems. Perhaps some of them have=20 > been fixed=20 > by now. Perhaps some of them were user error. >=20 > 1) The subroutines defined for pop-up menu click events never=20 > got called. >=20 > 2) Accelerators didn't work. >=20 > 3) It wasn't possible to obtain the "old" event reference, so=20 > that event=20 > references could be stacked or nested. >=20 > The latter item blew away NEM for me, as I wasn't able to port Harold=20 > Piske's WinSize module in a reasonable fashion. I didn't really need=20 > accelerator keys on that project, but they are handy on all projects,=20 > and I prefer to have them available, so that was a negative. =20 > And that=20 > project used lots of pop-up menus, and when the Click event=20 > subroutine=20 > doesn't get called, that is a problem. >=20 > So those are the reasons I gave up on NEM for now. 1) May have been=20 > user error... anyone have a code sample in that area? 2) is still a=20 > problem, and 3) might be solvable via hooks... but I think hooks=20 > executed before the event is seen by the regular handling=20 > code would be=20 > more effective, and they just got switched to after the=20 > regular handling=20 > code. Being able to obtain the old code reference would be a handy=20 > feature, though, even though hooks do exist. >=20 >=20 > On approximately 1/20/2004 11:01 AM, came the following=20 > characters from > the keyboard of Steve Pick: > > Aldo's been silent for a while. > >=20 > > Exactly what events are missing? We're running out of space=20 > in the NEM to > > add new events (checking if events are set is based on a=20 > 32-bit mask, and > > most of the bits are used), but I'm sure that's easy to get round. > >=20 > > The NEM is probably faster than the OEM, though I've not=20 > run any benchmarks. > >=20 > > I would no longer even consider using the OEM, having=20 > looked at the code for > > it (mind you I'm hardly in a position to comment on code=20 > clarity :) ). > >=20 > > Steve > >=20 > > ----- Original Message -----=20 > > From: "Jez White" <je...@je...> > > To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; > > <per...@li...> > > Sent: Tuesday, January 20, 2004 11:20 AM > > Subject: Re: [perl-win32-gui-users] Accelerator bug? > >=20 > >=20 > >=20 > >>I'de like to use NEM more - but I am finding some events=20 > missing. So it > >=20 > > the > >=20 > >>NEM slightly "faster" as well? > >> > >>Aldo was talking about another model - is this just an=20 > enhancement of NEM? > >> > >>jez. > >> > >>----- Original Message -----=20 > >>From: "Stephen Pick" <Ste...@uc...> > >>To: <gw...@fo...>;=20 > <per...@li...> > >>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=20 > security holes. > >> > >>Steve > >> > >> > >>>-----Original Message----- > >>>From: per...@li... > >>>[mailto:per...@li...]On > Behalf Of > >>>Glenn W Munroe > >>>Sent: 20 January 2004 10:52 > >>>To: per...@li... > >>>Subject: RE: [perl-win32-gui-users] Accelerator bug? > >>> > >>> > >>> > >>>Just out of interest, is anybody really using the NEM? Are=20 > there any > >>>major advantages to it? I admit it is quite elegant to=20 > 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=20 > the head for > >>>me. > >>> > >>>Glenn > >>> > >>>-----Original Message----- > >>>From: per...@li... > >>>[mailto:per...@li...]=20 > On Behalf Of > >>>Glenn Linderman > >>>Sent: Monday, 19 January, 2004 21:52 > >>>To: gw...@fo... > >>>Cc: per...@li... > >>>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=20 > 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=20 > "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=20 > figure out > >>>and fix accelerators for OEM, but I think NEM has much=20 > more code that > >>>simply isn't there for accelerators. This is one reason I am still > >>>using OEM. (OEM =3D Old Event Model, when it takes a break > >>>from meaning > >>>Original Equipment Manufacturer :) ) > >>> > >>> > >>>>Regards, > >>>>Glenn Munroe > >>> > >>>--=20 > >>>Glenn -- http://nevcal.com/ > = >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >>>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 > >>>Per...@li... > >>>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 > >>>Per...@li... > >>>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 > >>Per...@li... > >>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 > >>Per...@li... > >>https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > >> > >=20 > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > 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 > > Per...@li... > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > >=20 > >=20 >=20 > --=20 > Glenn -- http://nevcal.com/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > The best part about procrastination is that you are never bored, > because you have all kinds of things that you should be doing. >=20 >=20 >=20 > ------------------------------------------------------- > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >=20 |
From: Glenn L. <pe...@ne...> - 2004-01-21 18:41:28
|
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: per...@li... >>[mailto:per...@li...]On Behalf Of >>Glenn Linderman >>Sent: 21 January 2004 01:39 >>To: Steve Pick >>Cc: Jez White; per...@li... >>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" <je...@je...> >>>To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; >>><per...@li...> >>>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" <Ste...@uc...> >>>>To: <gw...@fo...>; >> >><per...@li...> >> >>>>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: per...@li... >>>>>[mailto:per...@li...]On >> >> Behalf Of >> >>>>>Glenn W Munroe >>>>>Sent: 20 January 2004 10:52 >>>>>To: per...@li... >>>>>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: per...@li... >>>>>[mailto:per...@li...] >> >>On Behalf Of >> >>>>>Glenn Linderman >>>>>Sent: Monday, 19 January, 2004 21:52 >>>>>To: gw...@fo... >>>>>Cc: per...@li... >>>>>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 >>>>>Per...@li... >>>>>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 >>>>>Per...@li... >>>>>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 >>>>Per...@li... >>>>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 >>>>Per...@li... >>>>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 >>>Per...@li... >>>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 >>Per...@li... >>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. |
From: Steve P. <st...@ba...> - 2004-01-21 20:42:02
|
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" <pe...@ne...> To: "Stephen Pick" <Ste...@uc...> Cc: <per...@li...> 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: per...@li... > >>[mailto:per...@li...]On Behalf Of > >>Glenn Linderman > >>Sent: 21 January 2004 01:39 > >>To: Steve Pick > >>Cc: Jez White; per...@li... > >>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" <je...@je...> > >>>To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; > >>><per...@li...> > >>>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" <Ste...@uc...> > >>>>To: <gw...@fo...>; > >> > >><per...@li...> > >> > >>>>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: per...@li... > >>>>>[mailto:per...@li...]On > >> > >> Behalf Of > >> > >>>>>Glenn W Munroe > >>>>>Sent: 20 January 2004 10:52 > >>>>>To: per...@li... > >>>>>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: per...@li... > >>>>>[mailto:per...@li...] > >> > >>On Behalf Of > >> > >>>>>Glenn Linderman > >>>>>Sent: Monday, 19 January, 2004 21:52 > >>>>>To: gw...@fo... > >>>>>Cc: per...@li... > >>>>>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 > >>>>>Per...@li... > >>>>>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 > >>>>>Per...@li... > >>>>>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 > >>>>Per...@li... > >>>>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 > >>>>Per...@li... > >>>>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 > >>>Per...@li... > >>>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 > >>Per...@li... > >>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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > |
From: Glenn L. <pe...@ne...> - 2004-01-21 21:28:52
|
Thanks Steve. I hadn't gotten as far as trying to change one... since I couldn't retrieve the current one, I never tried to change it... you've already 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" <pe...@ne...> > To: "Stephen Pick" <Ste...@uc...> > Cc: <per...@li...> > 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: per...@li... >>>>[mailto:per...@li...]On Behalf Of >>>>Glenn Linderman >>>>Sent: 21 January 2004 01:39 >>>>To: Steve Pick >>>>Cc: Jez White; per...@li... >>>>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" <je...@je...> >>>>>To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; >>>>><per...@li...> >>>>>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" <Ste...@uc...> >>>>>>To: <gw...@fo...>; >>>> >>>><per...@li...> >>>> >>>>>>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: per...@li... >>>>>>>[mailto:per...@li...]On >>>> >>>>Behalf Of >>>> >>>> >>>>>>>Glenn W Munroe >>>>>>>Sent: 20 January 2004 10:52 >>>>>>>To: per...@li... >>>>>>>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: per...@li... >>>>>>>[mailto:per...@li...] >>>> >>>>On Behalf Of >>>> >>>> >>>>>>>Glenn Linderman >>>>>>>Sent: Monday, 19 January, 2004 21:52 >>>>>>>To: gw...@fo... >>>>>>>Cc: per...@li... >>>>>>>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 >>>>>>>Per...@li... >>>>>>>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 >>>>>>>Per...@li... >>>>>>>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 >>>>>>Per...@li... >>>>>>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 >>>>>>Per...@li... >>>>>>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 >>>>>Per...@li... >>>>>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 >>>>Per...@li... >>>>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 >>Per...@li... >>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. |
From: Steve P. <st...@ba...> - 2004-01-22 20:36:06
|
Hi, I've implemented the following two functions: $coderef = $window->GetEvent("eventname"); $window->SetEvent("eventname", \&sub); These allow you to access and modify NEM event handlers. You can't access and modify OEM event handlers. I should hope that the reasons are obvious: It would be impossible and pointless. Sourceforge's CVS is being particularly annoying at the moment (I can't get a branch list from it, and it keeps failing to respond when connecting) so you'll probably have to wait a bit before you see the changes appear. Steve ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...> To: "Steve Pick" <st...@ba...> Cc: "Win32 GUI Users" <per...@li...> Sent: Wednesday, January 21, 2004 9:29 PM Subject: Re: [perl-win32-gui-users] Accelerator bug? > Thanks Steve. I hadn't gotten as far as trying to change one... since I > couldn't retrieve the current one, I never tried to change it... you've > already 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" <pe...@ne...> > > To: "Stephen Pick" <Ste...@uc...> > > Cc: <per...@li...> > > 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: per...@li... > >>>>[mailto:per...@li...]On Behalf Of > >>>>Glenn Linderman > >>>>Sent: 21 January 2004 01:39 > >>>>To: Steve Pick > >>>>Cc: Jez White; per...@li... > >>>>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" <je...@je...> > >>>>>To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; > >>>>><per...@li...> > >>>>>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" <Ste...@uc...> > >>>>>>To: <gw...@fo...>; > >>>> > >>>><per...@li...> > >>>> > >>>>>>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: per...@li... > >>>>>>>[mailto:per...@li...]On > >>>> > >>>>Behalf Of > >>>> > >>>> > >>>>>>>Glenn W Munroe > >>>>>>>Sent: 20 January 2004 10:52 > >>>>>>>To: per...@li... > >>>>>>>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: per...@li... > >>>>>>>[mailto:per...@li...] > >>>> > >>>>On Behalf Of > >>>> > >>>> > >>>>>>>Glenn Linderman > >>>>>>>Sent: Monday, 19 January, 2004 21:52 > >>>>>>>To: gw...@fo... > >>>>>>>Cc: per...@li... > >>>>>>>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 > >>>>>>>Per...@li... > >>>>>>>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 > >>>>>>>Per...@li... > >>>>>>>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 > >>>>>>Per...@li... > >>>>>>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 > >>>>>>Per...@li... > >>>>>>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 > >>>>>Per...@li... > >>>>>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 > >>>>Per...@li... > >>>>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 > >>Per...@li... > >>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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > |
From: Johan L. <johanl@DarSerMan.com> - 2004-01-22 21:23:15
|
At 21:36 2004-01-22, Steve Pick wrote: >These allow you to access and modify NEM event handlers. Very cool. >You can't access and modify OEM event handlers. I should hope that the >reasons are obvious: It would be impossible and pointless. ...unless you just modify the symbol table? Or what is the OEM if not that? /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl@DarSerMan.com Latest bookmark: "Findory.com News Personalized News" http://www.findory.com/cgi-bin/news.cgi dmoz (1 of 6): /Arts/Celebrities/D/Dolenz,_Micky/ 89 |
From: Glenn L. <pe...@ne...> - 2004-01-23 01:40:41
|
On approximately 1/22/2004 12:36 PM, came the following characters from the keyboard of Steve Pick: > Hi, > > I've implemented the following two functions: > > $coderef = $window->GetEvent("eventname"); > $window->SetEvent("eventname", \&sub); > > These allow you to access and modify NEM event handlers. Great. > You can't access and modify OEM event handlers. I should hope that the > reasons are obvious: It would be impossible and pointless. Well, actually, since they are simply functions in the global name space, it is quite possible, but there is no need for a special XS function to do it. This is how WinSize.pm currently works. > Sourceforge's CVS is being particularly annoying at the moment (I can't get > a branch list from it, and it keeps failing to respond when connecting) so > you'll probably have to wait a bit before you see the changes appear. Life is hard, and then you die.** Hopefully these will appear before then. :) Thanks for figuring out how, and doing it. > Steve ** Unless you believe in reincarnation-- in that case, life is hard, and then life is hard, and then life is hard, and then life is hard... -- 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. |
From: Johan L. <johanl@DarSerMan.com> - 2004-01-23 08:21:38
|
At 02:41 2004-01-23, Glenn Linderman wrote: >Life is hard, and then you die.** Hopefully these will appear before >then. :) Thanks for figuring out how, and doing it. Or, as we used to say on Antigua: Life's a beach, and then you dive. Or: The water is always greener on the other side of the bay. Now back to our regular programming... /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl@DarSerMan.com Latest bookmark: "Findory.com News Personalized News" http://www.findory.com/cgi-bin/news.cgi dmoz (1 of 6): /Arts/Celebrities/D/Dolenz,_Micky/ 89 |
From: Stephen P. <Ste...@uc...> - 2004-01-21 10:35:47
|
GUI_MessageLoops.cpp, there are events for graphics in the OEM but i = don't see any NEM functionality for Paint(). the onMouseDown etc. events = will probably work if the graphic is set to be interactive. Steve > -----Original Message----- > From: per...@li... > [mailto:per...@li...]On Behalf Of > Jez White > Sent: 21 January 2004 10:27 > To: Steve Pick; per...@li... > Subject: Re: [perl-win32-gui-users] Accelerator bug? >=20 >=20 > Steve, >=20 > I think I have found some missing events (for graphics) but=20 > before I create > any bug reports I'd like to check the XS code - but were=20 > should I look? >=20 > Cheers, >=20 > jez. > ----- Original Message -----=20 > From: "Steve Pick" <st...@ba...> > To: "Jez White" <je...@je...>; > <per...@li...> > Sent: Tuesday, January 20, 2004 7:01 PM > Subject: Re: [perl-win32-gui-users] Accelerator bug? >=20 >=20 > > Aldo's been silent for a while. > > > > Exactly what events are missing? We're running out of space=20 > in the NEM to > > add new events (checking if events are set is based on a=20 > 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=20 > looked at the code > for > > it (mind you I'm hardly in a position to comment on code=20 > clarity :) ). > > > > Steve > > >=20 >=20 >=20 > ------------------------------------------------------- > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users >=20 |
From: Jez W. <je...@je...> - 2004-01-21 10:46:06
|
Yeah all the events work in the OEM but not in the NEM - I just looked at the code and I'm not confident enough to get NEM working. Should I create the tracker item as a bug or a feature request? Cheers, jez. ----- Original Message ----- From: "Stephen Pick" <Ste...@uc...> To: "Jez White" <je...@je...>; <per...@li...> Sent: Wednesday, January 21, 2004 10:35 AM Subject: RE: [perl-win32-gui-users] Accelerator bug? GUI_MessageLoops.cpp, there are events for graphics in the OEM but i don't see any NEM functionality for Paint(). the onMouseDown etc. events will probably work if the graphic is set to be interactive. Steve > -----Original Message----- > From: per...@li... > [mailto:per...@li...]On Behalf Of > Jez White > Sent: 21 January 2004 10:27 > To: Steve Pick; per...@li... > Subject: Re: [perl-win32-gui-users] Accelerator bug? > > > Steve, > > I think I have found some missing events (for graphics) but > before I create > any bug reports I'd like to check the XS code - but were > should I look? > > Cheers, > > jez. > ----- Original Message ----- > From: "Steve Pick" <st...@ba...> > To: "Jez White" <je...@je...>; > <per...@li...> > Sent: Tuesday, January 20, 2004 7:01 PM > Subject: Re: [perl-win32-gui-users] Accelerator bug? > > > > 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 > > > > > > ------------------------------------------------------- > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > |
From: Jez W. <je...@je...> - 2004-01-20 11:20:22
|
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" <Ste...@uc...> To: <gw...@fo...>; <per...@li...> 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: per...@li... > [mailto:per...@li...]On Behalf Of > Glenn W Munroe > Sent: 20 January 2004 10:52 > To: per...@li... > 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: per...@li... > [mailto:per...@li...] On Behalf Of > Glenn Linderman > Sent: Monday, 19 January, 2004 21:52 > To: gw...@fo... > Cc: per...@li... > 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 > Per...@li... > 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 > Per...@li... > 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 Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users |
From: Steve P. <st...@ba...> - 2004-01-20 19:00:49
|
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" <je...@je...> To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; <per...@li...> 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" <Ste...@uc...> > To: <gw...@fo...>; <per...@li...> > 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: per...@li... > > [mailto:per...@li...]On Behalf Of > > Glenn W Munroe > > Sent: 20 January 2004 10:52 > > To: per...@li... > > 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: per...@li... > > [mailto:per...@li...] On Behalf Of > > Glenn Linderman > > Sent: Monday, 19 January, 2004 21:52 > > To: gw...@fo... > > Cc: per...@li... > > 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 > > Per...@li... > > 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 > > Per...@li... > > 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 > Per...@li... > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > |
From: Jez W. <je...@je...> - 2004-01-20 20:26:20
|
Indeed he has... What events are missing - not sure - I'm in the process of tiding up my app, and large parts of it I would like to run under NEM - I'll create a bug report for missing events as I find them. cheers, jez. ----- Original Message ----- From: "Steve Pick" <st...@ba...> To: "Jez White" <je...@je...>; <per...@li...> Sent: Tuesday, January 20, 2004 7:01 PM Subject: Re: [perl-win32-gui-users] Accelerator bug? > 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" <je...@je...> > To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; > <per...@li...> > 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" <Ste...@uc...> > > To: <gw...@fo...>; <per...@li...> > > 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: per...@li... > > > [mailto:per...@li...]On Behalf Of > > > Glenn W Munroe > > > Sent: 20 January 2004 10:52 > > > To: per...@li... > > > 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: per...@li... > > > [mailto:per...@li...] On Behalf Of > > > Glenn Linderman > > > Sent: Monday, 19 January, 2004 21:52 > > > To: gw...@fo... > > > Cc: per...@li... > > > 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 > > > Per...@li... > > > 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 > > > Per...@li... > > > 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 > > Per...@li... > > 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 > > Per...@li... > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > > |
From: Steve P. <st...@ba...> - 2004-01-20 20:51:31
|
Thanks. Freeform windows - you want Layered windows. You can set a window to be layered by giving it an extended style of WS_EX_LAYERED (0x00080000), but I found that this made my window invisible. You may have better luck, as I tried it in an application that I'd made that uses lots of hooks to draw things and therefore is probably incompatible with them. Transparent backgrounds on labels - Try setting WS_EX_TRANSPARENT (0x00000020), This seems to screw up drawing a treat, but it may work if you set normal style WS_CLIPCHILDREN (0x02000000). Give it a go and let me know the result. Steve ----- Original Message ----- From: "Jez White" <je...@je...> To: "Steve Pick" <st...@ba...>; <per...@li...> Sent: Tuesday, January 20, 2004 7:29 PM Subject: Re: [perl-win32-gui-users] Accelerator bug? > Indeed he has... > > What events are missing - not sure - I'm in the process of tiding up my app, > and large parts of it I would like to run under NEM - I'll create a bug > report for missing events as I find them. > > cheers, > > jez. > ----- Original Message ----- > From: "Steve Pick" <st...@ba...> > To: "Jez White" <je...@je...>; > <per...@li...> > Sent: Tuesday, January 20, 2004 7:01 PM > Subject: Re: [perl-win32-gui-users] Accelerator bug? > > > > 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" <je...@je...> > > To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; > > <per...@li...> > > 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" <Ste...@uc...> > > > To: <gw...@fo...>; <per...@li...> > > > 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: per...@li... > > > > [mailto:per...@li...]On Behalf Of > > > > Glenn W Munroe > > > > Sent: 20 January 2004 10:52 > > > > To: per...@li... > > > > 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: per...@li... > > > > [mailto:per...@li...] On Behalf Of > > > > Glenn Linderman > > > > Sent: Monday, 19 January, 2004 21:52 > > > > To: gw...@fo... > > > > Cc: per...@li... > > > > 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 > > > > Per...@li... > > > > 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 > > > > Per...@li... > > > > 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 > > > Per...@li... > > > 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 > > > Per...@li... > > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > > > > > > > |
From: Glenn L. <pe...@ne...> - 2004-01-21 01:38:27
|
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" <je...@je...> > To: "Stephen Pick" <Ste...@uc...>; <gw...@fo...>; > <per...@li...> > 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" <Ste...@uc...> >>To: <gw...@fo...>; <per...@li...> >>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: per...@li... >>>[mailto:per...@li...]On Behalf Of >>>Glenn W Munroe >>>Sent: 20 January 2004 10:52 >>>To: per...@li... >>>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: per...@li... >>>[mailto:per...@li...] On Behalf Of >>>Glenn Linderman >>>Sent: Monday, 19 January, 2004 21:52 >>>To: gw...@fo... >>>Cc: per...@li... >>>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 >>>Per...@li... >>>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 >>>Per...@li... >>>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 >>Per...@li... >>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 >>Per...@li... >>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 > Per...@li... > 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. |
From: Jez W. <je...@je...> - 2004-01-21 10:26:21
|
Steve, I think I have found some missing events (for graphics) but before I create any bug reports I'd like to check the XS code - but were should I look? Cheers, jez. ----- Original Message ----- From: "Steve Pick" <st...@ba...> To: "Jez White" <je...@je...>; <per...@li...> Sent: Tuesday, January 20, 2004 7:01 PM Subject: Re: [perl-win32-gui-users] Accelerator bug? > 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 > |
From: Glenn W M. <gw...@fo...> - 2004-01-20 20:04:30
|
It sounds like the NEM is the way to go, then. Accordingly, I've added non-functioning accelerators to the Tracker as a bug (though I suppose it could have been a feature request according to Glenn Linderman's reply). Thinking about it, it would be nice to be able to do this: $mw->btButton->Change(-events => {Click => sub {return -1}}); but it doesn't seem to work. Is there something fundamentally wrong with the idea, or has it just not been implemented (yet)? Glenn Munroe -----Original Message----- From: Stephen Pick [mailto:Ste...@uc...] Sent: Tuesday, 20 January, 2004 07:59 To: gw...@fo...; per...@li... 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: per...@li... > [mailto:per...@li...]On Behalf Of > Glenn W Munroe > Sent: 20 January 2004 10:52 > To: per...@li... > 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: per...@li... > [mailto:per...@li...] On Behalf Of > Glenn Linderman > Sent: Monday, 19 January, 2004 21:52 > To: gw...@fo... > Cc: per...@li... > 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 > Per...@li... > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > |
From: Steve P. <st...@ba...> - 2004-01-20 20:56:16
|
> Thinking about it, it would be nice to be able to do this: > > $mw->btButton->Change(-events => {Click => sub {return -1}}); There's nothing wrong with the concept and the implementation might actually be pretty simple (all I think it needs is to bitwise-OR in the constant that says "yes, capture clicks" to the NEM event mask). It's on the todo list. Steve ----- Original Message ----- From: "Glenn W Munroe" <gw...@fo...> To: "'Stephen Pick'" <Ste...@uc...> Cc: <per...@li...> Sent: Tuesday, January 20, 2004 8:03 PM Subject: RE: [perl-win32-gui-users] Accelerator bug? > > It sounds like the NEM is the way to go, then. Accordingly, I've added > non-functioning accelerators to the Tracker as a bug (though I suppose > it could have been a feature request according to Glenn Linderman's > reply). > > Thinking about it, it would be nice to be able to do this: > > $mw->btButton->Change(-events => {Click => sub {return -1}}); > > but it doesn't seem to work. Is there something fundamentally wrong with > the idea, or has it just not been implemented (yet)? > > Glenn Munroe > > -----Original Message----- > From: Stephen Pick [mailto:Ste...@uc...] > Sent: Tuesday, 20 January, 2004 07:59 > To: gw...@fo...; per...@li... > 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: per...@li... > > [mailto:per...@li...]On Behalf Of > > Glenn W Munroe > > Sent: 20 January 2004 10:52 > > To: per...@li... > > 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: per...@li... > > [mailto:per...@li...] On Behalf Of > > Glenn Linderman > > Sent: Monday, 19 January, 2004 21:52 > > To: gw...@fo... > > Cc: per...@li... > > 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 > > Per...@li... > > 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 > > Per...@li... > > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > |