perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension

[perl-win32-gui-hackers] New commit

[Jez W. <je...@je...>]

All,

I've just committed the following:

    - DC.XS
       + Added SetBrushOrgEx Method
       + Added GetBrushOrgEx Method
    - GUI.XS
       + Added LockWindowUpdate Method
       + Added GetKeyboardState Function
       + Added GetAsyncKeyState Function

In the case of GetKeyboardState and GetAsyncKeyState I have kept the =
functionality the same as in Adhoc.pm (i.e., GetKeyboardState returns an =
array references of the virtual keys).=20

I think that most (if not all) of the functionality that was in Adhoc is =
now in base Win32::gui in one form or another.

Cheers,

jez.

Re: [perl-win32-gui-hackers] Added Center method for a window

[Johan L. <jo...@Da...>]

At 20:15 2004-04-22, Jez White wrote:
>The exception is GetKeyboardState. There are various possibilities for
>implementation - but it would depend on how people are using it. I actually
>use this function myself (to test if the CTRL key and other keys are pressed
>at the same time). Any thoughts on an interface? The easy solution would be
>to return a reference to the array (like now) - but there might be a better
>suited "Perl solution"?

For me that works fine. I don't know of any other people using it, so... :)

Some other way to do it would be to return a hash ref, but I don't quite 
see the point.


/J


>If your wondering why I'm going to add these functions, I've found that the
>runtime memory size of one of my exe's reduces by just under one meg if I
>remove all dependency to AdHoc.

I can imagine it's the line
my $rsSetBrushOrgEx = new Win32::API("gdi32", "SetBrushOrgEx", "NNNP", "I") 
or die();
which loads the gdi32 dll. Try and remove it from your copy and see if it 
helps. If it does, I can change it to create a singleton object on the 
first invocation so it won't affect you if you don't use it.


/J

-------- ------ ---- --- -- --  --  -    -     -      -         -
Johan Lindström   Sourcerer @ Boss Casinos   jo...@Da...

Latest bookmark: "Laziness, Lizards and Monks"
http://www.perlmonks.org/index.pl?node_id=247497
dmoz (1 of 10): /Computers/Programming/Internet/CGI/ 40

Re: [perl-win32-gui-hackers] Added Center method for a window

[Jez W. <je...@je...>]

Hi,

I've just had a look through the functions of AdHoc (I've got version 0.0=
3).
Most of the functions are quite straightforward (even for me!) to convert
into XS, or already have been.

The exception is GetKeyboardState. There are various possibilities for
implementation - but it would depend on how people are using it. I actual=
ly
use this function myself (to test if the CTRL key and other keys are pres=
sed
at the same time). Any thoughts on an interface? The easy solution would =
be
to return a reference to the array (like now) - but there might be a bett=
er
suited "Perl solution"?

If your wondering why I'm going to add these functions, I've found that t=
he
runtime memory size of one of my exe's reduces by just under one meg if I
remove all dependency to AdHoc.

Cheers,

jez.
----- Original Message -----=20
From: "Johan Lindstrom" <jo...@Da...>
To: "guihackers" <per...@li...>
Sent: Thursday, April 22, 2004 5:36 PM
Subject: Re: [perl-win32-gui-hackers] Added Center method for a window


> At 18:22 2004-04-22, Jez White wrote:
> >Sorry. I can put your name in if you wish - or remove it all together?
>
> Just put me up as a general contributor or something. A per method
> attribution seems ridiculous :)
>
>
> >I was looking at some of the other functions in Adhoc (with an idea of
> >adding them to GUI) - DrawIcon would be quite useful (as a method to a=
n
Icon
> >or DC). Thoughts?
>
> I would be happy if as much as possible went into the core, so long as
it's
> functional and useful.
>
>
> /J
>
> -------- ------ ---- --- -- --  --  -    -     -      -         -
> Johan Lindstr=F6m   Sourcerer @ Boss Casinos   jo...@Da...
>
> Latest bookmark: "A 3D FPS game with SDL, OpenGL and Perl - Downl..."
> http://bloodgate.com/perl/sdl/download.html
> dmoz (1 of 10): /Computers/Software/Freeware/Games/ 22
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers

Re: [perl-win32-gui-hackers] Added Center method for a window

[Jez W. <je...@je...>]

> Just put me up as a general contributor or something. A per method
> attribution seems ridiculous :)

I've added your name to the actual code. Apologies again.

> I would be happy if as much as possible went into the core, so long as
it's
> functional and useful.

I've also just added The DrawIcon method to DC.xs. Usage:

  my $DC = $win->GetDC;
  my $icon = new Win32::GUI::Icon('someicon.ico');
  $DC->DrawIcon($icon,20,20);

Cheers,

jez.

Re: [perl-win32-gui-hackers] Added Center method for a window

[Johan L. <jo...@Da...>]

At 18:22 2004-04-22, Jez White wrote:
>Sorry. I can put your name in if you wish - or remove it all together?

Just put me up as a general contributor or something. A per method 
attribution seems ridiculous :)


