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

Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes

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

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.

Re: [perl-win32-gui-hackers] Rebar.xs - Some Changes

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

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.

[perl-win32-gui-hackers] MetaFile related stuff

[Steve P. <st...@ba...>]

Hi,

During the heavy documentation update (nearly every method in GUI.xs has now
been documented) I noticed some confusing things regarding these:
Win32::GUI::CloseEnhMetaFile(HANDLE)
Win32::GUI::CreateEnhMetaFile(FILENAME, [DESCRIPTION])
Win32::GUI::DeleteEnhMetaFile(HANDLE)
Win32::GUI::PlayEnhMetaFile(FILENAME)
Win32::GUI::PlayWinMetaFile(FILENAME)

Now, CreateEnhMetaFile creates a DC for an Enhanced Meta File and returns a
*handle* to it. While I've secretly extended "new Win32::GUI::DC(...)" to
accept a numeric DC handle as well as a device string or window, I think
that returning a handle rather than a DC object from CreateEnhMetaFile is
counter-intuitive.

With my mod to the Win32::GUI::DC constructor, it is possible to do:

$metadc = new Win32::GUI::DC(CreateEnhMetaFile("hello.emf","test 123"));
$metadc->FillRect(0,0,100,100);
Win32::GUI::CloseEnhMetaFile($metadc);

I think this is still pretty damn nasty, and it would be nice to be able to
do:

$metadc = Win32::GUI::CreateEnhMetaFile("hello.emf","test 123");
$metadc->FillRect(0,0,100,100);
$metadc->CloseEnhMetaFile;

Basically, from a documentation point of view, I don't want to have to tell
the reader "Ok, this function returns a handle to a DC, which is not the
same as a DC object, so when dealing with the handle to the DC you must use
all DC functions in class form like
Win32::GUI::DC::FillRect($handle,$left,$top,$right,$bottom)" because that's
REALLY confusing and makes no sense.

Do you think it's safe to mod CreateEnhMetaFile so it returns a blessed DC
object instead of just a handle? Will this break anything? Opinions
please...

Steve

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

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

Hi All,

I have made PPM build from Sourceforge Win32::GUI CVS.

I build it from my local dev directory with last CVS source =
(18/01/2004).

I have made 5.6 and 5.8 PPM (don't build for 5.005), 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] Re: [perl-win32-gui-users] Yet Another CVS Commit...

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

Quick question.

If I wanted to use a scroll bar for part of the window - say, within a
tabstrip, would the approach be to create another window and apply the
scroll bar to that?

Cheers,

jez.
----- Original Message ----- 
From: "Steve Pick" <st...@ba...>
To: "Win32 GUI Users" <per...@li...>; "Win32
GUI Hackers" <per...@li...>
Sent: Thursday, January 15, 2004 11:53 PM
Subject: [perl-win32-gui-users] Yet Another CVS Commit...


> Hello, me again...
>
> Since some people mentioned window scrollbars in the list a while back, I
> decided to implement some functions to make them actually work.
>
> I've also added the relevant constants for scrollbars and statusbars,
fixed
> the bug with $window->Result(x) (thanks to Glenn Linderman), and applied
> Laurent Rocher's tweaks for the Status Bar code.
>
> New functions. Use these in the form:
>
> $window->foo(bar, baz);
>
>
###########################################################################
>  # (@)METHOD:ScrollPos(scrollbar,[pos])
>  # Sets / Gets position of a window scrollbar (if enabled). scrollbar
>  # argument should be set as follows:
>  # 0 - Horizontal scrollbar
>  # 1 - Vertical scrollbar
>  #
>  # Returns the scrollbar position or undef on failure.
>
>
###########################################################################
>  # (@)METHOD:ScrollPage(scrollbar,[pagesize])
>  # Sets / Gets page size of a window scrollbar (if enabled). scrollbar
>  # argument should be set as follows:
>  # 0 - Horizontal scrollbar
>  # 1 - Vertical scrollbar
>  #
>  # Returns the scrollbar page size or undef on failure.
>
>
###########################################################################
>  # (@)METHOD:ScrollRange(scrollbar,[min, max])
>  # Sets / Gets range for a window scrollbar (if enabled). scrollbar
>  # argument should be set as follows:
>  # 0 - Horizontal scrollbar
>  # 1 - Vertical scrollbar
>  #
>  # Returns the scrollbar range as an array, or undef on failure.
>
>
###########################################################################
>  # (@)METHOD:Scroll(scrollbar,operation,position)
>  # Handles scrollbar scrolling if you don't want to do it yourself. This
is
>  # most useful in the Scroll event handler for a window or dialog box.
>  #
>  # scrollbar can be:
>  # 0 - Horizontal scrollbar
>  # 1 - Vertical scrollbar
>  #
>  # type is an identifier for the operation being performed on the
scrollbar,
>  # this can be:
>  # SB_LINEUP, SB_LINELEFT, SB_LINEDOWN, SB_LINERIGHT, SB_PAGEUP
>  # SB_PAGELEFT, SB_PAGEDOWN, SB_PAGERIGHT, SB_THUMBPOSITION,
>  # SB_THUMBTRACK, SB_TOP, SB_LEFT, SB_BOTTOM, SB_RIGHT, or SB_ENDSCROLL
>  #
>  # Returns the position of the scrollbar or undef on failure.
>  #
>
> New events for WINDOW/DIALOGBOX:
> /*
> * (@)EVENT:Scroll(SCROLLBAR, OPERATION, POSITION)
> * Sent when one of the window scrollbars is moved. SCROLLBAR identifies
> * which bar was moved, 0 for horizontal and 1 for vertical.
> *
> * OPERATION can be compared against one of the following constants:
> * SB_LINEUP, SB_LINELEFT, SB_LINEDOWN, SB_LINERIGHT, SB_PAGEUP
> * SB_PAGELEFT, SB_PAGEDOWN, SB_PAGERIGHT, SB_THUMBPOSITION,
> * SB_THUMBTRACK, SB_TOP, SB_LEFT, SB_BOTTOM, SB_RIGHT, SB_ENDSCROLL
> *
> * NEM equivalent: onScroll
> * Related messages: WM_HSCROLL, WM_VSCROLL
> */
>
> Example code:
>
> use Win32::GUI;
> my $win = new Win32::GUI::Window (
>  -name => "MainWin",
>  -left => 0,
>  -top => 100,
>  -width => 500,
>  -height => 300,
>  -sizable => 1,
>  -text => "Scrollbar Test",
>  -noflicker => 0,
>  -hscroll => 1,
>  -onScroll => \&scrolled
> );
>
> $win->ScrollRange(0,0,100));
> $win->ScrollPage(0,10);
> $win->ScrollPos(0,50);
>
> $win->Show;
> Win32::GUI::Dialog;
>
> sub scrolled {
>  my($object,$bar,$operation,$pos) = @_;
>  $object->Scroll($bar,$operation,$pos);
> # You could also do something like this if you want more control:
> #    if($operation == SB_LINEUP) {
> #        $object->ScrollPos($bar,$object->ScrollPos($bar) - 1);
> #    }
> #    elsif($operation == SB_PAGEUP) {
> #        $object->ScrollPos($bar,$object->ScrollPos($bar) -
> $object->ScrollPage($bar));
> #    }
> #    elsif($operation == SB_THUMBTRACK) {
> #        print "Tracking ".($bar == 0 ? "horizontal" : "vertical")."
> scrollbar thumb position: ".$pos."\n";
> #    }
> #    .... and so on.
> }
>
> Steve.
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users

