Menu
▾
▴
perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(31) |
Dec
(80) |
| 2004 |
Jan
(30) |
Feb
(31) |
Mar
(46) |
Apr
(31) |
May
(48) |
Jun
(16) |
Jul
|
Aug
|
Sep
(20) |
Oct
(31) |
Nov
(13) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(37) |
Jul
(39) |
Aug
(22) |
Sep
(3) |
Oct
(48) |
Nov
(24) |
Dec
(31) |
| 2006 |
Jan
(4) |
Feb
(6) |
Mar
(19) |
Apr
(17) |
May
(39) |
Jun
(62) |
Jul
(11) |
Aug
(21) |
Sep
(10) |
Oct
(26) |
Nov
(8) |
Dec
|
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Aldo C. <da...@pe...> - 2004-02-23 11:48:41
|
On Mon, 2004-02-23 at 01:38, Steve Pick wrote:
> The idea for the event model is good. I noticed that we're running out of
> space to add events to the NEM because it uses the eventmask thing, and
> there's only enough bits in that for 32 events. I was wondering if that
> whole thing should be done away with, and we should not bother to check the
> event mask but rather just look up event names in the "event map" that you
> mention, then fire them if they are defined by the user.
not so directly. the big win in using an eventmask thing is that, before
trying to call the Perl event itself, Win32::GUI can do a quick bit
comparison on a C variable, and it does take an infinitesimal amount of
time. doing a hash lookup, instead, is a costly operation. not as costly
as doing a perl_call_pv, granted, but costly. if we want to keep
performance at an acceptable level (remember that NEM events are always
checked for existence, even several times in a second (think about
MouseMove)) this lookup should be implemented somehow in C, perhaps with
an ad-hoc data structure.
> I think the events code is very messy right now, supporting both NEM and OEM
> with tons of redundant code. It would (I think) be nice to start a new
> module. There are several things with Win32::GUI that need to be addressed
> and are best addressed from scratch. Things like:
erm... I wasn't talking about starting a new "module" in Perl terms, but
a new "module" in *CVS terms*, which is a quite different thing! :-)
the upcoming implementation is called Win32::GUI 1.00 in my mind, and I
see no reason to change this to something else. so, let's see if your
reason convince me :-)
> 1. Perl context bugs
this means adding a plethora of pTHX_ and aTHX_ everywhere, I suppose. I
have to check the correct formula for this, but should not be a big
deal.
> 2. Freeing Win32 objects like windows, dialogs etc. Effectively we want to
> be able to destroy these objects when their DESTROY sub is called by Perl
this can be done easily enough. the main point seems to be that a
reference to a control is placed in its parent hash. eg. if you make
$Window->AddButton( -name => 'foo'), you are adding an hash key
$Window->{foo}. so, just deleting this key and calling DestroyWindow on
the button should free all resources. the problem with DESTROY is that
the order of calling (and, in my experience, the exact time at which
this happens) is not guaranteed at all. I had all kinds of problems
trying to implement a proper DESTROY, but I can revamp my experience in
this field if this is an important issue :-)
> 3. Move away from the whole "works like Visual Basic" idea. Originally this
> was a nice plan, but this is not VB, but perl, and there are many
> differences between the languages that mean making things work similarly to
> visual basic *but with subtle differences* is actually a lot more confusing
> than making things work in a perly way, as perl coders expect them to work.
that's true, oh so true :-)
> Things like hyphens at the start of hash keys and so on should probably be
> dropped, for example. I think it's better to basically convert the relevant
> APIs (windows shell, gui and gdi) into a useable form implemented in Perl.
I think hypens at the start of hash keys are a Good Thing. remember that
controls are stored in their parent's hash, and without the hypens, you
could make a big mess out of it.
> In other words, stay close to the C API rather than VB, but give it a Perl
> twist that allows easy creation of objects (windows, buttons etc), and gives
> a good amount of functions/methods for manipulating those objects and
> sending messages to them.
well, Win32::GUI already does that. the only thing "borrowed" from VB
was the event model (eg. Button_Click). but I expect, with the new
implementation of NEM, that OEM will be absolutely deprecated. we can't
just remove it (for backward compatibility issues), but once people
realize that NEM performs a lot better, nobody will want to use OEM
anymore. but still, if they feel comfortable with OEM, they will be able
to use it.
> 4. wxPerl is eclipsing Win32::GUI, so any new module would have to continue
> Win32::GUI's track as being a module that is not, in fact, just about the
> GUI. Win32::GUI can now handle resources, controlling other processes via
> messages, drawing in GDI, etc.
well, your mileage may vary. in the past, I've used Win32::GUI to
generate bitmaps for a website (which I later converted to png, of
course) by drawing a path in a window and dumping its DC to a file. that
was because GD and other drawing techniques were not giving me the same
antialiasing on TrueType fonts that Win32::GUI did :-)
Win32::GUI never claimed to be "the killer module" for GUI frontends, so
if there's a better toolkit (which is portable also), this is not a
problem. Win32::GUI will be there if (for whatever reason) one wants to
hook directly into the Win32 SDK APIs. it's also (reportedly to me) much
simpler to program with than wx for small applications.
> 5. Better support for extending with new controls.
that's the next issue in my mind, after NEM, and is called PEM (Package
Event Model). stay tuned for more :-)
> 6. A better code structure, move all things like labels, buttons and stuff
> into their own XS code, keep GUI.xs as the main repository for common
> functions/methods that apply to all related objects. Win32::GUI has
> obviously grown kind of like fungus, with bits added on pretty much at
> random and not exactly cleanly (like my "hooks" code). This would also help
> with point 2.
that's another issue, and I can really use some help from you all. at a
certain point, I started doing such a "separation", and if you look
closely at the code, you'll see that there are several things that still
needs to be completely implemented (for example, each .xs file should
have its own onParseOption, onPreCreate, onPostCreate hooks).
we could (should?) rethink package organization based on the "nature" of
the stuff Win32::GUI does manage. for example, there are windows with
position and size (eg. Buttons, Labels, etc.) and windows which should
not have an "explicit" position and size (eg. Statusbars).
currently, the Win32::GUI package contains *all* methods that refers to
windows (and so position, size, style, etc.) as well as functions
directly imported from the Win32 SDK APIs (eg. GetTextExtentPoint32).
anyway, the code surely needs a bit of refactoring, but this is not
something that should be visible to the end user.
> 7. Ramy suggested a name change a few days ago. I like Win32::Windows, as it
> describes what Win32::GUI does a little better. The module does control
> Windows, not just the GUI. Open to debate, of course.
yes, this is the main point to debate :-)
Win32::GUI is what it is and has its history. we can extend the codebase
and add functionality to do other things than building GUI frontends,
but I'm afraid that the "core" (what most people will use this module
for) will always be GUI stuff. from another point of view, every window
on the screen, every graphical resource on the system has to do with
User Interaction, so GUI still seems a reasonable name to me. back to
the roots of the module, the Win32 "bits" it implements are mainly
USER32.DLL and GDI32.DLL. if you take the "U" from the first and the "G"
and "I" from the second, you still can make "GUI" :-)
> 8. Unicode support would be nice. I know little about unicode and am
> confused by all these API functions that have W appended to them for wide
> character functionality, and how one should use these functions
> appropriately.
well, I've never really investigated this issue. I don't think simply
appending a 'W' to API calls will do some good. the main point, I guess,
is how to seamlessly integrate Win32's idea of Unicode (which isn't
Unicode really, but rather UCS2-LE) and Perl's idea of Unicode (which is
UTF-8 really).
> Obviously if we're going to extend the module in the above ways (or write a
> new one) then we need to rename it and release it in a new form, because
> changing things like the 8 points above will really break backward compat. I
> think there are a few things that will need to be laid down at the start to
> define how we do things, like check user arguments for errors, how we
> document stuff, and so on, but all that will have to be discussed if anyone
> really wants to help take on a whole new project.
my personal opinion is to avoid breaking things that much. Perl itself
lived for something like 15 years and 5 major releases before needing to
throw backward compatibility away. we are still at 0.0.something, so
there's plenty of time :-)
still, the need to clearly *define* things before embarking on this
journey is perfectly correct. and to me, one of the biggest thing to be
defined at this point is how to document stuff. but let's this be
another topic :-).
cheers,
Aldo
|
|
From: Steve P. <st...@ba...> - 2004-02-23 00:46:00
|
Hi Aldo,
Good to hear from you again, I wondered what had happened. Sorry to hear
about the HDD problems, it's happened to me in the past and I know the
feeling.
The idea for the event model is good. I noticed that we're running out of
space to add events to the NEM because it uses the eventmask thing, and
there's only enough bits in that for 32 events. I was wondering if that
whole thing should be done away with, and we should not bother to check the
event mask but rather just look up event names in the "event map" that you
mention, then fire them if they are defined by the user.
I think the events code is very messy right now, supporting both NEM and OEM
with tons of redundant code. It would (I think) be nice to start a new
module. There are several things with Win32::GUI that need to be addressed
and are best addressed from scratch. Things like:
1. Perl context bugs
2. Freeing Win32 objects like windows, dialogs etc. Effectively we want to
be able to destroy these objects when their DESTROY sub is called by Perl
3. Move away from the whole "works like Visual Basic" idea. Originally this
was a nice plan, but this is not VB, but perl, and there are many
differences between the languages that mean making things work similarly to
visual basic *but with subtle differences* is actually a lot more confusing
than making things work in a perly way, as perl coders expect them to work.
Things like hyphens at the start of hash keys and so on should probably be
dropped, for example. I think it's better to basically convert the relevant
APIs (windows shell, gui and gdi) into a useable form implemented in Perl.
In other words, stay close to the C API rather than VB, but give it a Perl
twist that allows easy creation of objects (windows, buttons etc), and gives
a good amount of functions/methods for manipulating those objects and
sending messages to them.
4. wxPerl is eclipsing Win32::GUI, so any new module would have to continue
Win32::GUI's track as being a module that is not, in fact, just about the
GUI. Win32::GUI can now handle resources, controlling other processes via
messages, drawing in GDI, etc.
5. Better support for extending with new controls.
6. A better code structure, move all things like labels, buttons and stuff
into their own XS code, keep GUI.xs as the main repository for common
functions/methods that apply to all related objects. Win32::GUI has
obviously grown kind of like fungus, with bits added on pretty much at
random and not exactly cleanly (like my "hooks" code). This would also help
with point 2.
7. Ramy suggested a name change a few days ago. I like Win32::Windows, as it
describes what Win32::GUI does a little better. The module does control
Windows, not just the GUI. Open to debate, of course.
8. Unicode support would be nice. I know little about unicode and am
confused by all these API functions that have W appended to them for wide
character functionality, and how one should use these functions
appropriately.
Obviously if we're going to extend the module in the above ways (or write a
new one) then we need to rename it and release it in a new form, because
changing things like the 8 points above will really break backward compat. I
think there are a few things that will need to be laid down at the start to
define how we do things, like check user arguments for errors, how we
document stuff, and so on, but all that will have to be discussed if anyone
really wants to help take on a whole new project.
Steve
----- Original Message -----
From: "Aldo Calpini" <da...@pe...>
To: "Stephen Pick" <Ste...@uc...>
Cc: "Win32 GUI Hackers (E-mail)"
<per...@li...>; "Jez White (E-mail)"
<je...@je...>
Sent: Friday, February 20, 2004 4:17 PM
Subject: Re: [perl-win32-gui-hackers] Menus and NEM
> hello people :-)
>
> On Mon, 2004-02-16 at 13:53, Stephen Pick wrote:
> > Hello,
> >
> > Looks like menus are indeed a little busted. You can't use both
> > event models on a menu. You can use either the NEM or the OEM, but
> > you can't selectively use NEM here and OEM there. If you add a menu
> > to a window that is using the NEM and your window uses OEM, your menu
> > won't work. Your menu's event model must match that of the window
> > you're adding it into.
>
> as I said a lot of time ago, the current OEM/NEM interoperability
> implementation is going to die. there's too much broken code in there,
> and I thought of a way to simplify things a lot (but they will be
> managed a little bit differently).
>
> the last time I wrote here, I promised a document describing the new
> architecture that I'm going to implement, but in the mean time a damn
> stupid 120 GB external USB HD ate my development directory. more than 1
> GB of stuff, more than 6 years of development, sigh :-(
>
> so, the whole thing exists only in my mind now.
>
> basically, the idea is the following: there will be a single messageloop
> for each window (including controls), which, in pseudocode, should do
> something like this:
>
> if(event_model & BYREF) {
> if(window->eventmap(event_id)) {
> event = window->events{get_event_name(event_id)};
> fire_event(event);
> }
> }
> if(event_model & BYNAME) {
> event_name = window->name . "_" . get_event_name(event_id);
> if(event = perl_get_cv(event_name)) {
> fire_event(event);
> }
> }
>
> the biggest implication is that the OEM (BYNAME event model) will
> probably result a little bit slower: that's because each message to each
> control will trigger a perl_get_cv call (which is orders of magnitude
> slower than a C instruction). on the other hand, every control will have
> the whole range of events (eg. MouseMove, MouseClick, etc.) enabled by
> default.
>
> event_model in the code above is a global variable in C which will be
> controlled by a method (Win32::GUI::SetEventModel or something like
> that) or by a directive in use (eg. use Win32::GUI EventModel =>
> 'BYREF').
>
> I'm a little (oh, well, a little is not enough :-) behind with the
> situation on CVS, but I'm ready to implement this architectural change.
>
> should we branch the CVS repository (or create a new module, which
> sounds better to me) or is the current status quiet enough to begin
> working on this for the next release?
>
>
> cheers,
> Aldo
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
|
|
From: Aldo C. <da...@pe...> - 2004-02-20 16:32:10
|
hello people :-)
On Mon, 2004-02-16 at 13:53, Stephen Pick wrote:
> Hello,
>
> Looks like menus are indeed a little busted. You can't use both
> event models on a menu. You can use either the NEM or the OEM, but
> you can't selectively use NEM here and OEM there. If you add a menu
> to a window that is using the NEM and your window uses OEM, your menu
> won't work. Your menu's event model must match that of the window
> you're adding it into.
as I said a lot of time ago, the current OEM/NEM interoperability
implementation is going to die. there's too much broken code in there,
and I thought of a way to simplify things a lot (but they will be
managed a little bit differently).
the last time I wrote here, I promised a document describing the new
architecture that I'm going to implement, but in the mean time a damn
stupid 120 GB external USB HD ate my development directory. more than 1
GB of stuff, more than 6 years of development, sigh :-(
so, the whole thing exists only in my mind now.
basically, the idea is the following: there will be a single messageloop
for each window (including controls), which, in pseudocode, should do
something like this:
if(event_model & BYREF) {
if(window->eventmap(event_id)) {
event = window->events{get_event_name(event_id)};
fire_event(event);
}
}
if(event_model & BYNAME) {
event_name = window->name . "_" . get_event_name(event_id);
if(event = perl_get_cv(event_name)) {
fire_event(event);
}
}
the biggest implication is that the OEM (BYNAME event model) will
probably result a little bit slower: that's because each message to each
control will trigger a perl_get_cv call (which is orders of magnitude
slower than a C instruction). on the other hand, every control will have
the whole range of events (eg. MouseMove, MouseClick, etc.) enabled by
default.
event_model in the code above is a global variable in C which will be
controlled by a method (Win32::GUI::SetEventModel or something like
that) or by a directive in use (eg. use Win32::GUI EventModel =>
'BYREF').
I'm a little (oh, well, a little is not enough :-) behind with the
situation on CVS, but I'm ready to implement this architectural change.
should we branch the CVS repository (or create a new module, which
sounds better to me) or is the current status quiet enough to begin
working on this for the next release?
cheers,
Aldo
|
|
From: Stephen P. <Ste...@uc...> - 2004-02-19 11:10:16
|
Goody Gumdrops.
=20
Just committed a change to CVS so that icons, bitmaps and cursors =
created in the standard way are first checked for in the EXE file that =
loaded Win32::GUI. Now there are some little points of note:
=20
1. Doesnt work with PAR (unless you're a sneaky bugger). The reason it =
doesnt work with PAR is because PAR is just a self-extracting archive =
that auto-runs a perl interpreter on extraction. If you want to =
compile-in resources with PAR you'll need to add the resources to =
whatever interpreter executable it puts inside it's archive (looks like =
it's par.exe) rather than the exe file actually generated by PAR.
=20
2. If I play around with perl2exe-generated executables in ResHacker, =
they either crash or fail to even start. This might be some sort of =
"don't you hack me!" protection inside the evaluation version of =
perl2exe, but it seems odd.
=20
3. Not tried it with perlapp, I hope it works with this.
=20
4. When adding resources with ResHacker, give the resource the same name =
as you passed for the filename of new Win32::GUI::Bitmap/Icon/Cursor. =
For instance, if you're doing new Win32::GUI::Bitmap("two.bmp") then =
your resource should have the name "TWO.BMP".
=20
I had to test this by ResHackering my perl executable. Hopefully someone =
out there has shelled out for perl2exe full version or perlapp, and if =
that's the case then please test this on those two tools to see if it =
works.
=20
Feedback please.
=20
Steve
=20
-----Original Message-----
From: per...@li... =
[mailto:per...@li...]On Behalf Of =
Jez White
Sent: 19 February 2004 09:46
To: Steve Pick; Win32-GUI
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe
I agree with your analysis - I especially like the idea of bitmaps, =
Icons and cursors to check for resources first, and then to look at the =
file system (would solve the problem of running in "dev" mode with the =
perl command line, or running the exe direct).=20
=20
How easy would it to be load other binary objects in from the exe? For =
example, having other image formats or storable created objects.
=20
As for adding resources - I can see the benefits of having a native =
solution, but it would create massive scope to mess around with the perl =
exe:) Perhaps the first step is to point to ResHacker, with a step by =
step guide on how to use it?
=20
jez.
=20
=20
----- Original Message -----=20
From: Steve Pick <mailto:st...@ba...> =20
To: Jez White <mailto:je...@je...> ; Win32-GUI =
<mailto:per...@li...> =20
Sent: Wednesday, February 18, 2004 10:40 PM
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe
I'd find this functionality kinda handy. Loading resources from the exe =
is very simple, and it would not be too difficult to extend the =
Win32::GUI::Bitmap, Icon, etc. objects to accept an additional argument =
that indicates that the resource should be loaded from the exe rather =
than from a real file on disk (in fact, it would actually be a trivial =
matter to do this).
=20
What is less trivial is getting the resources in there in the first =
place. While ResHacker lets you do it, it'd be nice to see a Win32::GUI =
native way of doing it. Microsoft provides functions for adding, =
deleting and replacing resources in executable files and I propose we =
either:
=20
1. Add this update/add/delete functionality into Win32::GUI so that =
applications can fiddle with their own resources. This may be an =
exceptionally bad idea (what exe file will it think it's using when =
running straight from Perl? We dont want it messing with perl.exe's =
resources)
=20
2. Create a small tool that is distributed with Win32::GUI to pack =
resources into the exe. I doubt we can re-dist ResHacker with win32::gui =
and it'd be nice if there was this functionality provided. The =
Win32::GUI::Bitmap, Icon and Cursor objects could then be modified to =
first check for a resource identified by the given filename in the =
current running exe, and if it's not found attempt to use the given =
filename to load an external file. This seems the best mode of operation =
to me.
=20
Steve
----- Original Message -----=20
From: Jez White <mailto:je...@je...> =20
To: Win32-GUI <mailto:per...@li...> =20
Sent: Wednesday, February 18, 2004 6:34 PM
Subject: [perl-win32-gui-users] Shipping resources with your exe
Hi,
=20
One the problems I have when I ship my exe is ensuring that all the =
resources (bitmaps, cursors and config files) are valid when my app =
starts up. Typically, just including them in a sub directory can cause =
problems since the user could delete or alter them. The ideal solution =
would be to package the resources into the exe and extract them at =
runtime. See:=20
=20
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winui/=
WinUI/WindowsUserInterface/Resources.asp
=20
Adding the resources to the exe is quite straightforward (with =
reshacker) but I'm not sure how easy it would be to implement these =
function calls (or even it is possible), would anyone find this kind of =
functionality useful?=20
=20
Cheers,
=20
jez.
|
|
From: Jez W. <je...@je...> - 2004-02-18 15:00:46
|
Cool. I'll have a play when I can see the changes.
----- Original Message -----=20
From: "Stephen Pick" <Ste...@uc...>
To: "Jez White" <je...@je...>; "Win32 GUI Hackers (E-mail)=
"
<per...@li...>
Sent: Wednesday, February 18, 2004 12:29 PM
Subject: Addition: [perl-win32-gui-hackers] CVS update: Toolbars
To enable tooltips you need to do something like this:
$TB->SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT|1|TBSTYLE_LIST|TBSTYLE_TOO=
LTI
PS);
$TB->SetExtendedStyle(0x00000008);
0x00000008 is the TBSTYLE_EX_MIXEDBUTTONS style which is only compiled in=
if
the constant _WIN32_IE is greater or equal to 0x0501. You can set this in
GUI.h, and I see no reason for it to remain forced at 0x0401 as this is
*OLD*, so I've updated it to 0x0501 as that basically means "IE 5 install=
ed"
which everyone in their right mind has.
CVS committed.
Steve
> -----Original Message-----
> From: per...@li...
> [mailto:per...@li...]On
> Behalf Of
> Jez White
> Sent: 18 February 2004 10:03
> To: Steve Pick; Win32 GUI Hackers (E-mail)
> Subject: Re: [perl-win32-gui-hackers] CVS update: Toolbars
>
>
> Hi,
>
> I've had a play and it seems ok - although I'm having a few
> problems with
> some of the styles - but this could be me:)
>
> The example below creates a toolbar with a few buttons (run
> in the samples
> folder for it to pick up the bitmaps) which are added via image lists.
> If I use the SetStyle method (with any style) the toolbar
> ends up at the
> bottem of the window. I've yet to get any functionality working with
> SetExtendedStyle (I was trying to get tooltips working with
> the toolbar
> using the text from the buttons).
>
> Just me?
>
> Cheers,
>
> jez.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> use Win32::GUI;
>
> $W =3D new Win32::GUI::Window(
> -title =3D> "Win32::GUI::Toolbar test",
> -left =3D> 100,
> -top =3D> 100,
> -width =3D> 500,
> -height =3D> 400,
> -name =3D> "Window",
> );
>
> $B1 =3D new Win32::GUI::Bitmap("one.bmp");
> $B2 =3D new Win32::GUI::Bitmap("two.bmp");
> $B3 =3D new Win32::GUI::Bitmap("three.bmp");
> $IL =3D new Win32::GUI::ImageList(16, 16, 0, 3, 10);
> $IL->Add($B1, 0);
> $IL->Add($B2, 0);
> $IL->Add($B3, 0);
>
> $TB =3D $W->AddToolbar(
> -left =3D> 0,
> -top =3D> 0,
> -width =3D> 300,
> -height =3D> 100,
> -name =3D> "Toolbar",
> -addstyle =3D> 0x0800,
> );
> $TB->SetImageList($IL);
> #$TB->SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT);
> #$TB->SetExtendedStyle(TBSTYLE_EX_MIXEDBUTTONS|TBSTYLE_EX_DRAW
> DDARROWS);
> $Bh1 =3D new Win32::GUI::Bitmap("three.bmp");
> $Bh2 =3D new Win32::GUI::Bitmap("one.bmp");
> $Bh3 =3D new Win32::GUI::Bitmap("two.bmp");
> $ILhot =3D new Win32::GUI::ImageList(16, 16, 0, 3, 10);
> $ILhot->Add($Bh1, 0);
> $ILhot->Add($Bh2, 0);
> $ILhot->Add($Bh3, 0);
> $TB->SetHotImageList($ILhot);
> $TB->AddButtons(
> 4,
> 0, 1, 4, 0, 0,
> 1, 2, 4, 0, 1,
> 0, 0, 0, TBSTYLE_SEP, 0,
> 2, 3, 4, 0, 2,
> );
> $TB->AddString("One");
> $TB->AddString("Two");
> $TB->AddString("Three");
>
> $W->Show;
>
> Win32::GUI::Dialog();
>
>
> sub Window_Terminate {
> return -1;
> }
>
> sub Window_Resize {
> $TB->Resize($W->ScaleWidth-10, 100);
> }
>
> sub Toolbar_ButtonClick {
> my($button) =3D @_;
> print "Toolbar: clicked button $button\n";
> }
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
|
|
From: Stephen P. <Ste...@uc...> - 2004-02-18 12:34:58
|
To enable tooltips you need to do something like this:
$TB->SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT|1|TBSTYLE_LIST|TBSTYLE_TOO=
LTIPS);
$TB->SetExtendedStyle(0x00000008);
0x00000008 is the TBSTYLE_EX_MIXEDBUTTONS style which is only compiled =
in if the constant _WIN32_IE is greater or equal to 0x0501. You can set =
this in GUI.h, and I see no reason for it to remain forced at 0x0401 as =
this is *OLD*, so I've updated it to 0x0501 as that basically means "IE =
5 installed" which everyone in their right mind has.
CVS committed.
Steve
> -----Original Message-----
> From: per...@li...
> [mailto:per...@li...]On=20
> Behalf Of
> Jez White
> Sent: 18 February 2004 10:03
> To: Steve Pick; Win32 GUI Hackers (E-mail)
> Subject: Re: [perl-win32-gui-hackers] CVS update: Toolbars
>=20
>=20
> Hi,
>=20
> I've had a play and it seems ok - although I'm having a few=20
> problems with
> some of the styles - but this could be me:)
>=20
> The example below creates a toolbar with a few buttons (run=20
> in the samples
> folder for it to pick up the bitmaps) which are added via image lists.
> If I use the SetStyle method (with any style) the toolbar=20
> ends up at the
> bottem of the window. I've yet to get any functionality working with
> SetExtendedStyle (I was trying to get tooltips working with=20
> the toolbar
> using the text from the buttons).
>=20
> Just me?
>=20
> Cheers,
>=20
> jez.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> use Win32::GUI;
>=20
> $W =3D new Win32::GUI::Window(
> -title =3D> "Win32::GUI::Toolbar test",
> -left =3D> 100,
> -top =3D> 100,
> -width =3D> 500,
> -height =3D> 400,
> -name =3D> "Window",
> );
>=20
> $B1 =3D new Win32::GUI::Bitmap("one.bmp");
> $B2 =3D new Win32::GUI::Bitmap("two.bmp");
> $B3 =3D new Win32::GUI::Bitmap("three.bmp");
> $IL =3D new Win32::GUI::ImageList(16, 16, 0, 3, 10);
> $IL->Add($B1, 0);
> $IL->Add($B2, 0);
> $IL->Add($B3, 0);
>=20
> $TB =3D $W->AddToolbar(
> -left =3D> 0,
> -top =3D> 0,
> -width =3D> 300,
> -height =3D> 100,
> -name =3D> "Toolbar",
> -addstyle =3D> 0x0800,
> );
> $TB->SetImageList($IL);
> #$TB->SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT);
> #$TB->SetExtendedStyle(TBSTYLE_EX_MIXEDBUTTONS|TBSTYLE_EX_DRAW
> DDARROWS);
> $Bh1 =3D new Win32::GUI::Bitmap("three.bmp");
> $Bh2 =3D new Win32::GUI::Bitmap("one.bmp");
> $Bh3 =3D new Win32::GUI::Bitmap("two.bmp");
> $ILhot =3D new Win32::GUI::ImageList(16, 16, 0, 3, 10);
> $ILhot->Add($Bh1, 0);
> $ILhot->Add($Bh2, 0);
> $ILhot->Add($Bh3, 0);
> $TB->SetHotImageList($ILhot);
> $TB->AddButtons(
> 4,
> 0, 1, 4, 0, 0,
> 1, 2, 4, 0, 1,
> 0, 0, 0, TBSTYLE_SEP, 0,
> 2, 3, 4, 0, 2,
> );
> $TB->AddString("One");
> $TB->AddString("Two");
> $TB->AddString("Three");
>=20
> $W->Show;
>=20
> Win32::GUI::Dialog();
>=20
>=20
> sub Window_Terminate {
> return -1;
> }
>=20
> sub Window_Resize {
> $TB->Resize($W->ScaleWidth-10, 100);
> }
>=20
> sub Toolbar_ButtonClick {
> my($button) =3D @_;
> print "Toolbar: clicked button $button\n";
> }
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>=20
|
|
From: Stephen P. <Ste...@uc...> - 2004-02-18 12:14:52
|
Yep, it will shift down to the bottom when you do SetStyle because =
you're replacing the styles. The common control style CCS_TOP is applied =
by default on new toolbars, but as soon as you do SetStyle you remove =
this style unless you explicitly add it into your setstyle call.
CCS_TOP is defined as 1, so to make the toolbar appear at the top of the =
window with setstyle use:
$TB->SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT|1);
I'm unsure as to whether to put this in by default. I think I'll add an =
option to the constructor so that you can specify where the toolbar is.
Steve
> -----Original Message-----
> From: per...@li...
> [mailto:per...@li...]On=20
> Behalf Of
> Jez White
> Sent: 18 February 2004 10:03
> To: Steve Pick; Win32 GUI Hackers (E-mail)
> Subject: Re: [perl-win32-gui-hackers] CVS update: Toolbars
>=20
>=20
> Hi,
>=20
> I've had a play and it seems ok - although I'm having a few=20
> problems with
> some of the styles - but this could be me:)
>=20
> The example below creates a toolbar with a few buttons (run=20
> in the samples
> folder for it to pick up the bitmaps) which are added via image lists.
> If I use the SetStyle method (with any style) the toolbar=20
> ends up at the
> bottem of the window. I've yet to get any functionality working with
> SetExtendedStyle (I was trying to get tooltips working with=20
> the toolbar
> using the text from the buttons).
>=20
> Just me?
>=20
> Cheers,
>=20
> jez.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> use Win32::GUI;
>=20
> $W =3D new Win32::GUI::Window(
> -title =3D> "Win32::GUI::Toolbar test",
> -left =3D> 100,
> -top =3D> 100,
> -width =3D> 500,
> -height =3D> 400,
> -name =3D> "Window",
> );
>=20
> $B1 =3D new Win32::GUI::Bitmap("one.bmp");
> $B2 =3D new Win32::GUI::Bitmap("two.bmp");
> $B3 =3D new Win32::GUI::Bitmap("three.bmp");
> $IL =3D new Win32::GUI::ImageList(16, 16, 0, 3, 10);
> $IL->Add($B1, 0);
> $IL->Add($B2, 0);
> $IL->Add($B3, 0);
>=20
> $TB =3D $W->AddToolbar(
> -left =3D> 0,
> -top =3D> 0,
> -width =3D> 300,
> -height =3D> 100,
> -name =3D> "Toolbar",
> -addstyle =3D> 0x0800,
> );
> $TB->SetImageList($IL);
> #$TB->SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT);
> #$TB->SetExtendedStyle(TBSTYLE_EX_MIXEDBUTTONS|TBSTYLE_EX_DRAW
> DDARROWS);
> $Bh1 =3D new Win32::GUI::Bitmap("three.bmp");
> $Bh2 =3D new Win32::GUI::Bitmap("one.bmp");
> $Bh3 =3D new Win32::GUI::Bitmap("two.bmp");
> $ILhot =3D new Win32::GUI::ImageList(16, 16, 0, 3, 10);
> $ILhot->Add($Bh1, 0);
> $ILhot->Add($Bh2, 0);
> $ILhot->Add($Bh3, 0);
> $TB->SetHotImageList($ILhot);
> $TB->AddButtons(
> 4,
> 0, 1, 4, 0, 0,
> 1, 2, 4, 0, 1,
> 0, 0, 0, TBSTYLE_SEP, 0,
> 2, 3, 4, 0, 2,
> );
> $TB->AddString("One");
> $TB->AddString("Two");
> $TB->AddString("Three");
>=20
> $W->Show;
>=20
> Win32::GUI::Dialog();
>=20
>=20
> sub Window_Terminate {
> return -1;
> }
>=20
> sub Window_Resize {
> $TB->Resize($W->ScaleWidth-10, 100);
> }
>=20
> sub Toolbar_ButtonClick {
> my($button) =3D @_;
> print "Toolbar: clicked button $button\n";
> }
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>=20
|
|
From: Jez W. <je...@je...> - 2004-02-18 10:07:50
|
Hi,
I've had a play and it seems ok - although I'm having a few problems with
some of the styles - but this could be me:)
The example below creates a toolbar with a few buttons (run in the samples
folder for it to pick up the bitmaps) which are added via image lists.
If I use the SetStyle method (with any style) the toolbar ends up at the
bottem of the window. I've yet to get any functionality working with
SetExtendedStyle (I was trying to get tooltips working with the toolbar
using the text from the buttons).
Just me?
Cheers,
jez.
==============
use Win32::GUI;
$W = new Win32::GUI::Window(
-title => "Win32::GUI::Toolbar test",
-left => 100,
-top => 100,
-width => 500,
-height => 400,
-name => "Window",
);
$B1 = new Win32::GUI::Bitmap("one.bmp");
$B2 = new Win32::GUI::Bitmap("two.bmp");
$B3 = new Win32::GUI::Bitmap("three.bmp");
$IL = new Win32::GUI::ImageList(16, 16, 0, 3, 10);
$IL->Add($B1, 0);
$IL->Add($B2, 0);
$IL->Add($B3, 0);
$TB = $W->AddToolbar(
-left => 0,
-top => 0,
-width => 300,
-height => 100,
-name => "Toolbar",
-addstyle => 0x0800,
);
$TB->SetImageList($IL);
#$TB->SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT);
#$TB->SetExtendedStyle(TBSTYLE_EX_MIXEDBUTTONS|TBSTYLE_EX_DRAWDDARROWS);
$Bh1 = new Win32::GUI::Bitmap("three.bmp");
$Bh2 = new Win32::GUI::Bitmap("one.bmp");
$Bh3 = new Win32::GUI::Bitmap("two.bmp");
$ILhot = new Win32::GUI::ImageList(16, 16, 0, 3, 10);
$ILhot->Add($Bh1, 0);
$ILhot->Add($Bh2, 0);
$ILhot->Add($Bh3, 0);
$TB->SetHotImageList($ILhot);
$TB->AddButtons(
4,
0, 1, 4, 0, 0,
1, 2, 4, 0, 1,
0, 0, 0, TBSTYLE_SEP, 0,
2, 3, 4, 0, 2,
);
$TB->AddString("One");
$TB->AddString("Two");
$TB->AddString("Three");
$W->Show;
Win32::GUI::Dialog();
sub Window_Terminate {
return -1;
}
sub Window_Resize {
$TB->Resize($W->ScaleWidth-10, 100);
}
sub Toolbar_ButtonClick {
my($button) = @_;
print "Toolbar: clicked button $button\n";
}
|
|
From: Jez W. <je...@je...> - 2004-02-17 20:29:18
|
Hi,
No problem. I'll be giving it a good test tomorrow. I think I've found a =
bug
with the listview background change - some of my list views have a thin
black band on one side (on XP, with XP styles and without, I've yet to tr=
y
it on other versions of windows). I'll create a test example once I've
looked at it a little more.
Thanks for the work - some real good enhancements going in.
Cheers,
jez.
----- Original Message -----=20
From: "Steve Pick" <st...@ba...>
To: "Jez White" <je...@je...>; "Win32 GUI Hackers (E-mail)=
"
<per...@li...>
Sent: Tuesday, February 17, 2004 8:16 PM
Subject: Re: [perl-win32-gui-hackers] CVS update: Toolbars
> Hi Jez,
>
> I didnt say there wouldn't be bugs in it :)
>
> I've updated the CVS, it was a stupid mistake (casting a tooltip handle=
to
> an imagelist handle - DUH), so it should work now. Let me know of any
other
> bugs, I'm sure there will be plenty as I did not have time to fully tes=
t
> things like imagelists on it.
>
> Steve
>
> ----- Original Message -----=20
> From: "Jez White" <je...@je...>
> To: "Stephen Pick" <Ste...@uc...>; "Win32 GUI Hackers (E-mail=
)"
> <per...@li...>
> Sent: Tuesday, February 17, 2004 7:24 PM
> Subject: Re: [perl-win32-gui-hackers] CVS update: Toolbars
>
>
> I'm having problems building using ming. I get the following error:
>
> C:\development\Win32-GUI-0.0.670>nmake install
>
> Microsoft (R) Program Maintenance Utility Version 1.50
> Copyright (c) Microsoft Corp 1988-94. All rights reserved.
>
> C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib
> C:\Perl\lib\ExtUtils/xs
> ubpp -typemap C:\Perl\lib\ExtUtils\typemap -typemap typemap Toolbar.xs=
>
> Toolba
> r.cpp
>
>
>
>
>
gcc -c -g -O2 -DWIN32 -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -f=
no-
>
trict-aliasing -DPERL_MSVCRT_READFIX -g -O2 -DVERSION=3D\"0.0.670\" -=
DXS_
> VERS
> ION=3D\"0.0.670\" -DHASATTRIBUTE -IC:\Perl\lib\CORE -D__MINGW__ Toolbar=
.cpp
> Toolbar.xs: In function `BOOL Toolbar_onParseOption(char*, SV*,
> tagPERLWIN32GUI_CREATESTRUCT*)':
> Toolbar.xs:24: cannot convert `_IMAGELIST*' to `HWND__*' in assignment
> Toolbar.xs: In function `void
> XS_Win32__GUI__Toolbar_ChangeBitmap(PerlInterpreter*, CV*)':
> Toolbar.xs:320: warning: cast from pointer to integer of different size
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x1'
> Stop.
>
> If I comment out the line, it builds ok.
>
> Cheers,
>
> jez.
> ----- Original Message -----=20
> From: "Stephen Pick" <Ste...@uc...>
> To: "Win32-Gui-Users (E-mail)"
<per...@li...>;
> "Win32 GUI Hackers (E-mail)"
<per...@li...>
> Sent: Tuesday, February 17, 2004 1:58 PM
> Subject: [perl-win32-gui-hackers] CVS update: Toolbars
>
>
> Hi,
>
> I've just spent the morning converting and documenting Rammy's perl
toolbar
> functions into XS. They're now in the CVS.
>
> The new functions are as follows:
> # (@)METHOD:SetButtonState(BUTTON, STATE)
> # (@)METHOD:SetStyle(STYLE)
> # (@)METHOD:SetExtendedStyle(STYLE)
> # (@)METHOD:GetStyle(STYLE)
> # (@)METHOD:MoveButton(BUTTON, TARGET)
> # (@)METHOD:SetImageList(IMAGELIST)
> # (@)METHOD:SetHotImageList(IMAGELIST)
> # (@)METHOD:SetDisabledImageList(IMAGELIST)
> # (@)METHOD:GetImageList()
> # (@)METHOD:GetHotImageList()
> # (@)METHOD:GetDisabledImageList()
> # (@)METHOD:ChangeBitmap(BUTTON, BITMAP)
> # (@)METHOD:CheckButton(BUTTON, CHECKED)
> # (@)METHOD:DeleteButton(BUTTON)
> # (@)METHOD:SetToolTips(TOOLTIP)
>
> SetToolTips is not really needed, as you should be able to assign a
tooltip
> object using the -tooltip option when constructing the toolbar now. Sam=
e
> thing with SetImageList; you should be able to use -imagelist to set an
> imagelist now.
>
> Note that there is already a Padding() method for the toolbar so I didn=
t
add
> Rammy's padding one which seemed to do a similar thing. I've also
> (hopefully) fixed the "tooltips crash application on exit" bug that
appeared
> when I ran Rammy's test code.
>
> There is some safety checking on SetImageList, AddBitmap and ChangeBitm=
ap.
> You cannot call SetImageList and AddBitmap/ChangeBitmap on the same
toolbar
> as microsoft says this would be a really bad idea, so you get a croak
about
> it if you try it.
>
> Another thing is, I've modified the ButtonClick event so that when a
button
> that has the TBSTYLE_DROPDOWN style applied to it is clicked, an extra
> argument gets passed to ButtonClick with the value of 1. This allows yo=
u
to
> tell if you need to show a drop-down menu.
>
> There have been a ton of constants added to GUI.pm and GUI_Constants.cp=
p,
so
> you can use most of the regular toolbar styles, extended styles, button
> styles etc. One word of warning is to avoid using the BTNS_*** constant=
s
and
> use the TBSTYLE_*** equivalents instead, as the availability of the
BTNS_***
> constants depends on the headers and compiler used (they're a new thing=
).
>
> I added dwFlags to the USERDATA and CREATESTRUCT structs. This dword is
> intended to store any per-object flags needed. for instance, the toolba=
r
> uses FLAGS_TB_HASBITMAPS to remember if AddBitmap has been called and
> complain if the user attempts to SetImageList on the same toolbar objec=
t.
> Developers: add flags as you see fit.
>
> One last thing. We're running out of mask bits in the NEM. Are they rea=
lly
> needed? The mask only appears to be used as a speed thing (to avoid doi=
ng
a
> hash lookup for each event) so perhaps it would be more sensible to gro=
up
> some events together or something? Thoughts please...
>
> Steve
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
|
|
From: Steve P. <st...@ba...> - 2004-02-17 20:21:16
|
Hi Jez,
I didnt say there wouldn't be bugs in it :)
I've updated the CVS, it was a stupid mistake (casting a tooltip handle to
an imagelist handle - DUH), so it should work now. Let me know of any other
bugs, I'm sure there will be plenty as I did not have time to fully test
things like imagelists on it.
Steve
----- Original Message -----
From: "Jez White" <je...@je...>
To: "Stephen Pick" <Ste...@uc...>; "Win32 GUI Hackers (E-mail)"
<per...@li...>
Sent: Tuesday, February 17, 2004 7:24 PM
Subject: Re: [perl-win32-gui-hackers] CVS update: Toolbars
I'm having problems building using ming. I get the following error:
C:\development\Win32-GUI-0.0.670>nmake install
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib
C:\Perl\lib\ExtUtils/xs
ubpp -typemap C:\Perl\lib\ExtUtils\typemap -typemap typemap Toolbar.xs >
Toolba
r.cpp
gcc -c -g -O2 -DWIN32 -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-
strict-aliasing -DPERL_MSVCRT_READFIX -g -O2 -DVERSION=\"0.0.670\" -DXS_
VERS
ION=\"0.0.670\" -DHASATTRIBUTE -IC:\Perl\lib\CORE -D__MINGW__ Toolbar.cpp
Toolbar.xs: In function `BOOL Toolbar_onParseOption(char*, SV*,
tagPERLWIN32GUI_CREATESTRUCT*)':
Toolbar.xs:24: cannot convert `_IMAGELIST*' to `HWND__*' in assignment
Toolbar.xs: In function `void
XS_Win32__GUI__Toolbar_ChangeBitmap(PerlInterpreter*, CV*)':
Toolbar.xs:320: warning: cast from pointer to integer of different size
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1'
Stop.
If I comment out the line, it builds ok.
Cheers,
jez.
----- Original Message -----
From: "Stephen Pick" <Ste...@uc...>
To: "Win32-Gui-Users (E-mail)" <per...@li...>;
"Win32 GUI Hackers (E-mail)" <per...@li...>
Sent: Tuesday, February 17, 2004 1:58 PM
Subject: [perl-win32-gui-hackers] CVS update: Toolbars
Hi,
I've just spent the morning converting and documenting Rammy's perl toolbar
functions into XS. They're now in the CVS.
The new functions are as follows:
# (@)METHOD:SetButtonState(BUTTON, STATE)
# (@)METHOD:SetStyle(STYLE)
# (@)METHOD:SetExtendedStyle(STYLE)
# (@)METHOD:GetStyle(STYLE)
# (@)METHOD:MoveButton(BUTTON, TARGET)
# (@)METHOD:SetImageList(IMAGELIST)
# (@)METHOD:SetHotImageList(IMAGELIST)
# (@)METHOD:SetDisabledImageList(IMAGELIST)
# (@)METHOD:GetImageList()
# (@)METHOD:GetHotImageList()
# (@)METHOD:GetDisabledImageList()
# (@)METHOD:ChangeBitmap(BUTTON, BITMAP)
# (@)METHOD:CheckButton(BUTTON, CHECKED)
# (@)METHOD:DeleteButton(BUTTON)
# (@)METHOD:SetToolTips(TOOLTIP)
SetToolTips is not really needed, as you should be able to assign a tooltip
object using the -tooltip option when constructing the toolbar now. Same
thing with SetImageList; you should be able to use -imagelist to set an
imagelist now.
Note that there is already a Padding() method for the toolbar so I didnt add
Rammy's padding one which seemed to do a similar thing. I've also
(hopefully) fixed the "tooltips crash application on exit" bug that appeared
when I ran Rammy's test code.
There is some safety checking on SetImageList, AddBitmap and ChangeBitmap.
You cannot call SetImageList and AddBitmap/ChangeBitmap on the same toolbar
as microsoft says this would be a really bad idea, so you get a croak about
it if you try it.
Another thing is, I've modified the ButtonClick event so that when a button
that has the TBSTYLE_DROPDOWN style applied to it is clicked, an extra
argument gets passed to ButtonClick with the value of 1. This allows you to
tell if you need to show a drop-down menu.
There have been a ton of constants added to GUI.pm and GUI_Constants.cpp, so
you can use most of the regular toolbar styles, extended styles, button
styles etc. One word of warning is to avoid using the BTNS_*** constants and
use the TBSTYLE_*** equivalents instead, as the availability of the BTNS_***
constants depends on the headers and compiler used (they're a new thing).
I added dwFlags to the USERDATA and CREATESTRUCT structs. This dword is
intended to store any per-object flags needed. for instance, the toolbar
uses FLAGS_TB_HASBITMAPS to remember if AddBitmap has been called and
complain if the user attempts to SetImageList on the same toolbar object.
Developers: add flags as you see fit.
One last thing. We're running out of mask bits in the NEM. Are they really
needed? The mask only appears to be used as a speed thing (to avoid doing a
hash lookup for each event) so perhaps it would be more sensible to group
some events together or something? Thoughts please...
Steve
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=ick
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=ick
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
|
|
From: Jez W. <je...@je...> - 2004-02-17 19:28:54
|
I'm having problems building using ming. I get the following error:
C:\development\Win32-GUI-0.0.670>nmake install
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib
C:\Perl\lib\ExtUtils/xs
ubpp -typemap C:\Perl\lib\ExtUtils\typemap -typemap typemap Toolbar.xs >
Toolba
r.cpp
gcc -c -g -O2 -DWIN32 -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -f=
no-
strict-aliasing -DPERL_MSVCRT_READFIX -g -O2 -DVERSION=3D\"0.0.670\" =
-DXS_
VERS
ION=3D\"0.0.670\" -DHASATTRIBUTE -IC:\Perl\lib\CORE -D__MINGW__ Toolbar.c=
pp
Toolbar.xs: In function `BOOL Toolbar_onParseOption(char*, SV*,
tagPERLWIN32GUI_CREATESTRUCT*)':
Toolbar.xs:24: cannot convert `_IMAGELIST*' to `HWND__*' in assignment
Toolbar.xs: In function `void
XS_Win32__GUI__Toolbar_ChangeBitmap(PerlInterpreter*, CV*)':
Toolbar.xs:320: warning: cast from pointer to integer of different size
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0=
x1'
Stop.
If I comment out the line, it builds ok.
Cheers,
jez.
----- Original Message -----=20
From: "Stephen Pick" <Ste...@uc...>
To: "Win32-Gui-Users (E-mail)" <per...@li...=
t>;
"Win32 GUI Hackers (E-mail)" <per...@li...=
t>
Sent: Tuesday, February 17, 2004 1:58 PM
Subject: [perl-win32-gui-hackers] CVS update: Toolbars
Hi,
I've just spent the morning converting and documenting Rammy's perl toolb=
ar
functions into XS. They're now in the CVS.
The new functions are as follows:
# (@)METHOD:SetButtonState(BUTTON, STATE)
# (@)METHOD:SetStyle(STYLE)
# (@)METHOD:SetExtendedStyle(STYLE)
# (@)METHOD:GetStyle(STYLE)
# (@)METHOD:MoveButton(BUTTON, TARGET)
# (@)METHOD:SetImageList(IMAGELIST)
# (@)METHOD:SetHotImageList(IMAGELIST)
# (@)METHOD:SetDisabledImageList(IMAGELIST)
# (@)METHOD:GetImageList()
# (@)METHOD:GetHotImageList()
# (@)METHOD:GetDisabledImageList()
# (@)METHOD:ChangeBitmap(BUTTON, BITMAP)
# (@)METHOD:CheckButton(BUTTON, CHECKED)
# (@)METHOD:DeleteButton(BUTTON)
# (@)METHOD:SetToolTips(TOOLTIP)
SetToolTips is not really needed, as you should be able to assign a toolt=
ip
object using the -tooltip option when constructing the toolbar now. Same
thing with SetImageList; you should be able to use -imagelist to set an
imagelist now.
Note that there is already a Padding() method for the toolbar so I didnt =
add
Rammy's padding one which seemed to do a similar thing. I've also
(hopefully) fixed the "tooltips crash application on exit" bug that appea=
red
when I ran Rammy's test code.
There is some safety checking on SetImageList, AddBitmap and ChangeBitmap=
.
You cannot call SetImageList and AddBitmap/ChangeBitmap on the same toolb=
ar
as microsoft says this would be a really bad idea, so you get a croak abo=
ut
it if you try it.
Another thing is, I've modified the ButtonClick event so that when a butt=
on
that has the TBSTYLE_DROPDOWN style applied to it is clicked, an extra
argument gets passed to ButtonClick with the value of 1. This allows you =
to
tell if you need to show a drop-down menu.
There have been a ton of constants added to GUI.pm and GUI_Constants.cpp,=
so
you can use most of the regular toolbar styles, extended styles, button
styles etc. One word of warning is to avoid using the BTNS_*** constants =
and
use the TBSTYLE_*** equivalents instead, as the availability of the BTNS_=
***
constants depends on the headers and compiler used (they're a new thing).
I added dwFlags to the USERDATA and CREATESTRUCT structs. This dword is
intended to store any per-object flags needed. for instance, the toolbar
uses FLAGS_TB_HASBITMAPS to remember if AddBitmap has been called and
complain if the user attempts to SetImageList on the same toolbar object.
Developers: add flags as you see fit.
One last thing. We're running out of mask bits in the NEM. Are they reall=
y
needed? The mask only appears to be used as a speed thing (to avoid doing=
a
hash lookup for each event) so perhaps it would be more sensible to group
some events together or something? Thoughts please...
Steve
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
|
|
From: Stephen P. <Ste...@uc...> - 2004-02-17 14:03:19
|
Hi, I've just spent the morning converting and documenting Rammy's perl = toolbar functions into XS. They're now in the CVS. The new functions are as follows: # (@)METHOD:SetButtonState(BUTTON, STATE) # (@)METHOD:SetStyle(STYLE) # (@)METHOD:SetExtendedStyle(STYLE) # (@)METHOD:GetStyle(STYLE) # (@)METHOD:MoveButton(BUTTON, TARGET) # (@)METHOD:SetImageList(IMAGELIST) # (@)METHOD:SetHotImageList(IMAGELIST) # (@)METHOD:SetDisabledImageList(IMAGELIST) # (@)METHOD:GetImageList() # (@)METHOD:GetHotImageList() # (@)METHOD:GetDisabledImageList() # (@)METHOD:ChangeBitmap(BUTTON, BITMAP) # (@)METHOD:CheckButton(BUTTON, CHECKED) # (@)METHOD:DeleteButton(BUTTON) # (@)METHOD:SetToolTips(TOOLTIP) SetToolTips is not really needed, as you should be able to assign a = tooltip object using the -tooltip option when constructing the toolbar = now. Same thing with SetImageList; you should be able to use -imagelist = to set an imagelist now. Note that there is already a Padding() method for the toolbar so I didnt = add Rammy's padding one which seemed to do a similar thing. I've also = (hopefully) fixed the "tooltips crash application on exit" bug that = appeared when I ran Rammy's test code. There is some safety checking on SetImageList, AddBitmap and = ChangeBitmap. You cannot call SetImageList and AddBitmap/ChangeBitmap on = the same toolbar as microsoft says this would be a really bad idea, so = you get a croak about it if you try it. Another thing is, I've modified the ButtonClick event so that when a = button that has the TBSTYLE_DROPDOWN style applied to it is clicked, an = extra argument gets passed to ButtonClick with the value of 1. This = allows you to tell if you need to show a drop-down menu. There have been a ton of constants added to GUI.pm and = GUI_Constants.cpp, so you can use most of the regular toolbar styles, = extended styles, button styles etc. One word of warning is to avoid = using the BTNS_*** constants and use the TBSTYLE_*** equivalents = instead, as the availability of the BTNS_*** constants depends on the = headers and compiler used (they're a new thing). I added dwFlags to the USERDATA and CREATESTRUCT structs. This dword is = intended to store any per-object flags needed. for instance, the toolbar = uses FLAGS_TB_HASBITMAPS to remember if AddBitmap has been called and = complain if the user attempts to SetImageList on the same toolbar = object. Developers: add flags as you see fit. One last thing. We're running out of mask bits in the NEM. Are they = really needed? The mask only appears to be used as a speed thing (to = avoid doing a hash lookup for each event) so perhaps it would be more = sensible to group some events together or something? Thoughts please... Steve |
|
From: Glenn L. <pe...@ne...> - 2004-02-16 20:07:19
|
Way back when, I tried to convert a whole program to NEM, and menus didn't work at all. And I'd converted them to NEM too, I thought. But maybe I did something wrong. I'll try again after the next release of Win32::GUI. On approximately 2/16/2004 4:53 AM, came the following characters from the keyboard of Stephen Pick: > Hello, > > Looks like menus are indeed a little busted. You can't use both event models on a menu. You can use either the NEM or the OEM, but you can't selectively use NEM here and OEM there. If you add a menu to a window that is using the NEM and your window uses OEM, your menu won't work. Your menu's event model must match that of the window you're adding it into. > > This is because menu commands are processed in their parent window's wndproc, and the wndproc assigned to a window depends on the event model it is using. A bit of bashing and hacking on my (and others) part could make multi-event-model menus work properly, but I'd like to know if this functionality is actually required by anyone. I mean, if you're a NEM user you're going to use the NEM for everything, and if you're an OEM user you're going to use the OEM for everything. So is there any point to allowing you to mix and match in menus? > > I'm inclined to believe "yes" just for flexibility, but if I discover that it looks too annoying to implement I might change my mind to "no". > > Steve > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id56&alloc_id438&op=click > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > > -- 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-02-16 13:56:20
|
Interesting. Now I know what the problem is I can use a work around (create a child window within the main window being the parent, then attach all controls = to the child :) ) In an ideal world it should be fixed - but I can see the logic for not do= ing it. In my case, I'm trying to convert my app to exclusively use NEM but keep running into various problems - such as this one:) Most of my app is stil= l OEM... Cheers, jez. ----- Original Message -----=20 From: "Stephen Pick" <Ste...@uc...> To: "Win32 GUI Hackers (E-mail)" <per...@li...>; "Jez White (E-mail)" <je...@je...> Sent: Monday, February 16, 2004 12:53 PM Subject: [perl-win32-gui-hackers] Menus and NEM Hello, Looks like menus are indeed a little busted. You can't use both event mod= els on a menu. You can use either the NEM or the OEM, but you can't selective= ly use NEM here and OEM there. If you add a menu to a window that is using t= he NEM and your window uses OEM, your menu won't work. Your menu's event mod= el must match that of the window you're adding it into. This is because menu commands are processed in their parent window's wndproc, and the wndproc assigned to a window depends on the event model = it is using. A bit of bashing and hacking on my (and others) part could make multi-event-model menus work properly, but I'd like to know if this functionality is actually required by anyone. I mean, if you're a NEM use= r you're going to use the NEM for everything, and if you're an OEM user you= 're going to use the OEM for everything. So is there any point to allowing yo= u to mix and match in menus? I'm inclined to believe "yes" just for flexibility, but if I discover tha= t it looks too annoying to implement I might change my mind to "no". Steve ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick _______________________________________________ Perl-Win32-GUI-Hackers mailing list Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers |
|
From: Stephen P. <Ste...@uc...> - 2004-02-16 12:57:18
|
Hello, Looks like menus are indeed a little busted. You can't use both event = models on a menu. You can use either the NEM or the OEM, but you can't = selectively use NEM here and OEM there. If you add a menu to a window = that is using the NEM and your window uses OEM, your menu won't work. = Your menu's event model must match that of the window you're adding it = into. This is because menu commands are processed in their parent window's = wndproc, and the wndproc assigned to a window depends on the event model = it is using. A bit of bashing and hacking on my (and others) part could = make multi-event-model menus work properly, but I'd like to know if this = functionality is actually required by anyone. I mean, if you're a NEM = user you're going to use the NEM for everything, and if you're an OEM = user you're going to use the OEM for everything. So is there any point = to allowing you to mix and match in menus? I'm inclined to believe "yes" just for flexibility, but if I discover = that it looks too annoying to implement I might change my mind to "no". Steve |
|
From: Stephen P. <Ste...@uc...> - 2004-02-16 12:31:19
|
Regular malloc seems to fail too. This is now really confusing. Steve > -----Original Message----- > From: per...@li... > [mailto:per...@li...]On=20 > Behalf Of > Stephen Pick > Sent: 16 February 2004 12:14 > To: Win32 GUI Hackers (E-mail) > Subject: [perl-win32-gui-hackers] safemalloc() not safe? >=20 >=20 > Hi, >=20 > Firstly - what on earth is safemalloc()? It seems to be=20 > documented in old patches to the perl 5.005 API, but not since then. >=20 > Secondly - safemalloc() seems to fail when reserving space=20 > for text label strings in the InsertItem function of=20 > TreeView.xs. The samples/pmx.pl file distributed with the=20 > Win32::GUI 665 PPM is a good example of the crash, just=20 > comment out "use blib" at the start. It probably won't crash=20 > on your machine (since I'm guessing this is dependent on=20 > circumstance). >=20 > The crash varies. Sometimes it is a null pointer assignment=20 > (memory at "0x0000000" could not be "written"). Sometimes it=20 > is an access violation. I don't understand why safefree is=20 > doing this, it's only allocating 3 or 4 bytes of RAM so it's=20 > not like that's a problem. The line is: >=20 > pszText =3D (LPSTR) safemalloc(tlen); >=20 > tlen is defined OK. >=20 > Is there something that we should be using instead of=20 > safemalloc() because safemalloc does not appear to be safe. >=20 > Steve >=20 >=20 > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers >=20 |
|
From: Stephen P. <Ste...@uc...> - 2004-02-16 12:18:15
|
Hi, Firstly - what on earth is safemalloc()? It seems to be documented in = old patches to the perl 5.005 API, but not since then. Secondly - safemalloc() seems to fail when reserving space for text = label strings in the InsertItem function of TreeView.xs. The = samples/pmx.pl file distributed with the Win32::GUI 665 PPM is a good = example of the crash, just comment out "use blib" at the start. It = probably won't crash on your machine (since I'm guessing this is = dependent on circumstance). The crash varies. Sometimes it is a null pointer assignment (memory at = "0x0000000" could not be "written"). Sometimes it is an access = violation. I don't understand why safefree is doing this, it's only = allocating 3 or 4 bytes of RAM so it's not like that's a problem. The = line is: pszText =3D (LPSTR) safemalloc(tlen); tlen is defined OK. Is there something that we should be using instead of safemalloc() = because safemalloc does not appear to be safe. Steve |
|
From: Stephen P. <Ste...@uc...> - 2004-02-16 11:09:16
|
Whoa PMX is shoddy. =20 I got the message you mentioned when I first tried it, but after that I = get "Memory could not be 'read'" at 0x0000000. If I disable all the NEM = stuff and then go to the about screen, when I click OK the program locks = up. =20 I'm looking into the crash out of curiosity. If something can cause a = crash like that then it's not good and must be fixed. =20 Steve -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 15 February 2004 15:59 To: guihackers Subject: [perl-win32-gui-hackers] Strange behaviour in the NEM - Bugs? Hi, For a while I've been having strange behaviour in the NEM - I've always = assumed it was something that I was doing (or not doing). Basically it's = when you mix NEM and OEM. As an example, look at pmx.pl in the samples = folder. It mainly uses OEM, but has a couple of NEM calls.=20 =20 If you run it from the command line, and select any menu item, you get = an=20 =20 "Undefined subroutine &main:: called at pmx.pl line 383." =20 If you comment out the two places that use NEM calls (line 43, and lines = 79 to 81) the program runs fine. =20 I've tried -eventmodel but this makes no difference. =20 Is this a bug? =20 Cheers, =20 jez. =20 =20 |
|
From: Jez W. <je...@je...> - 2004-02-15 16:01:38
|
Hi, For a while I've been having strange behaviour in the NEM - I've always = assumed it was something that I was doing (or not doing). Basically it's = when you mix NEM and OEM. As an example, look at pmx.pl in the samples = folder. It mainly uses OEM, but has a couple of NEM calls.=20 If you run it from the command line, and select any menu item, you get = an=20 "Undefined subroutine &main:: called at pmx.pl line 383." If you comment out the two places that use NEM calls (line 43, and lines = 79 to 81) the program runs fine. I've tried -eventmodel but this makes no difference. Is this a bug? Cheers, jez. |
|
From: Jez W. <je...@je...> - 2004-02-03 13:00:15
|
My 2 pence worth: Another release - it would keep the momentum going... ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...> To: "Win32 GUI Hackers" <per...@li...> Sent: Tuesday, February 03, 2004 1:53 AM Subject: [perl-win32-gui-hackers] notta lotta > Hi, > > There's not been a lot of traffic in the last few days, but maybe that > is because everyone is fighting MyDoom? > > If instead it is because we've reached a nice quiescent point in > Win32::GUI development, maybe it would be a good time to do another > release? It has been a month since the last one, and there have been > significant enhancements made. Not to say there isn't more that could > be done... > > Looks like Steve has implemented all the stuff I need to port a couple > applications from OEM to NEM, but if I do that, I'd like to be able to > tell my clients that it is based on the latest released version of > Win32::GUI ... which also makes it easier to distribute. > > Of course, if someone is off busily implementing something else major, > and will be done soon, then waiting might be appropriate... but > releasing another version would help us keep up the perceived momentum. > > -- > 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-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers |
|
From: Stephen P. <Ste...@uc...> - 2004-02-03 10:17:08
|
Perhaps the silence is due to me being away for a week ;) I'm back now, ready to fix stuff once more, though churning through all the messages on the Users list is a bit of a pain. I think we should do another release. I see no reason not to, especially now that SourceForge seems to be behaving itself again. It'd be nice to see the updated docs in the next release, and it'd also be nice to see some entry or other on the News section on the sf.net project page. The last one is ages old. Steve > -----Original Message----- > From: per...@li... > [mailto:per...@li...]On=20 > Behalf Of > Glenn Linderman > Sent: 03 February 2004 01:54 > To: Win32 GUI Hackers > Subject: [perl-win32-gui-hackers] notta lotta >=20 >=20 > Hi, >=20 > There's not been a lot of traffic in the last few days, but=20 > maybe that=20 > is because everyone is fighting MyDoom? >=20 > If instead it is because we've reached a nice quiescent point in=20 > Win32::GUI development, maybe it would be a good time to do another=20 > release? It has been a month since the last one, and there have been=20 > significant enhancements made. Not to say there isn't more=20 > that could=20 > be done... >=20 > Looks like Steve has implemented all the stuff I need to port=20 > a couple=20 > applications from OEM to NEM, but if I do that, I'd like to=20 > be able to=20 > tell my clients that it is based on the latest released version of=20 > Win32::GUI ... which also makes it easier to distribute. >=20 > Of course, if someone is off busily implementing something=20 > else major,=20 > and will be done soon, then waiting might be appropriate... but=20 > releasing another version would help us keep up the perceived=20 > momentum. >=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-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers >=20 |
|
From: Glenn L. <pe...@ne...> - 2004-02-03 01:54:03
|
Hi, There's not been a lot of traffic in the last few days, but maybe that is because everyone is fighting MyDoom? If instead it is because we've reached a nice quiescent point in Win32::GUI development, maybe it would be a good time to do another release? It has been a month since the last one, and there have been significant enhancements made. Not to say there isn't more that could be done... Looks like Steve has implemented all the stuff I need to port a couple applications from OEM to NEM, but if I do that, I'd like to be able to tell my clients that it is based on the latest released version of Win32::GUI ... which also makes it easier to distribute. Of course, if someone is off busily implementing something else major, and will be done soon, then waiting might be appropriate... but releasing another version would help us keep up the perceived momentum. -- 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: Laurent R. <ro...@cl...> - 2004-01-26 16:18:44
|
OK, Rebar patch commit on CVS.
The -eventmodel option is a general Window option.
But, it's probably affect only container window (Main window and =
dialog).
When use Both value, first it's try to handle event using NEM and if not =
found a event handler try to use OEM model. =20
Laurent.
----- Original Message -----=20
From: Jez White=20
To: Laurent ROCHER ; Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 9:47 PM
Subject: Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes
Well, you learn something new everyday:) I just did a quick search and =
there is no documentation for this option - is it just used for each =
window, with all the child controls effected?
Time for the pub...
Cheers,
jez.
----- Original Message -----=20
From: Laurent ROCHER=20
To: Jez White ; Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 8:13 PM
Subject: Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes
No, this option exist since NEN is add to Win32::GUI.
It's enable using of both NEM/OEM model.
Valid value are 'byname' (OEM), 'byref' (NEM) and 'both' (OEM/NEM)
Laurent.
----- Original Message -----=20
From: Jez White=20
To: Laurent ROCHER ; Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 9:02 PM
Subject: Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes
The option -eventmodel =3D> 'both' - is this new?
I have been experiencing really odd problems as I've been =
converting my app from OEM to NEM - I had assumed it was my code - Is =
there problems using a mixture of OEM and NEM?
Thanks,
jez.
----- Original Message -----=20
From: Laurent ROCHER=20
To: Jez White ; Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 7:55 PM
Subject: Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes
I try to commit on CVS but Developer CVS access will be offline =
for maintenance :(
I found and correct BandInfo crash. I have add some new methods =
too.
See change in attached file.
For me, HeightChange don't work only if you use NEM in main =
window and OEM for Rebar.
It work in pure OEM model or pure NEM model.
Problem is in NEM_WindowMsgLoop.
Set default PerlResult value to -2.=20
And add option below in your main window for use both NEM/EOM.
-eventmodel =3D> 'both',
Laurent.
----- Original Message -----=20
From: Jez White=20
To: Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 2:47 PM
Subject: [perl-win32-gui-hackers] Rebar.xs - Some Changes
Hi,
I've gone through Rebar.xs and added documentation for all the =
methods - I've also created two new methods, ShowBand and HideBand.
The method BandInfo is broken (causes a crash). The ChangeBand =
method is missing, and would be similar in structure to BandInfo - but =
both are beyond my skills to fix/add. There are a couple of useful =
missing methods and events but I couldn't get them working.
The event HeightChange works, but only under NEM.
The major issue left is to be able to add a toolbar to one of =
the bands. >From my basic understanding of the code Win32::GUI expects a =
parent window when creating a toolbar, so there is no way to create a =
stand alone tool bar which can then added to a rebar band (a good =
example of this =
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/shellc=
c/platform/commctls/rebar/rebar.asp )
I've also got a couple of examples that may be worth adding to =
the samples directory - has this been created on CVS yet?
I've created a tracker item for the problems.
I would be grateful if someone could commit these changes.
Cheers,
jez.
|
|
From: Steve P. <st...@ba...> - 2004-01-25 01:47:47
|
In this commit: AbsLeft and AbsTop now can take arguments: AbsLeft(10) sets the absolute left co-ordinate of a window to 10 pixels, for example. GetEvent(name) will return the coderef for the specified NEM event handler. "name" should be an event name like "Resize". SetEvent(name, handler) will set the coderef for the specified NEM event handler. "name" should be an event name, and "handler" should be a code reference to a subroutine that will handle the event. You can use this to change event handlers to something else if you need to. Steve. |
|
From: Jez W. <je...@je...> - 2004-01-23 20:47:30
|
Well, you learn something new everyday:) I just did a quick search and =
there is no documentation for this option - is it just used for each =
window, with all the child controls effected?
Time for the pub...
Cheers,
jez.
----- Original Message -----=20
From: Laurent ROCHER=20
To: Jez White ; Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 8:13 PM
Subject: Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes
No, this option exist since NEN is add to Win32::GUI.
It's enable using of both NEM/OEM model.
Valid value are 'byname' (OEM), 'byref' (NEM) and 'both' (OEM/NEM)
Laurent.
----- Original Message -----=20
From: Jez White=20
To: Laurent ROCHER ; Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 9:02 PM
Subject: Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes
The option -eventmodel =3D> 'both' - is this new?
I have been experiencing really odd problems as I've been converting =
my app from OEM to NEM - I had assumed it was my code - Is there =
problems using a mixture of OEM and NEM?
Thanks,
jez.
----- Original Message -----=20
From: Laurent ROCHER=20
To: Jez White ; Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 7:55 PM
Subject: Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes
I try to commit on CVS but Developer CVS access will be offline =
for maintenance :(
I found and correct BandInfo crash. I have add some new methods =
too.
See change in attached file.
For me, HeightChange don't work only if you use NEM in main window =
and OEM for Rebar.
It work in pure OEM model or pure NEM model.
Problem is in NEM_WindowMsgLoop.
Set default PerlResult value to -2.=20
And add option below in your main window for use both NEM/EOM.
-eventmodel =3D> 'both',
Laurent.
----- Original Message -----=20
From: Jez White=20
To: Win32 GUI Hackers=20
Sent: Friday, January 23, 2004 2:47 PM
Subject: [perl-win32-gui-hackers] Rebar.xs - Some Changes
Hi,
I've gone through Rebar.xs and added documentation for all the =
methods - I've also created two new methods, ShowBand and HideBand.
The method BandInfo is broken (causes a crash). The ChangeBand =
method is missing, and would be similar in structure to BandInfo - but =
both are beyond my skills to fix/add. There are a couple of useful =
missing methods and events but I couldn't get them working.
The event HeightChange works, but only under NEM.
The major issue left is to be able to add a toolbar to one of =
the bands. From my basic understanding of the code Win32::GUI expects a =
parent window when creating a toolbar, so there is no way to create a =
stand alone tool bar which can then added to a rebar band (a good =
example of this =
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/shellc=
c/platform/commctls/rebar/rebar.asp )
I've also got a couple of examples that may be worth adding to =
the samples directory - has this been created on CVS yet?
I've created a tracker item for the problems.
I would be grateful if someone could commit these changes.
Cheers,
jez.
|
18 messages has been excluded from this view by a project administrator.