>I was looking at some of the other functions in Adhoc (with an idea of
>adding them to GUI) - DrawIcon would be quite useful (as a method to an Icon
>or DC). Thoughts?

I would be happy if as much as possible went into the core, so long as it's 
functional and useful.


/J

-------- ------ ---- --- -- --  --  -    -     -      -         -
Johan Lindström   Sourcerer @ Boss Casinos   jo...@Da...

Latest bookmark: "A 3D FPS game with SDL, OpenGL and Perl - Downl..."
http://bloodgate.com/perl/sdl/download.html
dmoz (1 of 10): /Computers/Software/Freeware/Games/ 22

Re: [perl-win32-gui-hackers] Added Center method for a window

[Jez W. <je...@je...>]

Sorry. I can put your name in if you wish - or remove it all together?

I was looking at some of the other functions in Adhoc (with an idea of
adding them to GUI) - DrawIcon would be quite useful (as a method to an I=
con
or DC). Thoughts?

Cheers,

jez.
----- Original Message -----=20
From: "Johan Lindstrom" <jo...@Da...>
To: "guihackers" <per...@li...>
Sent: Thursday, April 22, 2004 5:16 PM
Subject: Re: [perl-win32-gui-hackers] Added Center method for a window


> At 18:03 2004-04-22, Jez White wrote:
> >I've just committed a change to GUI.pm. The method Center which (surpr=
ise
> >surprise) centers the window :)
> >
> >The code originally came from Adhoc.pm (I've no idea who the original
> >author was, so couldn't credit them directly).
>
> That's me, but never mind.
>
>
> /J
>
> -------- ------ ---- --- -- --  --  -    -     -      -         -
> Johan Lindstr=F6m   Sourcerer @ Boss Casinos   jo...@Da...
>
> Latest bookmark: "A 3D FPS game with SDL, OpenGL and Perl - Downl..."
> http://bloodgate.com/perl/sdl/download.html
> dmoz (1 of 10): /Computers/Software/Freeware/Games/ 22
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers

Re: [perl-win32-gui-hackers] Added Center method for a window

[Johan L. <jo...@Da...>]

At 18:03 2004-04-22, Jez White wrote:
>I've just committed a change to GUI.pm. The method Center which (surprise 
>surprise) centers the window :)
>
>The code originally came from Adhoc.pm (I've no idea who the original 
>author was, so couldn't credit them directly).

That's me, but never mind.


/J

-------- ------ ---- --- -- --  --  -    -     -      -         -
Johan Lindström   Sourcerer @ Boss Casinos   jo...@Da...

Latest bookmark: "A 3D FPS game with SDL, OpenGL and Perl - Downl..."
http://bloodgate.com/perl/sdl/download.html
dmoz (1 of 10): /Computers/Software/Freeware/Games/ 22

[perl-win32-gui-hackers] Added Center method for a window

[Jez W. <je...@je...>]

Hi,

I've just committed a change to GUI.pm. The method Center which =
(surprise surprise) centers the window :)