[perl-win32-gui-hackers] Yet Another CVS Commit...

[Steve P. <st...@ba...>]

Hello, me again...

Since some people mentioned window scrollbars in the list a while back, I
decided to implement some functions to make them actually work.

I've also added the relevant constants for scrollbars and statusbars, fixed
the bug with $window->Result(x) (thanks to Glenn Linderman), and applied
Laurent Rocher's tweaks for the Status Bar code.

New functions. Use these in the form:

$window->foo(bar, baz);

 ###########################################################################
 # (@)METHOD:ScrollPos(scrollbar,[pos])
 # Sets / Gets position of a window scrollbar (if enabled). scrollbar
 # argument should be set as follows:
 # 0 - Horizontal scrollbar
 # 1 - Vertical scrollbar
 #
 # Returns the scrollbar position or undef on failure.

 ###########################################################################
 # (@)METHOD:ScrollPage(scrollbar,[pagesize])
 # Sets / Gets page size of a window scrollbar (if enabled). scrollbar
 # argument should be set as follows:
 # 0 - Horizontal scrollbar
 # 1 - Vertical scrollbar
 #
 # Returns the scrollbar page size or undef on failure.

 ###########################################################################
 # (@)METHOD:ScrollRange(scrollbar,[min, max])
 # Sets / Gets range for a window scrollbar (if enabled). scrollbar
 # argument should be set as follows:
 # 0 - Horizontal scrollbar
 # 1 - Vertical scrollbar
 #
 # Returns the scrollbar range as an array, or undef on failure.

 ###########################################################################
 # (@)METHOD:Scroll(scrollbar,operation,position)
 # Handles scrollbar scrolling if you don't want to do it yourself. This is
 # most useful in the Scroll event handler for a window or dialog box.
 #
 # scrollbar can be:
 # 0 - Horizontal scrollbar
 # 1 - Vertical scrollbar
 #
 # type is an identifier for the operation being performed on the scrollbar,
 # this can be:
 # SB_LINEUP, SB_LINELEFT, SB_LINEDOWN, SB_LINERIGHT, SB_PAGEUP
 # SB_PAGELEFT, SB_PAGEDOWN, SB_PAGERIGHT, SB_THUMBPOSITION,
 # SB_THUMBTRACK, SB_TOP, SB_LEFT, SB_BOTTOM, SB_RIGHT, or SB_ENDSCROLL
 #
 # Returns the position of the scrollbar or undef on failure.
 #

New events for WINDOW/DIALOGBOX:
/*
* (@)EVENT:Scroll(SCROLLBAR, OPERATION, POSITION)
* Sent when one of the window scrollbars is moved. SCROLLBAR identifies
* which bar was moved, 0 for horizontal and 1 for vertical.
*
* OPERATION can be compared against one of the following constants:
* SB_LINEUP, SB_LINELEFT, SB_LINEDOWN, SB_LINERIGHT, SB_PAGEUP
* SB_PAGELEFT, SB_PAGEDOWN, SB_PAGERIGHT, SB_THUMBPOSITION,
* SB_THUMBTRACK, SB_TOP, SB_LEFT, SB_BOTTOM, SB_RIGHT, SB_ENDSCROLL
*
* NEM equivalent: onScroll
* Related messages: WM_HSCROLL, WM_VSCROLL
*/

