Menu
▾
▴
perl-win32-gui-users
|
From: <pau...@or...> - 2002-02-28 11:46:52
|
Hi All I've just built and packaged a PPM and sent it off to Aldo so hopefully it will be available soon. Oh, and yes - just tried out tool tips ... fantastic ! Cheers Paul ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* |
|
From: Frazier, J. J. <Joe...@Pe...> - 2002-02-28 12:22:28
|
> -----Original Message-----
> From: Aldo Calpini [mailto:dad...@al...]
> Sent: Thursday, February 28, 2002 5:02 AM
> To: Perl-Win32-GUI-Users
> Subject: [perl-win32-gui-users] Win32::GUI Release 0.0.665
>=20
>=20
> hello people,
>=20
> finally, an update! this release of Win32::GUI introduces=20
> many new features,
> the most important being:
>=20
> - the NEM (New Event Model), which allows for something like:
>=20
> $Window->AddButton(
> -text =3D> 'say hello',
> -onClick =3D> sub { print "hello, world!\n"; },
> );
Hmmm... is this the ONLY way or does the old method still work also?
> *** editor's note *** there are actually many gotchas with NEM,
> I'll elaborate more on this in a separate post.
>=20
> - tooltips are now supported on most controls with the -tip =3D> =
STRING
> option.
Super!!!!
>=20
> - ListView checkboxes can now be managed with the ItemCheck() method;
> there's also a new ItemCheck event for ListViews that gets=20
> fired when
> you toggle an item's checkbox.
Super again!
>=20
> the biggest changes are in the codebase, which is now=20
> splitted in several
> files. please note that something - particularly the NEM -=20
> may be broken
> in this release (you already knew it, huh? ;-)
Anyone going to perform some hard testing over the weekend on the new =
code and report back to the list? I would love to be able to do this, =
but working two jobs, I barely have time for my family, much less =
anything fun (yes, coding is fun for me. Since it is about the only =
thing free that I can do decently, its all I have).
Thanks Aldo!
Joe Frazier, Jr.
Technical Support Engineer
Peopleclick Service Support
Tel: +1-800-841-2365
E-Mail: mailto:su...@pe...
|
|
From: Aldo C. <dad...@al...> - 2002-02-28 13:15:42
|
Frazier, Joe Jr wrote:
> > $Window->AddButton(
> > -text => 'say hello',
> > -onClick => sub { print "hello, world!\n"; },
> > );
>
> Hmmm... is this the ONLY way or does the old method still work also?
the old method still works. but the main problem now is the interaction
between the methods. in a few words:
don't expect to use them both for the same window!
if you define a $Window with NEM events, *all* of the controls inside it
should have NEM events only, eg. no Button_Click won't work if the parent of
the Button has NEM events.
this is a little tricky, I know; in fact I proposed to add a pragma when
loading Win32::GUI, like this:
use Win32::GUI Event_Model => 'byref';
#### only NEM events in this script!
or
use Win32::GUI Event_Model => 'byname';
#### no NEM events in this script!
but I still don't know what to do when you just say use Win32::GUI ;-)
BTW, NEM events can also be specified inside a single -events option (or in
mixed style), as in:
my $Window = Win32::GUI::Window->new(
# ....
-events => {
Terminate => sub { -1 },
Activate => sub { print "here I am!\n"; },
},
-onMinimize => sub { print "no please!\n"; },
);
you can (err, should be able to, not really tested ;-) change events with
the Change() method. to cancel an event, undef it:
$Window->Change(
-onMinimize => undef,
);
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
|
|
From: Frazier, J. J. <Joe...@Pe...> - 2002-02-28 14:08:22
|
> -----Original Message-----
> From: Aldo Calpini [mailto:dad...@al...]
> Sent: Thursday, February 28, 2002 8:18 AM
> To: Frazier, Joe Jr; Perl-Win32-GUI-Users
> Subject: Re: [perl-win32-gui-users] Win32::GUI Release 0.0.665
>=20
>=20
> Frazier, Joe Jr wrote:
> > > $Window->AddButton(
> > > -text =3D> 'say hello',
> > > -onClick =3D> sub { print "hello, world!\n"; },
> > > );
> >
> > Hmmm... is this the ONLY way or does the old method still=20
> work also?
>=20
> the old method still works. but the main problem now is the=20
> interaction
> between the methods. in a few words:
>=20
> don't expect to use them both for the same window!
>=20
> if you define a $Window with NEM events, *all* of the=20
> controls inside it
> should have NEM events only, eg. no Button_Click won't work=20
> if the parent of
> the Button has NEM events.
I would probably do something simular to the way XML::SAX::* works and =
do this=20
package My::Package;
my $gui =3D My::Package->new()
.....
....
sub myhandler{
}
package main;
my $Window =3D Win32::GUI::Window->new(
# .... =20
-events =3D> {
Terminate =3D> $gui->myhandler();
Activate =3D> sub { print "here I am!\n"; },
},
-onMinimize =3D> sub { print "no please!\n"; },
);
=20
Now, the question is, how does it work to pass in stuff such as the =
listview passing the row clicked? or do we have to handle all that =
ourselves? If this is covered in the docs(are the docs more fleshed =
out?), let me know and I will check there.
>=20
> this is a little tricky, I know; in fact I proposed to add a=20
> pragma when
> loading Win32::GUI, like this:
>=20
> use Win32::GUI Event_Model =3D> 'byref';
> #### only NEM events in this script!
>=20
> or
>=20
> use Win32::GUI Event_Model =3D> 'byname';
> #### no NEM events in this script!
>=20
> but I still don't know what to do when you just say use Win32::GUI ;-)
>=20
<vote type=3D"my opinion">Use old style by default. This avoids users =
having to change thier code until they are ready to totally update thier =
code.</vote>
> BTW, NEM events can also be specified inside a single -events=20
> option (or in
> mixed style), as in:
>=20
> my $Window =3D Win32::GUI::Window->new(
> # ....
> -events =3D> {
> Terminate =3D> sub { -1 },
> Activate =3D> sub { print "here I am!\n"; },
> },
> -onMinimize =3D> sub { print "no please!\n"; },
> );
>=20
ooooooooooo! me like. =20
> you can (err, should be able to, not really tested ;-) change=20
> events with
> the Change() method. to cancel an event, undef it:
>=20
> $Window->Change(
> -onMinimize =3D> undef,
> );
>=20
>=20
Awesome! If this works, it will greatly help me with some dynamic fields =
I would like to be able to add. ie. Have a DB which builds your app =
controls for you. Not "easily" possible in the old model, but it seems =
very easy with this new model (assuming the change event thing works).
Sorry to be a pain, but i am so excited to check this out and have a few =
questions on gotchas I have ran into in the past before migrating.
Joe Frazier, Jr.
Technical Support Engineer
Peopleclick Service Support
Tel: +1-800-841-2365
E-Mail: mailto:su...@pe...
|
|
From: Aldo C. <dad...@al...> - 2002-03-01 14:54:11
|
Frazier, Joe Jr wrote:
> > but I still don't know what to do when you just say use Win32::GUI ;-)
>
> <vote type="my opinion">Use old style by default. This avoids users
> having to change thier code until they are ready to totally update thier
> code.</vote>
yes, this is sure. by default the old style is used, the problem is when you
don't use it and put an -events option on something. maybe I should
process -events options *only* if you said:
use Win32::GUI Event_Model => 'byref';
otherwise they're simply ignored.
> I would probably do something simular to the way XML::SAX::* works and
> do this
>
> [...]
>
> -events => {
> Terminate => $gui->myhandler();
not quite... should be something like:
Terminate => \&{ $gui->myhandler };
arguments to -events can be:
- a subroutine name (string)
- a reference (eg. \&)
- an anonymous sub (eg. sub { .. })
BTW, I didn't understand the use of My::Package ... but maybe it's just me.
> Now, the question is, how does it work to pass in stuff such as the
> listview passing the row clicked? or do we have to handle all that
> ourselves? If this is covered in the docs(are the docs more fleshed
> out?), let me know and I will check there.
ops, sorry, I forgot to mention this :-)
for your joy (and many other's too), all NEM events pass the object they're
referring to as their first argument, while subsequent arguments are the
same as their non-NEM counterparts.
so you can do this:
$Window->AddButton(
# ...
-name => "Button1",
-onClick => sub {
my($self) = @_;
print "you clicked button: $self->{-name}\n";
},
);
and this will print out: you clicked button: Button1
an ItemClick event for a ListView would look like:
-onItemClick => sub {
my($self, $item) = @_;
# do something with $item
},
> Sorry to be a pain, but i am so excited to check this out and have a
> few questions on gotchas I have ran into in the past before migrating.
don't worry, this kind of pain is welcome :-)
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
|
|
From: Glenn L. <Gle...@ne...> - 2002-03-04 04:21:47
|
Aldo Calpini wrote: > > Frazier, Joe Jr wrote: > > > but I still don't know what to do when you just say use Win32::GUI ;-) > > > > <vote type="my opinion">Use old style by default. This avoids users > > having to change thier code until they are ready to totally update thier > > code.</vote> > > yes, this is sure. by default the old style is used, the problem is when you > don't use it and put an -events option on something. maybe I should > process -events options *only* if you said: > > use Win32::GUI Event_Model => 'byref'; Seems like it would be possible to "merge" the old and new styles, if, when a new window or control is defined, a search of the compiled namespace would be done, and all functions defined at that time that match the "window or control name followed by underscore followed by event name" naming convention could be implicitly included into the -event list (unless they were already defined explicitly with a -event or -onEvent parameter). This would allow a gradual migration path from old to new model, for most typical Win32::GUI programs. Programs that use eval to define new methods to handle new events for new windows or controls wouldn't benefit as greatly, but the (few) places where those evals are done could be converted into Change ( -event ) calls. -- Glenn ===== Remember, 84.3% of all statistics are made up on the spot. |
|
From: Glenn L. <Gle...@ne...> - 2002-03-04 20:05:54
|
Aldo Calpini wrote:
>
> arguments to -events can be:
> - a subroutine name (string)
> - a reference (eg. \&)
> - an anonymous sub (eg. sub { .. })
Both of the following items prevent me from porting certain Win32::GUI
applications to the New Event Model.
There doesn't seem to be a way to...
1) discover the code ref for an event handler, in case you want to wrap
it in a more powerful handler, or chain the handlers, when using layered
or modular software techniques. Something like the following could be a
possible interface:
$coderef = $mw->GetEventHandler ( "Terminate" );
2) execute an event handler. Something like the following could be the
interface:
$mw->CallEventHandler ( "Terminate", @pass_through_parameters );
The handler itself would then be called with the window/control name as
its first parameter, followed with the @pass_through_parameters. The
handler's return value would be returned from CallEventHandler, but it
would generally be discarded in cases like this I suspect.
Clearly (1) is more powerful than (2), since if you can discover the
code ref, then you could clearly execute it... but (2) could be
convenient syntactic sugar for recoding cases like (old style event
model) shutting down all windows when the main window is closed:
sub Main_Terminate
{ # print "Main_Terminate\n";
& LB_Terminate ();
& PR_Terminate ();
& ED_Terminate ();
return -1;
}
--
Glenn
=====
Remember, 84.3% of all statistics are made up on the spot.
|
|
From: <Kev...@al...> - 2002-02-28 14:13:55
|
I've downloaded and compiled the new version. The only script I've had problems with so far is one based on Aldo's pride.pl example but then pride.pl doesn't work any more either. Tried a simple test with the NEM and fork() and it still works (except for the crash on exit with a double fork mentioned yesterday). Much better than TK which crashes as soon as I try a fork. Kev. |---------+------------------------------------------------> | | "Aldo Calpini" <dad...@al...> | | | Sent by: | | | per...@li...ur| | | ceforge.net | | | | | | | | | 28/02/2002 10:02 | | | | |---------+------------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: "Perl-Win32-GUI-Users" <per...@li...> | | cc: | | Subject: [perl-win32-gui-users] Win32::GUI Release 0.0.665 | >----------------------------------------------------------------------------------------------| hello people, finally, an update! this release of Win32::GUI introduces many new features, the most important being: - the NEM (New Event Model), which allows for something like: $Window->AddButton( -text => 'say hello', -onClick => sub { print "hello, world!\n"; }, ); *** editor's note *** there are actually many gotchas with NEM, I'll elaborate more on this in a separate post. - tooltips are now supported on most controls with the -tip => STRING option. - ListView checkboxes can now be managed with the ItemCheck() method; there's also a new ItemCheck event for ListViews that gets fired when you toggle an item's checkbox. the biggest changes are in the codebase, which is now splitted in several files. please note that something - particularly the NEM - may be broken in this release (you already knew it, huh? ;-) source code is available at my site (http://dada.perl.it, which is up and running again :-) and at SourceForge. PPM binaries will follow ASAP -- if someone wants to pack the binaries for us, please do it (you'll certainly be faster than me ;-) and send me the files so that I can put it online. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; _______________________________________________ Perl-Win32-GUI-Users mailing list Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users |
|
From: Glenn L. <Gle...@ne...> - 2002-03-01 05:41:42
|
Now I've downloaded and compiled the new version. Boy was I surprised! I ran an existing application, and it looked quite different in layout, but upon careful inspection, and knowing how the code was written, it appears that everything that is different is a result of exactly one thing: $font = Win32::GUI::Font->new ( -name => "Times New Roman", -size => 18, ); The above line was fiddled with by trial and error using version 558, to get the size font that I wanted. I was rather surprised at the time that the size, if expressed in points, turned out to be so small on my screen. But I was so busy learning other stuff, that I just ignored that issue.... but now it has come back to haunt me! Using version 665, the font used probably _is_ 18 points... at least it looks the same as what Word Perfect calls 18 points for that same font! So I guess this is an improvement, except that it would be nice to know if there is a scale factor that can be applied, so that an application could choose the same size font in either version of Win32::GUI. Other than the font size issue, and the resulting effects on widget layout, my forking Win32::GUI application seems to still be functional. -- Glenn ===== Remember, 84.3% of all statistics are made up on the spot. |
|
From: Glenn L. <Gle...@ne...> - 2002-03-02 07:24:30
|
Glenn Linderman wrote: > > Now I've downloaded and compiled the new version. Boy was I surprised! Here's another surprise: When moving the cursor to the edges and corners for resizing things, the cursor doesn't change to the "usual" double-headed arrows which provide feedback to the user that they are in the right position for resizing. Resizing still works, but it is awkward because of the expectation from other programs and earlier versions of Win32::GUI that the cursor should change shape for that event. -- Glenn ===== Remember, 84.3% of all statistics are made up on the spot. |
|
From: Glenn L. <Gle...@ne...> - 2002-03-01 15:11:25
|
> At Thursday, 28 February 2002, Glenn wrote: > > >Now I've downloaded and compiled the new version. Boy was I surprised! jean bosco muzatsinda wrote: > > Hi, > How did you proceed to download and compile? > I'm knew to this matter of things ( win32::GUI)and I'm experiencing > some problems. > Thanks, > > Jean Although this was a private message (inappropriate) I'm replying back to the list, because there may be a number of others that have never compiled Win32::GUI, that now suddenly have the desire to. It was my first time to ever compile a perl module, but really, it isn't too hard when things are set up right, I guess, and it seems that Aldo has things set up right. The following is what I did to download and compile: Download: used web browser, went to http://data.perl.it/, found the link for the source ( http://dada.perl.it/Win32-GUI-0.0.665.tar.gz ), and fetched it to my local hard drive, I used d:\. Using cmd.exe, I Then "gunzip Win32-GUI-0.0.665.tar.gz" Then "tar xvf Win32-GUI-0.0.665.tar" Then "cd d:\Win32-GUI-0.0.665" I used my favorite text editor, emacs, to look around. It appears that although the code has been enhanced and restructured into multiple source files, that the documentation has not yet been enhanced in any way, and also not the sample code. Then I had to experiment to see how to compile. Since I'm using ActiveState's perl, which is reportedly compiled using MS VC, I figured I'd need to get that on my path. And I remembered that when I had installed MS VC, it had told me about a batch file that can put it on the path (doesn't need to be on the path when you use the MS IDE). And I remembered seeing, over and over again on various perl lists, the comment that when using MS VC, you have to use "nmake" instead of "make". And the theoretical process for installing modules is documented as the sequence of commands: perl makefile.pl make make install So I wrote the following batch file: call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat" perl makefile.pl nmake nmake install Upon executing it from the command line prompt, where my current directory was d:\Win32-GUI-0.0.665, it seemed to do the trick. I then attempted to run a couple scripts for which I had already set up shortcuts, and lo and behold! they used the new version of Win32::GUI ! With the surprise reported earlier. -- Glenn ===== Remember, 84.3% of all statistics are made up on the spot. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X