The code originally came from Adhoc.pm (I've no idea who the original =
author was, so couldn't credit them directly).

Cheers,

jez.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

Thanks for the quick response... I'm off camping for the rest of the 
week but I'll play with this some when I get back.

So one would think that an appropriate "untie" would be possible, to 
allow Window destruction.


On approximately 4/19/2004 8:17 AM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi,
> 
> Yes, you right, i break TIED window property.
> You can reactivate it by changing in _new methods :
>     my $self = tie %tier, $class, $oself;
> By :
>     tie %tier, $class, $oself;
>     my $self = bless \%tier, $class;
> 
> I mode this change when i want to add Window destruuction when undef a perl
> window reference.
> But, i have trouble when this feature is activated.
> 
> You can replace hard coded window type constant by
> Win32::GUI::constant("WIN32__GUI__DIALOG", 0).
> 
> Laurent
> 
> 
> 
>>Hi Laurent,
>>
>>I got the compile working with the new SDK variables set up.  (Lots of
>>other stuff going on, so slow progress.  Nice to have CVS set up so I
>>can easily pick up and compile the latest changes now).
>>
>>So my first step was to test the new GUI, with a functioning OEM script.
>>  It failed.
>>
>>Upon investigation, it seems that one used to be able to make a new window
>>
>>   $mw = Win32::GUI::Window->new( -name => 'Main', ... );
>>
>>and then add a button
>>
>>   $but = $mw->AddButton( -name => 'b_nl', ..., -width => 24, ... );
>>
>>And then do things like
>>
>>   print "but-width: $but->{'-width'}\n";
>>
>>and get back the 24.
>>
>>Now this always seemed very mysterious to me, because there was no data
>>member of the hash referenced by $but named '-width'.  However, when I
>>had found the %TwoWayMethodMap in gui.pm which contained "-width" as one
>>of the entries, I convinced myself that this "fashionable" but not
>>understood technique was how the sort of print statement above could work.
>>
>>Unfortunately, the above code sequence doesn't work on the latest CVS
>>version.  The print statement just prints "but-width:" without the 24 :(
>>So we need to decide if this is something we want to have keep working,
>>so that we can stay "fashionable".
>>
>>Clearly, I could call Width() directly, but the borrowed code would need
>>significant modification, because is uses many of the fashionable
>>techniques!
>>
>>The item below is clearly an internal, but I am less sure whether the
>>above behavior should be considered internal or external.
>>
>>So I also noticed that the object types got renumbered to remove the gap
>>after WIN32__GUI__DIALOG ... some code I'd borrowed had also depended on
>>that, but since it was just discriminating between WINDOW & DIALOG and
>>"all the rest", I could simply change the "> 10" test to "> 1", and that
>>works for all versions of Win32::GUI.
>>
> 
> 
> 
> 
> 

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

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi,

Yes, you right, i break TIED window property.
You can reactivate it by changing in _new methods :
    my $self = tie %tier, $class, $oself;
By :
    tie %tier, $class, $oself;
    my $self = bless \%tier, $class;

I mode this change when i want to add Window destruuction when undef a perl
window reference.
But, i have trouble when this feature is activated.

You can replace hard coded window type constant by
Win32::GUI::constant("WIN32__GUI__DIALOG", 0).

Laurent


> Hi Laurent,
>
> I got the compile working with the new SDK variables set up.  (Lots of
> other stuff going on, so slow progress.  Nice to have CVS set up so I
> can easily pick up and compile the latest changes now).
>
> So my first step was to test the new GUI, with a functioning OEM script.
>   It failed.
>
> Upon investigation, it seems that one used to be able to make a new window
>
>    $mw = Win32::GUI::Window->new( -name => 'Main', ... );
>
> and then add a button
>
>    $but = $mw->AddButton( -name => 'b_nl', ..., -width => 24, ... );
>
> And then do things like
>
>    print "but-width: $but->{'-width'}\n";
>
> and get back the 24.
>
> Now this always seemed very mysterious to me, because there was no data
> member of the hash referenced by $but named '-width'.  However, when I
> had found the %TwoWayMethodMap in gui.pm which contained "-width" as one
> of the entries, I convinced myself that this "fashionable" but not
> understood technique was how the sort of print statement above could work.
>
> Unfortunately, the above code sequence doesn't work on the latest CVS
> version.  The print statement just prints "but-width:" without the 24 :(
> So we need to decide if this is something we want to have keep working,
> so that we can stay "fashionable".
>
> Clearly, I could call Width() directly, but the borrowed code would need
> significant modification, because is uses many of the fashionable
> techniques!
>
> The item below is clearly an internal, but I am less sure whether the
> above behavior should be considered internal or external.
>
> So I also noticed that the object types got renumbered to remove the gap
> after WIN32__GUI__DIALOG ... some code I'd borrowed had also depended on
> that, but since it was just discriminating between WINDOW & DIALOG and
> "all the rest", I could simply change the "> 10" test to "> 1", and that
> works for all versions of Win32::GUI.
>

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

Hi Laurent,

I got the compile working with the new SDK variables set up.  (Lots of 
other stuff going on, so slow progress.  Nice to have CVS set up so I 
can easily pick up and compile the latest changes now).

So my first step was to test the new GUI, with a functioning OEM script. 
  It failed.

Upon investigation, it seems that one used to be able to make a new window

   $mw = Win32::GUI::Window->new( -name => 'Main', ... );

and then add a button

   $but = $mw->AddButton( -name => 'b_nl', ..., -width => 24, ... );

And then do things like

   print "but-width: $but->{'-width'}\n";

and get back the 24.

Now this always seemed very mysterious to me, because there was no data 
member of the hash referenced by $but named '-width'.  However, when I 
had found the %TwoWayMethodMap in gui.pm which contained "-width" as one 
of the entries, I convinced myself that this "fashionable" but not 
understood technique was how the sort of print statement above could work.

Unfortunately, the above code sequence doesn't work on the latest CVS 
version.  The print statement just prints "but-width:" without the 24 :(
So we need to decide if this is something we want to have keep working, 
so that we can stay "fashionable".

Clearly, I could call Width() directly, but the borrowed code would need 
significant modification, because is uses many of the fashionable 
techniques!

The item below is clearly an internal, but I am less sure whether the 
above behavior should be considered internal or external.

So I also noticed that the object types got renumbered to remove the gap 
after WIN32__GUI__DIALOG ... some code I'd borrowed had also depended on 
that, but since it was just discriminating between WINDOW & DIALOG and 
"all the rest", I could simply change the "> 10" test to "> 1", and that 
works for all versions of Win32::GUI.


On approximately 4/12/2004 10:32 AM, came the following characters from
the keyboard of Laurent ROCHER:

> Hi,
> 
> You can add #define WINVER 0x0501 in you gui.h for this problem but you need
> to download and install last microsoft SDK for other problem.
> 
> see: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm
> 
> You need Core SDK Build environment (31 mb).
> It's a huge download.
> If you want i can make a zip with only include and lib directory (7mo).
> 
> Laurent
> 
> 
> 
> 
>>On approximately 4/8/2004 2:36 PM, came the following characters from
>>the keyboard of Laurent ROCHER:
>>
>>>New changes on CVS :
>>
>>Hi Laurent,  You've been putting some many nice new features out lately,
>>I thought I should bite the bullet, and try again to move my code to the
>>NEM.  "The bullet" seemed to need to include getting the code from CVS,
>>to get all the new goodies, and I've been wanting to get my CVS set up
>>for quite a while anyway, but just was trying not to spend that time....
>>
>>Well, Tortoise CVS didn't seem to be a big problem, it seems to have
>>done a checkout.
>>
>>But when I go to build things, then it won't compile.  So with the same
>>basic environment (compiler setup, VC++ 6.0, but different directory to
>>build in), I can compile the last release of GUI.  I don't know if I've
>>missed something in CVS setup, or missed something somewhere else, or if
>>it is code changes, but I get the following errors.  As far as I can
>>tell, the obvious things are OK:  GUI.cpp #include GUI.h, and GUI.h
>>#include winuser.h, and winuser.h is where WINDOWINFO is declared.  But,
>>the error makes it seem like it isn't declared.
>>
>>Any clues?
>>
>>cl -c    -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE
>>-DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT
>>-DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG
>>-O1    -DVERSION=\"0.0.671\"  -DXS_VERSION=\"0.0.671\"
>>"-IC:\Perl\lib\CORE"   GUI.cpp
>>GUI.cpp
>>
>>*** Using Preserved Perl context.
>>
>>GUI.xs(1886) : warning C4101: 'targ' : unreferenced local variable
>>GUI.xs(2179) : error C2065: 'WINDOWINFO' : undeclared identifier
>>GUI.xs(2179) : error C2146: syntax error : missing ';' before identifier
>>'pwi'
>>GUI.xs(2179) : error C2065: 'pwi' : undeclared identifier
>>GUI.xs(2181) : error C2228: left of '.cbSize' must have
>>class/struct/union type
>>GUI.xs(2182) : error C2065: 'GetWindowInfo' : undeclared identifier
>>GUI.xs(2184) : error C2228: left of '.rcClient' must have
>>class/struct/union type
>>GUI.xs(2184) : error C2228: left of '.left' must have class/struct/union
>>type
>>GUI.xs(2185) : error C2228: left of '.rcClient' must have
>>class/struct/union type
>>GUI.xs(2185) : error C2228: left of '.top' must have class/struct/union
> 
> type
> 
>>GUI.xs(2186) : error C2228: left of '.rcClient' must have
>>class/struct/union type
>>GUI.xs(2186) : error C2228: left of '.right' must have
>>class/struct/union type
>>GUI.xs(2187) : error C2228: left of '.rcClient' must have
>>class/struct/union type
>>GUI.xs(2187) : error C2228: left of '.bottom' must have
>>class/struct/union type
>>*** PACKAGE Win32::GUI::Menu...
>>*** PACKAGE Win32::GUI::MenuButton...
>>*** PACKAGE Win32::GUI::MenuItem...
>>NMAKE : fatal error U1077: 'cl' : return code '0x2'
>>Stop.
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&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.

[perl-win32-gui-hackers] Win32::GUI Dev PPM

[Laurent R. <ro...@cl...>]

Hi All,

I have made PPM build from Sourceforge Win32::GUI CVS Main branch.
  a.. Completely new base code.=20
  b.. Full NEM/OEM support.=20
  c.. Lot of control Win32 API method.=20
  d.. Preserved Perl context.=20
  e.. New DoModal.=20
  f.. More documentation.=20
  g.. ...=20
I build it from my local dev directory with last CVS source =
(17/04/2004).
I have made 5.6 and 5.8 PPM, and a source zip file from my dev =
directory.

See : http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/index.html

Laurent

[perl-win32-gui-hackers] New changes

[Jez W. <je...@je...>]

Hi,

I've just committed some changes:

    - DC.xs=20
        + CreateCompatibleDC method now returns a DC object
        + Added CreateCompatibleBitmap method
        + Added Line method (combination of MoveTo and LineTo)
        + Added Win32::GUI::Region object (used for clipping)
           + Added CreateRectRgn
           + Added CreateEllipticRgn
           + Added CreateRoundRectRgn
           + Added PtInRegion
           + Added RectInRegion
           + Added SetRectRgn
           + Added OffsetRgn
           + Added GetRgnBox
           + Added EqualRgn
        + Added SelectClipRgn
        + Added FillRgn
        + Added FrameRgn
        + Added InvertRgn
        + Added PaintRgn

I'll be added a few more methods in the next few days.

cheers,

jez.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

New changes on CVS :

Changelog : Add new options and documentation.
    - Button.xs : 
        + Add new style option and documentation.
    - Combobox.xs
        + Add new style option and documentation.
    - Header.xs
        + Add new style option and documentation.
    - GUI_Helper.cpp :
        + CreateObjectWithHandle : Fix memory leak 
    - GUI.pm :
        + Add documentation.
    - Label.xs :
        + Add new option.
    - Rebar.xs :
        + Add new option.
    - Trackbar.xs :
        + Add documentation.
    - Window.xs :
        + Add documentation.
 
Laurent.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi,

You can add #define WINVER 0x0501 in you gui.h for this problem but you need
to download and install last microsoft SDK for other problem.

see: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm

You need Core SDK Build environment (31 mb).
It's a huge download.
If you want i can make a zip with only include and lib directory (7mo).

Laurent



> On approximately 4/8/2004 2:36 PM, came the following characters from
> the keyboard of Laurent ROCHER:
> > New changes on CVS :
>
> Hi Laurent,  You've been putting some many nice new features out lately,
> I thought I should bite the bullet, and try again to move my code to the
> NEM.  "The bullet" seemed to need to include getting the code from CVS,
> to get all the new goodies, and I've been wanting to get my CVS set up
> for quite a while anyway, but just was trying not to spend that time....
>
> Well, Tortoise CVS didn't seem to be a big problem, it seems to have
> done a checkout.
>
> But when I go to build things, then it won't compile.  So with the same
> basic environment (compiler setup, VC++ 6.0, but different directory to
> build in), I can compile the last release of GUI.  I don't know if I've
> missed something in CVS setup, or missed something somewhere else, or if
> it is code changes, but I get the following errors.  As far as I can
> tell, the obvious things are OK:  GUI.cpp #include GUI.h, and GUI.h
> #include winuser.h, and winuser.h is where WINDOWINFO is declared.  But,
> the error makes it seem like it isn't declared.
>
> Any clues?
>
> cl -c    -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE
> -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT
> -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG
> -O1    -DVERSION=\"0.0.671\"  -DXS_VERSION=\"0.0.671\"
> "-IC:\Perl\lib\CORE"   GUI.cpp
> GUI.cpp
>
> *** Using Preserved Perl context.
>
> GUI.xs(1886) : warning C4101: 'targ' : unreferenced local variable
> GUI.xs(2179) : error C2065: 'WINDOWINFO' : undeclared identifier
> GUI.xs(2179) : error C2146: syntax error : missing ';' before identifier
> 'pwi'
> GUI.xs(2179) : error C2065: 'pwi' : undeclared identifier
> GUI.xs(2181) : error C2228: left of '.cbSize' must have
> class/struct/union type
> GUI.xs(2182) : error C2065: 'GetWindowInfo' : undeclared identifier
> GUI.xs(2184) : error C2228: left of '.rcClient' must have
> class/struct/union type
> GUI.xs(2184) : error C2228: left of '.left' must have class/struct/union
> type
> GUI.xs(2185) : error C2228: left of '.rcClient' must have
> class/struct/union type
> GUI.xs(2185) : error C2228: left of '.top' must have class/struct/union
type
> GUI.xs(2186) : error C2228: left of '.rcClient' must have
> class/struct/union type
> GUI.xs(2186) : error C2228: left of '.right' must have
> class/struct/union type
> GUI.xs(2187) : error C2228: left of '.rcClient' must have
> class/struct/union type
> GUI.xs(2187) : error C2228: left of '.bottom' must have
> class/struct/union type
> *** PACKAGE Win32::GUI::Menu...
> *** PACKAGE Win32::GUI::MenuButton...
> *** PACKAGE Win32::GUI::MenuItem...
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
>

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

On approximately 4/8/2004 2:36 PM, came the following characters from
the keyboard of Laurent ROCHER:
> New changes on CVS :

Hi Laurent,  You've been putting some many nice new features out lately, 
I thought I should bite the bullet, and try again to move my code to the 
NEM.  "The bullet" seemed to need to include getting the code from CVS, 
to get all the new goodies, and I've been wanting to get my CVS set up 
for quite a while anyway, but just was trying not to spend that time....

Well, Tortoise CVS didn't seem to be a big problem, it seems to have 
done a checkout.

But when I go to build things, then it won't compile.  So with the same 
basic environment (compiler setup, VC++ 6.0, but different directory to 
build in), I can compile the last release of GUI.  I don't know if I've 
missed something in CVS setup, or missed something somewhere else, or if 
it is code changes, but I get the following errors.  As far as I can 
tell, the obvious things are OK:  GUI.cpp #include GUI.h, and GUI.h 
#include winuser.h, and winuser.h is where WINDOWINFO is declared.  But, 
the error makes it seem like it isn't declared.

Any clues?

	cl -c    -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE 
-DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT 
-DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG 
-O1    -DVERSION=\"0.0.671\"  -DXS_VERSION=\"0.0.671\" 
"-IC:\Perl\lib\CORE"   GUI.cpp
GUI.cpp

*** Using Preserved Perl context.

GUI.xs(1886) : warning C4101: 'targ' : unreferenced local variable
GUI.xs(2179) : error C2065: 'WINDOWINFO' : undeclared identifier
GUI.xs(2179) : error C2146: syntax error : missing ';' before identifier 
'pwi'
GUI.xs(2179) : error C2065: 'pwi' : undeclared identifier
GUI.xs(2181) : error C2228: left of '.cbSize' must have 
class/struct/union type
GUI.xs(2182) : error C2065: 'GetWindowInfo' : undeclared identifier
GUI.xs(2184) : error C2228: left of '.rcClient' must have 
class/struct/union type
GUI.xs(2184) : error C2228: left of '.left' must have class/struct/union 
type
GUI.xs(2185) : error C2228: left of '.rcClient' must have 
class/struct/union type
GUI.xs(2185) : error C2228: left of '.top' must have class/struct/union type
GUI.xs(2186) : error C2228: left of '.rcClient' must have 
class/struct/union type
GUI.xs(2186) : error C2228: left of '.right' must have 
class/struct/union type
GUI.xs(2187) : error C2228: left of '.rcClient' must have 
class/struct/union type
GUI.xs(2187) : error C2228: left of '.bottom' must have 
class/struct/union type
*** PACKAGE Win32::GUI::Menu...
*** PACKAGE Win32::GUI::MenuButton...
*** PACKAGE Win32::GUI::MenuItem...
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.


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

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

New changes on CVS :

Changelog : Complet ImageList and TabStrip API.
    - Font.xs :
        + Improve parsing font options.
    - GUI.h :
        + Add new prototype.
    - GUI.pm :
        + Add method AddMasked for ImageList.
        + Add method Change for NotifyIcon.
    - ImageList.xs:
        + Add new methods and documentation.
    - StatusBar.xs:
        + Add new style option.
    - TabStrip.xs:
        + Add new methods, styles options and documentation.
    - Trackbar.xs :
        + Change styles name options.
    - Todo :
        + Complete todo
 
Laurent.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

New stuff on CVS :

Changelog : Complet Tooltip API.
    - GUI.h :
        + Add new prototype.
    - GUI_Options.cpp :
        + Add ParseTooltipOptions.
    - ToolTip.xs :
        + Complet API.

Laurent.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

I commit new thing.

Changelog : Complet API and documentation

    - Combobox.xs, DateTime.xs, GUI.pm, GUI.xs :
        + Add some documentation
    - DC.xs :
        + Add lot of new methods
    - GUI.h :
        + Add some new prototype
    - GUI_Options.cpp
        + Add new parse options function.
    - Header.xs :
        + Add new methods and styles options.
    - Label.xs :
        + Add new styles options.
    - Listbox.xs :
        + Add new styles options and documentation.
    - ListView.xs :
        + Add new methods, styles options and documentation.
    - Rebar.xs :
        + Add new methods, styles options and documentation.
    - Toolbar.xs :
        + Add new methods, styles options and documentation.
    - Trackbar.xs :
        + Add new styles options and documentation.
    - TreeView.xs :
        + Add new styles options and documentation.
    - TYPEMAP
        + Add HRGN.

Laurent.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

On approximately 3/30/2004 12:14 PM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi,
> 
> I commit new Accelerator event handling.
>     - GUI.h :
>         + Add FindChildWindowsProc prototype and search typedef struct.
>     - GUI_Events.cpp :
>         + Rewrite DoEvent_Accelerator.
>     -  GUI_Helpers.cpp :
>         + Add FindChildWindowsProc for search a child with specific name.

Sounds good.

>>>2) if accelerator define like : "Key" => "Name"
>>>  - Find a window called "Name" in current window hierarchy and
>>>call -onClick event if exist with Window Self .
>>>  - Call Window -onClick event if exist with Self + Name (-acc is
> 
> availlable
> 
>>>only for Window and Dialog so Click event isn't use for specific stuff).
>>
>>Yes, -accel is only available for those two, but I could imagine other
>>uses for Click event on the "white space" of a parent window.  So that
>>is why I suggested making a new "Accel" event, so one could specify
>>-onAccel => sub {...}
> 
> 
> Actually, i keep Click because :
>     - I win an NEM event flag ;o)
>     - For Click event on the "white space", it's not standard window event.
>       And, i think it's more application implementation to use KeyDown event
> and check white space.
>     - We can reuse Click event for menu (like Jez suggest) (so accelerator
> and menu call same method).
>         When your menu is "text" => "name" like in OEM.
>         We can call Window -click event if we can't found a OEM event
> handler.
> 
> But of course it's easy to change.

OK, I'm no expert in what is standard window event, so that sounds 
reasonable, given the availability of KeyDown on window.

So is it implemented that menus without -onClick events will call Window 
-onClick?  If not, this isn't a very good reason, and I'm not fond of 
the idea, but I can see it would be slightly handy.

So it occurred to me this morning that if we are going this route, that 
Buttons without -onClick should also fall into the Window -onClick.

I'm not fond of the idea because the Window -onClick, winds up having to 
handle lots of events, so has to include a "dispatcher" or "switch 
statement" to do so... and inside GUI, if -onClick is specified for all 
the individual events, the dispatching can be done in C code instead of 
Perl code, which should be faster.

I can see the "convenience" of writing one humongous function to handle 
all of Accelerators, Menus, and Buttons, with the same code regardless 
of which way an operation is invoked... but it suffers in performance, 
and I am somewhat negative about encouraging that.

Specifying   -onClick => sub { ... }  allows the dispatch to happen in 
C, and if the ... is simply { & my_sprongle_handler() }  that is fine to 
handle either the sprongle button, the accelerator key for sprongle, or 
the Tools / Sprongle  menu entry.  So you have 3 dinky wrapper 
functions... or you could specify  -onClick => \& my_sprongle_handler 
if there is no need to distinguish between which way the handler was 
invoked.

But I can't complain too much, because both technique will be available 
for use.

>>>  - Check for OEM Name_Click and call it if exist.
>>
>>This last would only be done for OEM mode, and BOTH mode, I presume.
> 
> 
> Actually, i call it, only if haven't find a named child window or named
> child window is OEM/BOTH.
> I can call Unknow_Click method like in OEM (for compatibility).

Ah.  OK.

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

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi,

I commit new Accelerator event handling.
    - GUI.h :
        + Add FindChildWindowsProc prototype and search typedef struct.
    - GUI_Events.cpp :
        + Rewrite DoEvent_Accelerator.
    -  GUI_Helpers.cpp :
        + Add FindChildWindowsProc for search a child with specific name.

> >
> > 1) if accelerator define like  : "key" => sub { } or "key" => \&mysub
> >   - Call this function with Window Self + accelerator name.
>
> This one will clearly wind up being the fastest to locate and invoke,
> under NEM.

Yes, it's faster way.

> > 2) if accelerator define like : "Key" => "Name"
> >   - Find a window called "Name" in current window hierarchy and
> > call -onClick event if exist with Window Self .
> >   - Call Window -onClick event if exist with Self + Name (-acc is
availlable
> > only for Window and Dialog so Click event isn't use for specific stuff).
>
> Yes, -accel is only available for those two, but I could imagine other
> uses for Click event on the "white space" of a parent window.  So that
> is why I suggested making a new "Accel" event, so one could specify
> -onAccel => sub {...}

Actually, i keep Click because :
    - I win an NEM event flag ;o)
    - For Click event on the "white space", it's not standard window event.
      And, i think it's more application implementation to use KeyDown event
and check white space.
    - We can reuse Click event for menu (like Jez suggest) (so accelerator
and menu call same method).
        When your menu is "text" => "name" like in OEM.
        We can call Window -click event if we can't found a OEM event
handler.

But of course it's easy to change.

> >   - Check for OEM Name_Click and call it if exist.
>
> This last would only be done for OEM mode, and BOTH mode, I presume.

Actually, i call it, only if haven't find a named child window or named
child window is OEM/BOTH.
I can call Unknow_Click method like in OEM (for compatibility).

Laurent

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

I add some add-on to DoModal method.
    - Prevent re-call DoModal on same dialog.
    - Add a parameter flag for disable all top window (By default only
parent/active window is disable).
And fix a problem with MinGW.

Changelog :
    - GUI.h :
        + Add Animate_OpenEx macro for MinGW
        + Add a IS_MODAL dwPlStyle flag.
        + Add EnableWindowsProc callback.
    - GUI.xs :
        + DoModal() :
            - Return false if function already in DoModal.
            - Add a boolean parameter for disable all Top Window and not
only parent/caller.
    - GUI_Helpers.cpp :
        + Add EnableWindowsProc : Activate or Deactivate current thread top
window.
    - GUI.pm :
        + Remove Win32::GUI::Window::DESTROY because unnecessary and conflic
with Win32::GUI::WindowProps.

Laurent.

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

On approximately 3/29/2004 12:39 PM, came the following characters from
the keyboard of Laurent ROCHER:

> Hi all,
> 
> If i resume, Accelerator event implement could be :
> 
> 1) if accelerator define like  : "key" => sub { } or "key" => \&mysub
>   - Call this function with Window Self + accelerator name.