Example code:

use Win32::GUI;
my $win = new Win32::GUI::Window (
 -name => "MainWin",
 -left => 0,
 -top => 100,
 -width => 500,
 -height => 300,
 -sizable => 1,
 -text => "Scrollbar Test",
 -noflicker => 0,
 -hscroll => 1,
 -onScroll => \&scrolled
);

$win->ScrollRange(0,0,100));
$win->ScrollPage(0,10);
$win->ScrollPos(0,50);

$win->Show;
Win32::GUI::Dialog;

sub scrolled {
 my($object,$bar,$operation,$pos) = @_;
 $object->Scroll($bar,$operation,$pos);
# You could also do something like this if you want more control:
#    if($operation == SB_LINEUP) {
#        $object->ScrollPos($bar,$object->ScrollPos($bar) - 1);
#    }
#    elsif($operation == SB_PAGEUP) {
#        $object->ScrollPos($bar,$object->ScrollPos($bar) -
$object->ScrollPage($bar));
#    }
#    elsif($operation == SB_THUMBTRACK) {
#        print "Tracking ".($bar == 0 ? "horizontal" : "vertical")."
scrollbar thumb position: ".$pos."\n";
#    }
#    .... and so on.
}

Steve.

Re: [perl-win32-gui-hackers] Menu enhancement patch for gui_options

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

With no reply, I got to wondering what had happened, and I couldn't find 
that I had actually sent the message for sure, so thought I'd resend it, 
rather than start asking if something went wrong!  Thanks for applying it.

Hopefully I'll get CVS going in the next couple months, so I can do this 
sort of thing myself.

On approximately 1/14/2004 10:56 AM, came the following characters from
the keyboard of Laurent ROCHER:
> Oups.
> 
> I don't know what i have do, but i have already commit it on CVS last time.
> But, i forgot to add a line in CHANGELOG and reply to your mail :-0
> 
> Sorry,
>    Laurent.
> 
> 
> 
>>Hi Laurent, and others,
>>
>>Here is a patch to enhance menus, by exposing more Windows options to
> 
> Perl.
> 
> 
> 

-- 
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] CVS: New statusbar methods added

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

Hi,

I just tried to build from the CVS - but the latest changes I can see (both
from the web and my CVS client) is six days ago.

according to the docs:

"Issues formerly encountered due to the SourceForge.net CVS infrastructure
have now been resolved. Pserver connections are no longer globally capped.
Data is currently synchronized between the developer CVS servers (SSH) and
the anonymous CVS servers (pserver) every 5 hours. There may be a delay of
up to five hours between the time a developer commits a file and when it
becomes available via pserver."

Which, means I might not see the change Steve just made - but surly I should
see the change he made yesterday?

jez.

----- Original Message ----- 
From: "Steve Pick" <st...@ba...>
To: "Win32 GUI Users" <per...@li...>; "Win32
GUI Hackers" <per...@li...>
Sent: Wednesday, January 14, 2004 7:12 PM
Subject: [perl-win32-gui-hackers] CVS: New statusbar methods added


> Hi,
>
> You'll all be pleased to know that I've enhanced the StatusBar object
> greatly. Here's the documentation for all the new methods for your status
> bars:
>
> Parts([x1, x2, x3...])
>     # Divides the statusbar into sections. The list of co-ordinates define
> the
>     # right-hand edge of each part.
>     #
>     # This method will return a list of co-ordinates for the current
parts.
>     # A value of -1 in the final co-ordinate means the last part will
>     # expand rightwards to fill the statusbar.
>
> Simple([simplemode])
>     # If simplemode is not 0, turns simple mode on. Otherwise, turns
simple
>     # mode off. Simple mode means the statusbar just shows text, with only
> one
>     # partition.
>     #
>     # Returns the status of simple mode (0 = off, non-zero = on)
>
> PartText(part,[string,[flags]])
>     # Sets or gets the text in a particular part of the status bar.
>     #
>     # Flags are as follows:
>     # 0
>     #        The text is drawn with a border to appear lower than the
plane
> of
>     #        the window.
>     #
>     #   SBT_NOBORDERS = 256
>     #        The text is drawn without borders.
>     #
>     #   SBT_POPOUT = 512
>     #        The text is drawn with a border to appear higher than the
plane
> of
>     #        the window.
>     #
>     #   SBT_RTLREADING = 1024
>     #        The text will be displayed in the opposite direction to the
> text
>     #        in the parent window.
>     #
>     #   SBT_OWNERDRAW = 4096
>     #        The text is drawn by the parent window.
>     #
>     # When called with no string or flags, in scalar context the method
will
>     # return the text string in the specified part of the status bar. In
> array
>     # context, the method will return the text string and the style flags
of
>     # the text in the specified part.
>     #
>
> Tip(part,string)
>     # Sets the tooltip text for a particular part of the status bar.
>     #
>     # From SDK documentation:
>     # This ToolTip text is displayed in two situations:
>     # When the corresponding pane in the status bar contains only an icon.
>     # When the corresponding pane in the status bar contains text that is
>     # truncated due to the size of the pane.
>
> Icon(part,icon)
>     # Sets or unsets the icon for a particular part of the status bar. If
> icon
>     # is set to 0 or less, the icon for the specified part of the status
bar
> is
>     # removed. icon should be a Win32::GUI::Icon object.
>     #
>
> GetRect(part)
>     # Gets the bounding rectangle for the given part of the status bar.
> Returns
>     # left, top, right, bottom co-ordinates, or undef on failure. This is
> useful
>     # for drawing in the status bar.
>     #
>
> SetMinHeight(height)
>     # Sets the minimum height of a status window's drawing area, and
redraws
>     # the status bar.
>     #
>     # The minimum height produced will be: height + (2 * vertical border
> width)
>     #
>
> GetBorders()
>     # Gets the border values for the status bar. Returns an array
containing
>     # width of the horizontal border, width of the vertical border, and
the
>     # width of the border between parts.
>     #
>
> SetBkColor([color])
>     # Sets the background color of the status bar. If no color is given,
>     # it sets the background color to the default background color.
>     #
>
> Any questions, let me know. Suggestions and bugs to sourceforge tracker.
> Thank you.
>
> Steve
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers

[perl-win32-gui-hackers] CVS: New statusbar methods added

[Steve P. <st...@ba...>]

Hi,

You'll all be pleased to know that I've enhanced the StatusBar object
greatly. Here's the documentation for all the new methods for your status
bars:

Parts([x1, x2, x3...])
    # Divides the statusbar into sections. The list of co-ordinates define
the
    # right-hand edge of each part.
    #
    # This method will return a list of co-ordinates for the current parts.
    # A value of -1 in the final co-ordinate means the last part will
    # expand rightwards to fill the statusbar.

Simple([simplemode])
    # If simplemode is not 0, turns simple mode on. Otherwise, turns simple
    # mode off. Simple mode means the statusbar just shows text, with only
one
    # partition.
    #
    # Returns the status of simple mode (0 = off, non-zero = on)

PartText(part,[string,[flags]])
    # Sets or gets the text in a particular part of the status bar.
    #
    # Flags are as follows:
    # 0
    #        The text is drawn with a border to appear lower than the plane
of
    #        the window.
    #
    #   SBT_NOBORDERS = 256
    #        The text is drawn without borders.
    #
    #   SBT_POPOUT = 512
    #        The text is drawn with a border to appear higher than the plane
of
    #        the window.
    #
    #   SBT_RTLREADING = 1024
    #        The text will be displayed in the opposite direction to the
text
    #        in the parent window.
    #
    #   SBT_OWNERDRAW = 4096
    #        The text is drawn by the parent window.
    #
    # When called with no string or flags, in scalar context the method will
    # return the text string in the specified part of the status bar. In
array
    # context, the method will return the text string and the style flags of
    # the text in the specified part.
    #

Tip(part,string)
    # Sets the tooltip text for a particular part of the status bar.
    #
    # From SDK documentation:
    # This ToolTip text is displayed in two situations:
    # When the corresponding pane in the status bar contains only an icon.
    # When the corresponding pane in the status bar contains text that is
    # truncated due to the size of the pane.

Icon(part,icon)
    # Sets or unsets the icon for a particular part of the status bar. If
icon
    # is set to 0 or less, the icon for the specified part of the status bar
is
    # removed. icon should be a Win32::GUI::Icon object.
    #

GetRect(part)
    # Gets the bounding rectangle for the given part of the status bar.
Returns
    # left, top, right, bottom co-ordinates, or undef on failure. This is
useful
    # for drawing in the status bar.
    #

SetMinHeight(height)
    # Sets the minimum height of a status window's drawing area, and redraws
    # the status bar.
    #
    # The minimum height produced will be: height + (2 * vertical border
width)
    #

GetBorders()
    # Gets the border values for the status bar. Returns an array containing
    # width of the horizontal border, width of the vertical border, and the
    # width of the border between parts.
    #

SetBkColor([color])
    # Sets the background color of the status bar. If no color is given,
    # it sets the background color to the default background color.
    #

Any questions, let me know. Suggestions and bugs to sourceforge tracker.
Thank you.

Steve

Re: [perl-win32-gui-hackers] Menu enhancement patch for gui_options

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

Oups.

I don't know what i have do, but i have already commit it on CVS last time.
But, i forgot to add a line in CHANGELOG and reply to your mail :-0

Sorry,
   Laurent.


> Hi Laurent, and others,
>
> Here is a patch to enhance menus, by exposing more Windows options to
Perl.

[perl-win32-gui-hackers] Menu enhancement patch for gui_options

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

Hi Laurent, and others,

Here is a patch to enhance menus, by exposing more Windows options to Perl.

The new code is in the first part of the patch, I think you have already
applied the second part of the patch.

After the patch I give a usage sample.


diff -c D:\Win32-GUI-rel-0.0.665\gui_options.cpp gui_options.cpp
*** D:\Win32-GUI-rel-0.0.665\gui_options.cpp	Wed Feb 27 03:09:22 2002
--- gui_options.cpp	Sat Jan  3 20:55:41 2004
***************
*** 896,901 ****
--- 896,913 ----
                   SwitchBit(mii->fMask, MIIM_TYPE, 1);
                   next_i = i + 1;
                   SwitchBit(mii->fType, MFT_SEPARATOR, SvIV(ST(next_i)));