This one will clearly wind up being the fastest to locate and invoke, 
under NEM.

> 2) if accelerator define like : "Key" => "Name"
>   - Find a window called "Name" in current window hierarchy and
> call -onClick event if exist with Window Self .
>   - Call Window -onClick event if exist with Self + Name (-acc is availlable
> only for Window and Dialog so Click event isn't use for specific stuff).

Yes, -accel is only available for those two, but I could imagine other 
uses for Click event on the "white space" of a parent window.  So that 
is why I suggested making a new "Accel" event, so one could specify 
-onAccel => sub {...}

>   - Check for OEM Name_Click and call it if exist.

This last would only be done for OEM mode, and BOTH mode, I presume.

> Of course we stop after first event call.
> 
> I think it's not too much difficult to do ;o)

More power to you!

> Laurent.
> 
> 
>>Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.
>>Hi Laurent,
>>
>>I'm excited about all the enhancements you are making to Win32::GUI
>>these days, can hardly wait to try them out!
> 
> 
> 
> 

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

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Laurent R. <ro...@cl...>]

Hi all,

If i resume, Accelerator event implement could be :

1) if accelerator define like  : "key" => sub { } or "key" => \&mysub
  - Call this function with Window Self + accelerator name.

2) if accelerator define like : "Key" => "Name"
  - Find a window called "Name" in current window hierarchy and
call -onClick event if exist with Window Self .
  - Call Window -onClick event if exist with Self + Name (-acc is availlable
only for Window and Dialog so Click event isn't use for specific stuff).
  - Check for OEM Name_Click and call it if exist.

Of course we stop after first event call.

I think it's not too much difficult to do ;o)

Laurent.

> Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.
> Hi Laurent,
>
> I'm excited about all the enhancements you are making to Win32::GUI
> these days, can hardly wait to try them out!

Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.

[Glenn L. <pe...@ne...>]

The approach is workable, but it

1) isn't as easily portable from OEM accelerators, which I think is 
useful to preserve.

2) a single handler is forced to "couple" the code for widely disparate 
events, which isn't always the easiest to maintain... and you often wind 
up with a haandler that has an extra switch statement in it to further 
dispatch the event.  The OEM accelerator model caused the dispatch of 
the exact, already defined widget_Click event, allowing accelerators to 
be handled without writing any additional code, which is a great 
timesaver for adding many simple accelerators in many applications, 
which I think should be preserved.

3) As I outlined in my previous message, some extensions could be made 
to accelerators.  If all accelerator keys are mapped to names that do 
not have widgets, then you do wind up with the option of handling all 
accelerators in a single handler, if that method appeals to you and/or 
is an appropriate technique for particular applications.