+             } else if(strcmp(option, "-menubarbreak") == 0) {
+                 SwitchBit(mii->fMask, MIIM_TYPE, 1);
+                 next_i = i + 1;
+                 SwitchBit(mii->fType, MFT_MENUBARBREAK, SvIV(ST(next_i)));
+             } else if(strcmp(option, "-menubreak") == 0) {
+                 SwitchBit(mii->fMask, MIIM_TYPE, 1);
+                 next_i = i + 1;
+                 SwitchBit(mii->fType, MFT_MENUBREAK, SvIV(ST(next_i)));
+             } else if(strcmp(option, "-radiocheck") == 0) {
+                 SwitchBit(mii->fMask, MIIM_TYPE, 1);
+                 next_i = i + 1;
+                 SwitchBit(mii->fType, MFT_RADIOCHECK, SvIV(ST(next_i)));
               } else if(strcmp(option, "-default") == 0) {
                   SwitchBit(mii->fMask, MIIM_STATE, 1);
                   next_i = i + 1;
***************
*** 907,913 ****
               } else if(strcmp(option, "-enabled") == 0) {
                   SwitchBit(mii->fMask, MIIM_STATE, 1);
                   next_i = i + 1;
!                 SwitchBit(mii->fState, MFS_ENABLED, SvIV(ST(next_i)));
               } else if(strcmp(option, "-name") == 0) {
                   next_i = i + 1;
   #ifdef PERLWIN32GUI_STRONGDEBUG
--- 919,925 ----
               } else if(strcmp(option, "-enabled") == 0) {
                   SwitchBit(mii->fMask, MIIM_STATE, 1);
                   next_i = i + 1;
!                 SwitchBit(mii->fState, MFS_DISABLED, ! SvIV(ST(next_i)));
               } else if(strcmp(option, "-name") == 0) {
                   next_i = i + 1;
   #ifdef PERLWIN32GUI_STRONGDEBUG
=====================================================================

$m_config = new Win32::GUI::Menu (
   'Config' => 'sConfig',
   ">&newest" => 'sNewest',
   ">&this year" => 'sThisYear',
   ">&last year" => 'sLastYear',
   ">&prior year" => 'sPriorYear',
   ">&all years" => 'sAllYear',
   ">&open file" => 'sFile',
   ">&show debug window" => 'sShowDos',
   ">&reset data directory" => 'sGetDataDir',
   );
if ( ! $m_config )
{ & mydie ( $msgpfx . "m_config creation error: $^E\n" );
}

$m_config->{'sFile'}->Change( -menubarbreak => 1 );

This causes the last three entries to be displayed in a separate menu
column, with a vertical separator bar.

I suppose one could instead parse special characters after the > in the
menu entry, and set these automatically, but it would risk backwards
compatibility with user's existing menu entry texts.

-- 
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] CVS commit

[Steve P. <st...@ba...>]

Hi,

In this update:

 - GUI.xs : Made ProgressBar aware of -foreground and -background colour
settings

Example:

my $progressbar = new Win32::GUI::ProgressBar($mainwindow,
    -name => "PB1",
    -left => 0,
    -top => 0,
    -width => 100,
    -height => 20,
    -foreground => [255,0,0], # Red. Can also use a color object as normal
    -background => [0,0,0], # Black.
);

$progressbar->Change(-foreground => [80,80,80]); # Change bar colour to
grey.
$progressbar->Change(-background => [0,80,80]); # Change background colour
to slate.

 - GUI.xs : Added Result(handle, code) call for explicitly setting the
returned LRESULT from a handler. (normally the value returned from Perl
handlers was not returned from their calling wndproc, this allows you to
specify a result that will be returned.)

Example:

my notifyhandler {
    my $object = shift;
    $object->Result(20);    # set the value we should return to Windows to
be 20.
    return 0;
}

See the API documentation on msdn.microsoft.com for valid values to return
on particular messages. This feature is most useful for responding to the
various WM_NOTIFY and WM_COMMAND messages.

 - GUI_MessageLoops.cpp : If CommonMsgLoop must be called then it is called
before any Hook handlers are called.

You will probably not notice a difference with this change. Basically it
means that any events that were previously processed AFTER the hooks were
called are now done BEFORE the hooks are called. The most significant
advantage of this is that you can now hook WM_PAINT and do all your
client-area drawing there (previously, any drawing you did was erased
immediately).

Any problems, mail the list. Any suggestions, bug reports or feature
requests, please use:
http://sourceforge.net/tracker/?group_id=16572

Thank you and good night :)

Steve

[perl-win32-gui-hackers] Some modifications to GUI_MessageLoops.cpp

[Stephen P. <Ste...@uc...>]

Hi all,

Glenn Munroe pointed out that when you return a value from a handler it =
is discarded by Win32::GUI. Some notify messages and other messages =
benefit from the ability to return a specific result from the wndproc. =
I've implemented this as follows: In your handler, if you want to =
explicitly set the return value, you must call $win->Result(xxx) where =
xxx is whatever result you wish to return. Of course this can also be =
called as Win32::GUI::Result($handle, xxx). I chose not to simply take =
the return value of the handler function because i feared that that =
would break almost every Win32::GUI application out there (a lot of =
people don't bother with returns at the end of their subroutines).

Example:

return the value 20 from a button click:

my $button =3D new Win32::GUI::Button($window,
	-text =3D> "Hello, world!",
	-name =3D> "Button1",
	-onClick =3D> \&buttonclicked
);

sub buttonclicked {
	my $button =3D shift;
	print "Button was clicked, returning 20\n";
	$button->Result(20);	# gets sent to windows API.
	return 0;			# flag for Win32::GUI (as normal).
}

This should work with all event models (with any luck), and I will =
commit it thisevening. Also i've made some general tweaks that mean =
hooks on WM_PAINT and WM_ERASEBKGND are now called after those messages =
are processed by Win32::GUI instead of before. This means that you can =
hook WM_PAINT on something and paint whenever you need to paint, which =
is really handy for drawing things in the window client area.

Steve

Re: [perl-win32-gui-hackers] CVS commit

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

At 20:59 2004-01-08, Steve Pick wrote:
> > What happens if you do:
> > $win->Hook(WM_MOVE, $mysub);
> > $win->Hook(WM_MOVE, $myothersub);
>
>Two hooks are assigned. When $win receives WM_MOVE, $mysub is called, then
>$myothersub is called.

Ah, that accounts for my confusion. The solution was more clever than I 
expected, not less :)


/J

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

Latest bookmark: "Open Text Summarizer"
http://libots.sourceforge.net/
dmoz (1 of 6): /Computers/Software/Operating_Systems/Linux/ 9

Re: [perl-win32-gui-hackers] CVS commit

[Steve P. <st...@ba...>]

Hi,

> >When removing hooks they are identified by coderef, so this is WRONG:
> >
> >$win->Hook(WM_MOVE, sub { print "moved!" });
> >$win->UnHook(WM_MOVE, sub { print "moved!" });
> >
> >In that case, UnHook will return false and the hook will not be removed
> >because the codref passed to the UnHook call will be different to the one
> >passed to Hook. You should do it like this:
> >
> >$movedsub = sub { print "moved!\n" };
> >$win->Hook(WM_MOVE, $movedsub);
> >$win->UnHook(WM_MOVE, $movedsub);
>
> I'm sorry but, from the outside, doesn't this seem slightly illogical?

No? From what you wrote below there might be some misunderstanding here...

> What happens if you do:
> $win->Hook(WM_MOVE, $mysub);
> $win->Hook(WM_MOVE, $myothersub);

Two hooks are assigned. When $win receives WM_MOVE, $mysub is called, then
$myothersub is called.

> or even using the same handler for two windows:
> $win->Hook(WM_MOVE, $mysub);
> $win2->Hook(WM_MOVE, $mysub);
> Would that result in weirdness?

No, when $win receives WM_MOVE, $mysub is called. when $win2 receives
WM_MOVE, $mysub is called. Hooklists are per-object. It works as you would
expect. If you want to remove $mysub handler from $win2, you'd do
$win2->UnHook(WM_MOVE,$mysub); - literally "remove the $mysub handler from
$win2's list of handlers for WM_MOVE".

> Would it not be more logical to key the hook by the $win and the message
> (WM_MOVE) rather than the handler coderef?

No. The hook is ALREADY keyed by the $win, we're (pseudo) object oriented
here. There is an individual array of handlers for every message for every
window/widget. This is to allow you to add several hooks to ONE message in a
specific window. The advantages of this include:
1) 3rd party modules can get a window object passed to them and assign and
unassign their own hooks without breaking the users own hooks, since every
hook you remove is identified by the coderef of the handler, there is no
possibility that a 3rd party module could accidentally remove one of the
users own hooks.
2) You can temporarilly make one window message call an additional handler,
without first having to remove the original handler and re-add the original
handler afterwards.
3) It's just generally versatile.

Also, the semantics are not strange if you do something like this:

$win->Hook(WM_MOVE,\&handler);
$win->UnHook(WM_MOVE,\&handler);

since \&handler always returns a coderef of the same value.

Hope that helps,

Steve

Re: [perl-win32-gui-hackers] CVS commit

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

At 02:33 2004-01-08, Steve Pick wrote:
>When removing hooks they are identified by coderef, so this is WRONG:
>
>$win->Hook(WM_MOVE, sub { print "moved!" });
>$win->UnHook(WM_MOVE, sub { print "moved!" });
>
>In that case, UnHook will return false and the hook will not be removed
>because the codref passed to the UnHook call will be different to the one
>passed to Hook. You should do it like this:
>
>$movedsub = sub { print "moved!\n" };
>$win->Hook(WM_MOVE, $movedsub);
>$win->UnHook(WM_MOVE, $movedsub);

I'm sorry but, from the outside, doesn't this seem slightly illogical?

What happens if you do:
$win->Hook(WM_MOVE, $mysub);
$win->Hook(WM_MOVE, $myothersub);

or even using the same handler for two windows:

$win->Hook(WM_MOVE, $mysub);
$win2->Hook(WM_MOVE, $mysub);

Would that result in weirdness?


Would it not be more logical to key the hook by the $win and the message 
(WM_MOVE) rather than the handler coderef? 1) No strange semantics. 2) No 
need to remember what I happened to hook it with.

Or is it just me? :)


/J

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

Latest bookmark: "Open Text Summarizer"
http://libots.sourceforge.net/
dmoz (1 of 6): /Computers/Software/Operating_Systems/Linux/ 9

Re: [perl-win32-gui-hackers] CVS commit

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

On approximately 1/7/2004 5:33 PM, came the following characters from
the keyboard of Steve Pick:
> Hi,
> 
> I've committed the updated hooks code in 665-Fix. See GUI.xs for the
> documentation for the Hook and UnHook functions.
> 
> What's new:
> 
> Hooks work in Old Event Model and New Event Model