Regarding handling menus via a single handler.  I have the same concerns 
  that for many applications that adds an extra switch statement, and 
couples disparate lines of code.  And the implementation in Windows and 
Win32::GUI for menus and accelerators is quite different, although that 
alone shouldn't stop us from giving a unified interface if it makes 
sense, isn't too hard, and is seen as desirable for some applications.

So what is the essence of a menu?  And how are they different from 
accelerators?

An accelerator is:

  "key" => "name"  (or possibly, by enhancement, "key" => sub {...} )

A menu is

  "text" => "name"  # OEM
  "text" => { -name => "name, -onClick => sub {...}, }  # NEM

The "text" part can also have flags which encode a level of hierarchy, 
and some geometry (separators and columnization at least) specifications.

For OEM, we have the _Click event available, and if the name_Click 
function exists it is called when the menu item is selected.  So indeed, 
the action part of the activity is very similar to accelerators, but 
under the covers, there is a collection of Windows data structures 
created, that are not created for accelarators... but this is mostly for 
the user interface differences between menus and accelerators.

For NEM, while it isn't presently implemented, one could envision that 
other events could be defined for menu items.... at least a RightClick 
event could be envisioned, possibly also GotFocus/LostFocus, DblClick, 
DblRightClick, maybe others).  If this sort of extension would be made, 
which I think would be useful (note that Windows differentiates clicking 
and right clicking on Start menu items, among other things), then the 
vision of accelerators and menus as being fairly similar starts to break 
down.... there is no possibility of RightClick-ing an accelerator :) 
And there could be a richer event model for menus than a simple, single, 
Click event.  And I would doubt that handling a richer event model for 
menus would appropriately be done by a single handler in most applications.