Thanks.  The above should let me catch WM_MENUCHAR messages, which are 
needed in order to handle keystrokes that are not simple alphanumerics, 
when displaying menus.  Eventually.  When I get to it.

-- 
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] CVS commit

[Steve P. <st...@ba...>]

Hi,

I've committed the updated hooks code in 665-Fix. See GUI.xs for the
documentation for the Hook and UnHook functions.

What's new:

Hooks work in Old Event Model and New Event Model
You can hook WM_COMMAND and WM_NOTIFY submessages if you call Hook on a
child widget (like a button, for example)
You can now add multiple hooks for each message. Calling Hook(MSG, CODEREF)
no longer replaces the current handler returning the old handler for that
hook (which didnt work properly anyway) but adds another handler for the
specified message. Returns true if adding succeeded or false otherwise
(normally if it returns false then the hook has already been defined).

When removing hooks they are identified by coderef, so this is WRONG:

$win->Hook(WM_MOVE, sub { print "moved!" });
$win->UnHook(WM_MOVE, sub { print "moved!" });

In that case, UnHook will return false and the hook will not be removed
because the codref passed to the UnHook call will be different to the one
passed to Hook. You should do it like this:

$movedsub = sub { print "moved!\n" };
$win->Hook(WM_MOVE, $movedsub);
$win->UnHook(WM_MOVE, $movedsub);

Some more arguments have been added to the handler callbacks. These are
$type and $msg. $msg is simply the code for the message that triggered the
hook, and $type is 0 for normal window message, WM_NOTIFY for WM_NOTIFY
messages, and WM_COMMAND for WM_COMMAND messages. $type is there because
often WM_COMMAND submessages, WM_NOTIFY submessages and normal messages can
conflict so it's good to check if your handler has been called by the
correct type of message. Yes this is a nasty kludge, but i chose it because
all the other options would have taken too long to get right or would have
been less intuitive.

Doing UnHook() inside a hook handler seems to be safe (after a lot of
bugfixing and tweaks to make it safe), but if you find any problems (usually
crashes) with this kind of thing let me know.

Steve Pick
st...@ba...

Re: [perl-win32-gui-hackers] Millions of constants

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

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

> Hi,
> 
> I've identified about 4000 constants from CommCtl.h and WinUser.h that are not exported by Win32::GUI.
> 
> I've autogenerated a GUI_Constants.cpp but I'm reluctant to add it to the current CVS as it seems like an incredible bloat.
> 
> Perhaps this absolutely huge list of constants could be a support module for Win32::GUI?
> 
> E.g.:
> 
> use Win32::GUI::Constants
> 
> Good idea or should they just be added to the base Win32::GUI? Remember that in Perl code these constants are rarely asked for (but are nevertheless important), so there won't be a noticeable speed hit, just a size increase (GUI.pm and GUI_Constants.cpp will grow by about 70kb and 800kb respectively).
> 
> Steve

Well, I recently added the TPM_* constants directly to Win32::GUI.

One could make the argument that we could just add them as we need them, 
or we could be proactive, as you seem to have been, and decide to add 
them all.  Certainly, there are probably applications for which each 
individual constant could be useful.

I guess I don't have a problem with the bloat of adding them directly to 
  Win32::GUI.

If others do, then perhaps one could write them as separately package 
constant packages, if there is a good way to divvy them up.  I could see 
where they could be useful to people that don't use Win32::GUI but do 
use Win32::API, for example.  So a structure like

Win32::Constants::WM
Win32::Constants::WM_NOTIFY
Win32::Constants::TPM

etc.  Could allow people to simply include the constant packages that 
they need.  Or maybe that is more trouble than it is worth, given that 
they are somewhat dynmaically loaded anyway, so maybe just a single big 
package of all the Windows constants would be fine.  Or a big package, 
but with a clever exports list, that would allow not individual 
constants to be exported, but groups like the proposed packages above.

-- 
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] Millions of constants

[Stephen P. <Ste...@uc...>]

Hi,

I've identified about 4000 constants from CommCtl.h and WinUser.h that =
are not exported by Win32::GUI.

I've autogenerated a GUI_Constants.cpp but I'm reluctant to add it to =
the current CVS as it seems like an incredible bloat.

Perhaps this absolutely huge list of constants could be a support module =
for Win32::GUI?

E.g.:

use Win32::GUI::Constants

Good idea or should they just be added to the base Win32::GUI? Remember =
that in Perl code these constants are rarely asked for (but are =
nevertheless important), so there won't be a noticeable speed hit, just =
a size increase (GUI.pm and GUI_Constants.cpp will grow by about 70kb =
and 800kb respectively).

Steve

Re: [perl-win32-gui-hackers] Which CVS branch are we supposed to use?

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

Which CVS branch are we supposed to use?Hi,

    I continue to commit on 665-Fix branch. Latest sourcecode is on this
branch.
    Win32-GUI-0_0_670 is a tag on Win32-GUI-665-Fix branch.

    Main branch it's keep for next Aldo code base.

Laurent.

> Now there's a CVS branch for 670 and 665-Fix. Which one are we meant to
commit to? Which one contains the latest code? Shouldn't > we make the 670
branch the one we're all meant to commit to now?

Re: [perl-win32-gui-hackers] Which CVS branch are we supposed to use?

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

Which CVS branch are we supposed to use?Humm - good point.=20