On approximately 3/29/2004 2:30 AM, came the following characters from
the keyboard of Jez White:

> My 2 cents worth. I *really* like this approach. The idea of one handler is
> much cleaner and simpler, especially when you have many items in the table.
> Going one step further I'd like to see the same kind of approach taken for
> menus!
> 
> cheers,
> 
> jez.
> 
> ----- Original Message ----- 
> From: "Laurent ROCHER" <ro...@cl...>
> To: "Win32 GUI Hackers" <per...@li...>
> Sent: Sunday, March 28, 2004 8:56 PM
> Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.
> 
> 
> 
>>Hi,
>>
>>Some small bug fix :
>>    - UpDown :
>>        + Fix Scroll event.
>>    - GUI_Events.cpp :
>>        + In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after
>>event call.
>>
>>I looking for NEM support for accelerator and i don't know if my current
>>implementation was good.
>>If you look in sample below, you see it's always call -onClick window
> 
> event
> 
>>with accelerator name but not call button click event like in OEM.
>>For NEM support it's probably nicer to call Button click method like OEM
> 
> do.
> 
>>What do you think ?
>>
>>Laurent.
>>
>>use Win32::GUI;
>>
>>my $acc = new Win32::GUI::AcceleratorTable(
>> "A" => "Window",
>> "B" => "Button",
>>);
>>
>>$W = new Win32::GUI::Window(
>>    -name   => "Window",
>>    -title  => "test",
>>    -pos    => [100, 100],
>>    -size   => [280, 280],
>>    -accel  => $acc,
>>    # NEM call comment for OEM.
>>    -onClick => sub { my ($self, $name) = @_; print "Window OnClick :
>>$name\n"; },
>>);
>>
>>$W->AddButton(
>>    -name    => "Button",
>>    -pos     => [5,  5],
>>    -size    => [100, 100],
>>    -text    => "Just button",
>>);
>>
>>$W->Show;
>>Win32::GUI::Dialog();
>>
>># OEM call
>>sub Window_Click {
>>  print "Window_Click\n";
>>}
>>
>>sub Button_Click {
>>  print "Button_Click\n";
>>}
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>Perl-Win32-GUI-Hackers mailing list
>>Per...@li...
>>https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&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.