I've been using the 665-fix branch to build the latest code line. I've =
just had a look and there have been no changes to 670 - so 665-fix is =
the latest code line. Although in theory, 670 should be the latest.

I guess it comes down to how Aldo wants to handle code releases? My =
personal viewpoint is that there should be new builds on a regular =
basis, with=20
"everyone" contributing to the latest code line.=20

jez.

  ----- Original Message -----=20
  From: Stephen Pick=20
  To: Win32 GUI Hackers (E-mail)=20
  Sent: Monday, January 05, 2004 12:45 PM
  Subject: [perl-win32-gui-hackers] Which CVS branch are we supposed to =
use?


  Hi,=20

  Now there's a CVS branch for 670 and 665-Fix. Which one are we meant =
to commit to? Which one contains the latest code? Shouldn't we make the =
670 branch the one we're all meant to commit to now?

  Steve=20

[perl-win32-gui-hackers] Which CVS branch are we supposed to use?

[Stephen P. <Ste...@uc...>]

Hi,

Now there's a CVS branch for 670 and 665-Fix. Which one are we meant to =
commit to? Which one contains the latest code? Shouldn't we make the 670 =
branch the one we're all meant to commit to now?

Steve

[perl-win32-gui-hackers] Menu enhancement patch for gui_options

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

Hi Laurent, and others,

Here is a patch to enhance menus, by exposing more Windows options to Perl.

The new code is in the first part of the patch, I think you have already 
applied the second part of the patch.

After the patch I give a usage sample.


diff -c D:\Win32-GUI-rel-0.0.665\gui_options.cpp gui_options.cpp
*** D:\Win32-GUI-rel-0.0.665\gui_options.cpp	Wed Feb 27 03:09:22 2002
--- gui_options.cpp	Sat Jan  3 20:55:41 2004
***************
*** 896,901 ****
--- 896,913 ----
                   SwitchBit(mii->fMask, MIIM_TYPE, 1);
                   next_i = i + 1;
                   SwitchBit(mii->fType, MFT_SEPARATOR, SvIV(ST(next_i)));
+             } else if(strcmp(option, "-menubarbreak") == 0) {
+                 SwitchBit(mii->fMask, MIIM_TYPE, 1);
+                 next_i = i + 1;
+                 SwitchBit(mii->fType, MFT_MENUBARBREAK, SvIV(ST(next_i)));
+             } else if(strcmp(option, "-menubreak") == 0) {
+                 SwitchBit(mii->fMask, MIIM_TYPE, 1);
+                 next_i = i + 1;
+                 SwitchBit(mii->fType, MFT_MENUBREAK, SvIV(ST(next_i)));
+             } else if(strcmp(option, "-radiocheck") == 0) {
+                 SwitchBit(mii->fMask, MIIM_TYPE, 1);
+                 next_i = i + 1;
+                 SwitchBit(mii->fType, MFT_RADIOCHECK, SvIV(ST(next_i)));
               } else if(strcmp(option, "-default") == 0) {
                   SwitchBit(mii->fMask, MIIM_STATE, 1);
                   next_i = i + 1;
***************
*** 907,913 ****
               } else if(strcmp(option, "-enabled") == 0) {
                   SwitchBit(mii->fMask, MIIM_STATE, 1);
                   next_i = i + 1;
!                 SwitchBit(mii->fState, MFS_ENABLED, SvIV(ST(next_i)));
               } else if(strcmp(option, "-name") == 0) {
                   next_i = i + 1;
   #ifdef PERLWIN32GUI_STRONGDEBUG
--- 919,925 ----
               } else if(strcmp(option, "-enabled") == 0) {
                   SwitchBit(mii->fMask, MIIM_STATE, 1);
                   next_i = i + 1;
!                 SwitchBit(mii->fState, MFS_DISABLED, ! SvIV(ST(next_i)));
               } else if(strcmp(option, "-name") == 0) {
                   next_i = i + 1;
   #ifdef PERLWIN32GUI_STRONGDEBUG
=====================================================================

$m_config = new Win32::GUI::Menu (
   'Config' => 'sConfig',
   ">&newest" => 'sNewest',
   ">&this year" => 'sThisYear',
   ">&last year" => 'sLastYear',
   ">&prior year" => 'sPriorYear',
   ">&all years" => 'sAllYear',
   ">&open file" => 'sFile',
   ">&show debug window" => 'sShowDos',
   ">&reset data directory" => 'sGetDataDir',
   );
if ( ! $m_config )
{ & mydie ( $msgpfx . "m_config creation error: $^E\n" );
}

$m_config->{'sFile'}->Change( -menubarbreak => 1 );

This causes the last three entries to be displayed in a separate menu 
column, with a vertical separator bar.

I suppose one could instead parse special characters after the > in the 
menu entry, and set these automatically, but it would risk backwards 
compatibility with user's existing menu entry texts.

-- 
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] Patch for GUI.pm

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

Hi,

    I commit it to CVS.

Happy new year,
    Laurent.

> Laurent, and others,
> 
> Here is a patch that gives a default event name to every item for which 
> the user supplies an empty string, instead of just the ones that have a 
> text string of '-'.  It even saves a little code, I think.
> 
> It helps a system I am building, and is fully upward compatible with the 
> existing functionality, so I would appreciate it if it could get into 
> the next bug-fix release of Win32::GUI.  Thanks.