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

[perl-win32-gui-hackers] About time for a release?

[Blair S. <bs...@nu...>]

Hi all, 

Just wondering when we might get a new release of Win32::GUI. I notice the 
files on the Sourceforge homepage are v671 and CPAN still has v558 but i've 
been using v681 from CVS quite sucessfully now with Win32::GUI::XMLBuilder 
0.36 with no problems. I would like to make this release (WGX 0.36) public 
to CPAN but the accessibility of Win32::GUI is causing some problems for 
users. 

Any thoughts?
Blair

[perl-win32-gui-hackers] Bug (feature?!) with hooks

[Glenn W M. <gw...@se...>]

While checking into a problem with textfields and the -noflicker option (and
with some help from Jez White-thanks Jez), I found that the latest
development code breaks one of my applications. What I'm not sure is whether
it is a bug, or whether it is by design (Laurent, I think you will be the
one to know). My application hooks the LVN_ITEMCHANGED event, but it doesn't
work with the development code. Looking at the changes in listview.xs, I see
that the event is now handled here, where it wasn't before. Am I right in
thinking this is related to the NEM? In any case, was it expected that this
would prevent the user from hooking the LVN_ITEMCHANGED event, or is it a
bug with the implementation?

[perl-win32-gui-hackers] Color broken?

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

[Everything below relates 0.0.670]

Re: this post over at PerlMonks:
http://www.perlmonks.org/index.pl?node_id=370447

Is the -color of Win32::GUI::Class broken for anything other than system 
colors?

According to the code, this should work:
my $clsColor = Win32::GUI::Class->new(
     -name => "classColor",
     -color => [23, 12, 32],
     ) or die("Could not create Class\n");

(it dies)

Also, a color like "#FFCCFF" should work, but doesn't. The -color also 
can't take a Brush object as the docs indicate would be supported (but the 
code doesn't (the SvCOLORREF function)). None of this works for me.

Actually, the -background option of a Window seems to behave the same, but 
it also uses SvCOLORREF.


Or is it just me? :)


/J
-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "Oracle9i, Locally Managed Tablespaces (LMT) - E..."
<http://www.praetoriate.com/oracle_tips_storage_parameters.htm>
dmoz (1 of 6): /Computers/Programming/Languages/PL-SQL/ 50

Re: [perl-win32-gui-hackers] bug in Text()

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

On approximately 6/26/2004 1:30 PM, came the following characters from
the keyboard of Glenn Linderman:
> It seems like the development version of GUI has a bug.
> 
> The released versions of ->Text() without a parameter return the current 
> value from the object, without resetting it first.
> 
> The development version of ->Text() without a parameter seems to reset 
> the object, before returning the value.  This eliminates the ability to 
> "read" values.
> 
> This problem manifested itself to me when attempting to use ->Text() on 
> a Label, I haven't yet investigated to see how many objects might be 
> affected, or looked at the source to see how complex the fix might be...
> 
> I just happened to use an old program that hadn't been "ported" to the 
> new GUI, with the new GUI, and this symptom cropped up.  Using the old 
> GUI "cured" the problem.

This is somewhat a false alarm... but not completely.  I can't reproduce 
it in the "obvious" test case, and the source code for the gui.xs Text 
function, which is the only place Text is defined in either version of 
GUI, is identical.

On the other hand, I do have an application that works fine with the old 
  GUI and fails with the new one... same application, and same Perl. 
And the symptom is that data returned from Text() is different.  So I'm 
presently quite confused, but I'll be working on figuring it out.

This is an application that uses 2 threads, via the Win32 Perl fork 
emulation.

In adding a bunch of print statements, I see that with the older 
Win32::GUI, both the parent and child report the same HASH(address) for 
the Label object of concern, whereas the current development version 
reports different HASH(address) values for the Label object of concern.

Yet with the new GUI, the parent starts reporting the different value 
prior to the child thread being created!

One would think that it might be a different sort of scoping or 
different rules for closures, if I weren't using the same version of 
Perl, and just switching GUI versions.

Sort of makes me wonder if there is something about the compilation of 
Win32::GUI that affects the scoping of variables defined later, which 
isn't supposed to happen, of course.  But I'm really grasping at straws 
here.

I've tried to make a small test case, but the small test cases so far 
work identically under the old and new GUI versions.

-- 
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] bug in Text()

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

It seems like the development version of GUI has a bug.

The released versions of ->Text() without a parameter return the current 
value from the object, without resetting it first.

The development version of ->Text() without a parameter seems to reset 
the object, before returning the value.  This eliminates the ability to 
"read" values.

This problem manifested itself to me when attempting to use ->Text() on 
a Label, I haven't yet investigated to see how many objects might be 
affected, or looked at the source to see how complex the fix might be...

I just happened to use an old program that hadn't been "ported" to the 
new GUI, with the new GUI, and this symptom cropped up.  Using the old 
GUI "cured" the problem.

-- 
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] AcceleratorTable documentation error

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

Hi,

    When you use a string as an accelerator function name, it's call
<name>_Click event.
    It's not try to call an "S3" sub but an "S3_Click" Sub.

    Just change :
sub S3 { $W->Caption("Shift-3"); }
    By :
sub S3_Click { $W->Caption("Shift-3"); }
    And it's work ;o)

Laurent.

PS : From last documentation :
  ... when an accelerator is used, a corresponding <name>_Click event is
fired.

> The docs suggest "Shift-3" should work but in fact you need a reference!
>
> snip--->
>
> use Win32::GUI;
>
> $A = new Win32::GUI::AcceleratorTable(
> "Shift-1" => \&S1,
> "Shift-2" => sub { $W->Caption("Shift-2"); },
> "Shift-3" => "S3",
> );
>
> $W = new Win32::GUI::Window(-accel => $A, -width => 200);
> $W->Show(1);
> Win32::GUI::Dialog;
>
> sub S1 { $W->Caption("Shift-1"); }
> sub S3 { $W->Caption("Shift-3"); }
>

[perl-win32-gui-hackers] AcceleratorTable documentation error

[Blair S. <bs...@nu...>]

The docs suggest "Shift-3" should work but in fact you need a reference! 

snip---> 

use Win32::GUI; 

$A = new Win32::GUI::AcceleratorTable(
	"Shift-1" => \&S1,
	"Shift-2" => sub { $W->Caption("Shift-2"); },
	"Shift-3" => "S3",
); 

$W = new Win32::GUI::Window(-accel => $A, -width => 200);
$W->Show(1);
Win32::GUI::Dialog; 

sub S1 {	$W->Caption("Shift-1"); }
sub S3 {	$W->Caption("Shift-3"); }

[perl-win32-gui-hackers] Update to BitmapScroll.pl example

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

Hi,

I've just committed an update to the BitmapScroll.pl example. The =
changes uses the new -onPaint handler, fixes various bugs and has better =
comments. Most, if not all of the changes where made by Glenn Linderman.

Cheers,

jez. 

[perl-win32-gui-hackers] SB_THUMBSCROLL

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

I've added support for SB_THUMBSCROLL to Win32::GUI::Scroll.  Because 
only some applications, that can redraw the screen adequately quickly, 
would care to have SB_THUMBSCROLL support, I've made it optional, via a 
true value, via a new optional parameter to Win32::GUI::Scroll.

-- 
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] Accelerator keys (NEM)

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

On approximately 6/3/2004 2:40 AM, came the following characters from
the keyboard of Glenn Linderman:
> So I've been busily incorporating Jez's bitmapscroll example code into 
> one of my mainstream programs, so that I can get away from the old MDI 
> model, which has been removed.
> 
> Mostly things are going well.

Things are now wonderful!

> However, I've just discovered that my Accelerator Keys for my main 
> window are being seen even when a secondary window is activated.

The problem was a missing definition of @acc in 
Win32::GUI::AcceleratorTable::new.

Shouldn't we turn on strict and warnings for GUI.pm?  Or has someone 
tried, and it is a big job?

-- 
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] [commit] -onPaint event for a window

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

Hi,

I've just committed the initial code for an -onPaint event handler for =
windows. This allows you full control when painting a window. In many =
cases the current Graphic control is adequate, but for more complicated =
problems (for example child windows with scroll bars) more control is =
needed. The event handler calls the windows API BeginPaint and EndPaint, =
so other than the logic to paint the window no other action is required.

The main work is done in GUI_MessageLoops.cpp - but should it be done in =
Window.xs?=20

We (Glenn and I) have been doing some playing/testing and it seems to =
work well. We also have had some discussions to what should be passed as =
parameters to the hander. Currently the parameters that are passed are =
the window and the DC. The DC parameter could potentially removed, since =
in almost all cases the window DC and the DC to be painted are always =
the same (the only exception seems to be when the -noflicker option is =
used). The bounding rectangle of the area to be redrawn could also be =
passed. In most cases this bounding rectangle is not required since in =
typical usage you repaint the entire window (by a BitBlt), the clipping =
region is created automatically before the event is called. =20

Usage:

  -onPaint =3D> \&Paint,
 =20
  sub Paint {
    my ($win,$dc)=3D@_;
    #paint into the passed DC
    }

Comments?

Cheers,

jez.

[perl-win32-gui-hackers] Accelerator keys (NEM)

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

So I've been busily incorporating Jez's bitmapscroll example code into 
one of my mainstream programs, so that I can get away from the old MDI 
model, which has been removed.

Mostly things are going well.

However, I've just discovered that my Accelerator Keys for my main 
window are being seen even when a secondary window is activated.

Shouldn't each window have its own accelerator table?  (yes)
And shouldn't the accelerator keys for a window only have effect when 
that window is the current active window?  (yes)

However, it seems that the current code base, at least for NEM which I 
am now using, doesn't have the right answers for these questions.

The old code, for OEM, did seem to have the right answers for these 
questions, and my program worked fine, having different accelerator keys 
in different windows, with the old GUI.  So this seems to be an issue 
either with converting from OEM to NEM, or from the old GUI code base to 
the current GUI code base, I'm not sure which at the time.

It is much too late in this time zone to start figuring out the new GUI, 
NEM, accelerator table logic, so I will begin looking tomorrow.  This is 
a major setback to my ability to use the new GUI model.... and here I 
thought I was so close :(

Any comments or patches that would be enlightening would be appreciated 
from those in other time zones, before I have to tackle this.  Off to 
bed now!

-- 
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] Re: another code revision

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

So, when I add "use warnings;" to the BitmapScroll.pl sample code, I get 
40 "Use of uninitialized value in subroutine entry..." warnings.

The line number information lines up with the call to EndPaint.

EndPaint contains 40 attempts to obtain "-ps.*" values.

There seems to be a correlation.

BUT:  The EndPaint code _seems_ to carefully check for NULL and exit. 
But I guess checking for NULL isn't the same as "Use of uninitialized 
value..."

So I added a call to DataDumper between the BeginPaint and EndPaint 
calls, to dump the window object.  No "-ps.*" entries are found.

Are there two bugs?  One/40 in BeginPaint to not really put the "-ps.*" 
entries in the window object?  And one/40 in EndPaint to access 
uninitialized values when attempting to retrieve the "-ps.*" objects 
that aren't there?

I'd really like to "cure" this problem, rather than leave warnings 
turned off.


On approximately 6/1/2004 12:18 PM, came the following characters from
the keyboard of Glenn Linderman:
> Of course not.  It kept getting later, and I kept getting tireder.  When 
> I sent that message, I forgot that I renamed my file, so I could see the 
> one in CVS again.
> 
> Oops.
> 
> This morning when I woke up, I realized I should add a couple more 
> comments, also.
> 
> Thanks for noticing.  And sorry for the confusion.  I kept learning 
> more, but I kept making silly mistakes too.
> 
> 
> On approximately 6/1/2004 1:57 AM, came the following characters from
> the keyboard of Jez White:
> 
>> Hi,
>>
>> Is this the correct version? The resize event is the same as the 
>> original?
>>
>> Cheers,
>>
>> jez.
>> ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...>
>> To: "Jez White" <je...@je...>
>> Sent: Tuesday, June 01, 2004 9:38 AM
>> Subject: another code revision
>>
>>
>>
>>> Hi Jez,
>>>
>>> I left some debug and try this sort of code in my last email.   Here 
>>> is the code without such.  Sorry for 3 versions before I got the 
>>> whole message across.  I think the text is reasonable, although I 
>>> learned more as I wrote each message.
>>>
>>> -- 
>>> 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.
>>>
>>>
>>
>>
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> #This example creates a scrolling bitmap within another window. This example
> #uses a hooked event to paint to the window directly, rather than using a
> #Graphic Control.
> 
> use Win32::GUI;
> use strict;
> 
> sub Paint {
>   #Paint event handler, called when ever the window needs to be redrawn/painted
>   #get the window that needs to be repainted, in this case it is the child window
>   my $mdc=shift;
>   my $win=shift;  
>   #tell windows that we are starting to paint
>   $win->BeginPaint;
>   #get the DC of this window
>   my $dc=$win->GetDC;
>   #Perform a bit block transfer of the memory DC into the window DC
>   #The cordinates are based upon the position of the scroll bars
>   $dc->BitBlt(0, 0, $win->Width,$win->Height,$mdc,$win->ScrollPos(0),$win->ScrollPos(1));
>   #tell windows that we have finished painting.
>   $win->EndPaint;
>   return 1;
> }
> 
> sub AdjScroll {
>   my $bmap=shift;
>   my $cwin=shift;
>   my ($cwid, $chei) = ($cwin->GetClientRect)[2..3];
>   #Set the scroll bar page of each scroll bar.
>   #This has the effect of increasing/decreasing the size of the bar within the
>   #scroll bar as the window is resized.
>   if ($bmap) {
>     my ($width,$height)=$bmap->Info();
>     while (1) {
>       #the ScrollPage calls might trigger a Resize event, so this code might
>       #run reentrantly.  To be sure we don't use old data later and overwrite
>       #newer data, we reobtain the ClientRect after each operation that might
>       #change it.
>       $cwin->ScrollPage(0,$cwid);
>       my ($cwidA, $cheiA) = ($cwin->GetClientRect)[2..3];
>       $cwin->ScrollPage(1,$cheiA);
>       my ($cwid2,$chei2) = ($cwin->GetClientRect)[2..3];
>       my ($cwid3,$chei3) = ($cwin->Width,$cwin->Height);
>       last if $cwid == $cwid2  &&  $chei == $chei2;
>       ($cwid,$chei) = ($cwid2,$chei2);
>     }
>   }
> }
> 
> sub Resize {
>   #Resize handler, get the window
>   my $bmap=shift;
>   my $cwin=shift;
>   & AdjScroll($bmap,$cwin);
>   return 1;
> }
> 
> sub OpenBitmap {
>   my ($bmap,$mdc,$cwin) = @_;
>   #Function to load in the bitmap
>   my $file = Win32::GUI::GetOpenFileName(
>                    -owner => $cwin,
>                    -hidereadonly => 0,
>                    -title  => "Open an bitmap file",
>                    -filter => ['Bitmaps' => '*.bmp',
>                                'All files' => '*.*',
>                               ],                
>                    );
>   $bmap=new Win32::GUI::Bitmap($file);
>   $_[0]=$bmap; # set original parameter
>   if ($bmap) {
>     #if we have a valid bitmap, get the dimensions
>     my ($width,$height)=$bmap->Info();
>     #select the bitmap into the memory DC so it can be manipulated later.
>     $mdc->SelectObject($bmap);
>     #set the scroll bars to 0.
>     $cwin->ScrollRange(0,0,$width);
>     $cwin->ScrollRange(1,0,$height);
>     $cwin->ScrollPos(0,0);   
>     $cwin->ScrollPos(1,0);
>     & AdjScroll($bmap,$cwin);
>     $cwin->InvalidateRect(1); #invalidate the child window so windows triggers the paint event
>   }
>   return 1;
> }
> 
> sub Scroll {
>   #Scroll event handler. We have to explicitly "move" the scroll bars.
>   #Once they have been moved, we repaint the window.
>   my($win,$scrollbar, $operation, $position) = @_;
>   if($operation == SB_THUMBTRACK) {
>     $win->ScrollPos($scrollbar,$position);
>     }
>   elsif($operation == SB_LINEDOWN) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar)+1);
>   }
>   elsif($operation == SB_LINEUP) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar)-1);
>   }
>   elsif($operation == SB_PAGEDOWN) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar) + $win->ScrollPage($scrollbar));
>   }
>   elsif($operation == SB_PAGEUP) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar) - $win->ScrollPage($scrollbar));
>   }
>   #invalidate the child window so windows triggers the paint event
>   $win->InvalidateRect(0);
>   return 1;
> }
> 
> #create a new class which stops the WM_ERASEBKGND message from erasing the
> #background this stops the flicker of the window on resize.
> my $WC = new Win32::GUI::Class(
>     -name => "NoFlicker", 
>     -style => 0,
> );
> 
> #Define global variable
> my $bitmap;        #will hold the bitmap
> 
> sub MainResize {
>   my $win=shift;
>   my ($width, $height) = ($win->GetClientRect)[2..3];
>   $win->Open->Left($width-120);
>   $win->ChildWin->Resize($width-150,$height);
>   return 1;
> }
> 
> #Create the window and child controls.
> my $mainwin = new Win32::GUI::Window (
>     -pos         => [100, 100],
>     -size        => [330, 235],
>     -name        => "Window",
>     -text        => "Bitmap Scroll demo",
>     -pushstyle   => WS_CLIPCHILDREN,
>     -class       => $WC,
>     #NEM Events for this window
>     -onResize    => \&MainResize,
>     -onTerminate => sub {return -1;}
> );
> 
> #Create a child window with a scroll bars. 
> my $ChildWin = new Win32::GUI::Window (
>     -parent      => $mainwin,
>     -name        => "ChildWin",
>     -pos         => [0, 0],
>     -size        => [180, 235],
>     -popstyle    => WS_CAPTION | WS_SIZEBOX,
>     -pushstyle   => WS_CHILD | WS_CLIPCHILDREN,
>     -pushexstyle => WS_EX_CLIENTEDGE,
>     -class       => $WC,
>     -hscroll     => 1,
>     -vscroll     => 1,
>     -onScroll    => \&Scroll,
>     -onResize    => sub {&Resize($bitmap,@_)},
> );
> 
> #Create a memory DC compatible with the child window DC
> my $memdc=$ChildWin->GetDC->CreateCompatibleDC();
> 
> $mainwin->AddButton (
>     -name        => 'Open',
>     -pos         => [205, 20],
>     -size        => [110, 20],
>     -text        => 'Open Bitmap',
>     -onClick     => sub{ &OpenBitmap( $bitmap, $memdc, $ChildWin, @_ ) },
> );
> 
> #hook into the paint event of the child window
> $ChildWin->Hook(15, sub { &Paint( $memdc, @_ )});
> 
> #show both windows and enter the Dialog phase.
> $mainwin->Show();
> $ChildWin->Show();
> 
> Win32::GUI::Dialog();

-- 
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 build

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

On approximately 6/1/2004 2:34 AM, came the following characters from
the keyboard of Jez White:

> Hi all,
>  
> For the last couple of builds I've been getting this error:
>  
> Win32::GUI object version 0.0.671 does not match $Win32::GUI::VERSION 
> 0.0.681 at
>  C:/Perl/lib/DynaLoader.pm line 225.

nmake clean
nmake

should cure it

> Anyone else been getting this?

So I only saw it once...

> Cheers,
>  
> jez.

-- 
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 build

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

Thanks, worked a treat:)

jez.
  ----- Original Message -----=20
  From: Laurent ROCHER=20
  To: Jez White ; Win32 GUI Hackers=20
  Sent: Tuesday, June 01, 2004 6:43 PM
  Subject: Re: [perl-win32-gui-hackers] new build


  Try, to clean you build environement and regenerate makefile.

  nmake clean
  perl Makefile.pl or perl Makefile_m.pl
  nmake install

  Laurent.
    ----- Original Message -----=20
    From: Jez White=20
    To: Win32 GUI Hackers=20
    Sent: Tuesday, June 01, 2004 11:34 AM
    Subject: [perl-win32-gui-hackers] new build


    Hi all,

    For the last couple of builds I've been getting this error:

    Win32::GUI object version 0.0.671 does not match =
$Win32::GUI::VERSION 0.0.681 at
     C:/Perl/lib/DynaLoader.pm line 225.

    Anyone else been getting this?

    Cheers,

    jez.

Re: [perl-win32-gui-hackers] new build

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

Try, to clean you build environement and regenerate makefile.

nmake clean
perl Makefile.pl or perl Makefile_m.pl
nmake install

Laurent.
  ----- Original Message -----=20
  From: Jez White=20
  To: Win32 GUI Hackers=20
  Sent: Tuesday, June 01, 2004 11:34 AM
  Subject: [perl-win32-gui-hackers] new build


  Hi all,

  For the last couple of builds I've been getting this error:

  Win32::GUI object version 0.0.671 does not match $Win32::GUI::VERSION =
0.0.681 at
   C:/Perl/lib/DynaLoader.pm line 225.

  Anyone else been getting this?

  Cheers,

  jez.

[perl-win32-gui-hackers] new build

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

Hi all,

For the last couple of builds I've been getting this error:

Win32::GUI object version 0.0.671 does not match $Win32::GUI::VERSION =
0.0.681 at
 C:/Perl/lib/DynaLoader.pm line 225.

Anyone else been getting this?

Cheers,

jez.

[perl-win32-gui-hackers] MAIN CVS Commit

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

Hi,

    I commit new things.

    * A new InitMenu event for Window.=20
    This event is fire when user first select a menuitem.
    It's usefull for refresh menuitem (enable/disable menuitem).

    * Add some helpfull methods for textfield too.
=20
    * A Notepad sample.
    It's actually not exactly same as standard windows notepad but main =
feature exists.

Changelog

    - GUI.pm, GUI_Constants.cpp :
        + Add MessageBox return value constants.
    - GUI.xs :
        + Create : Force a window name for all control.
        + Add MessageBeep.
        + ChooseFont : Change -size by -pointsize option and return =
value.
    - GUI_Events.cpp :
        + DoEvent_Menu : Add Self for NEM event.
    - GUI_Helpers.cpp :
        + Perlud_Free : Check if svSelf is a valid SV before use it.
    - GUI_MessageLoops.cpp :
        + WindowMsgLoop : Add WM_INITMENU event.
    - Textfield.xs :
        + Fix EN_UPDATE event handler name.
        + New Methods : CanPaste & HaveSel.
    - Window.xs:
        + New InitMenu event.
    - Samples\Notepad.pl : New file


Laurent

[perl-win32-gui-hackers] Commit

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

Hi,

I've just committed a couple of items:

  samples\BitmapScroll.pl

The bitmap scroller, contains a fix for the bug reported by Glenn, as =
well as his suggestions on making the event handlers more generic.

GUI.xs

  Added LoadString Method

Cheers,

jez.

Re: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)

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

How about adding -onPaint and -onEraseBkGnd just to windows and not all
controls? An alternative would be to make the Graphic control more flexible,
adding scroll bar support etc.

jez.

----- Original Message ----- 
From: "Laurent ROCHER" <ro...@cl...>
To: "Jez White" <je...@je...>
Cc: "guihackers" <per...@li...>
Sent: Tuesday, May 18, 2004 4:55 PM
Subject: Re: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)


> Hi,
>
>     Graphic control it's a specialized window for painting issue.
> Graphic was created only for provide Paint event for user wanted to draw
> specific stuff.
>     Paint event, it's not usefull for standard/common control (button,
> listbox, ...). And, for doing owner draw control, it's not WM_PAINT event
to
> use but WM_DRAWITEM/NM_CUSTOMDRAW.
>
> For me, it's not a good idea to add this event for all control.
> If you really need this event for a special case, it's better to use
> HookEvent.
>
> For performance, WM_PAINT it's a frequent event so adding it to every
> control can slowdown application.
>
>     But, It's a good idea to add -onEraseBkGnd event to Graphic control.
>
> Laurent.
>
> >
> > I had  assumed that the Graphic control was some sort of windows thing.
> It's
> > not, its a perl thing. A graphic is simply a window, with XS code to
call
> > the paint and interactive events in perl. I must admit that other than
the
> > paint handler, I'm a bit stumped to come up with a reason why the
Graphic
> > control exits, other than in older versions of Win32::GUI normal windows
> did
> > not have the events associated with an "interactive" Graphic (mousemove
> > etc). So if a normal window had a paint handler, why use a graphic
> control?
> >
> > It also turns out there is an alternatives to using Windows
> > BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how
> > painting works for Graphic controls (ValidateRect is Validate in Perl
> > speak). There are subtle differences to BeginPaint/EndPaint and
> > ValidateRect/GetUpdateRect but I'll have to play to see what the effects
> are
> > in reality. You can use the Validate method on a DC for a hooked paint
> > event.
> >
> > If adding an -onPaint event is a sensible thing (I think it is) I also
> > suggest adding the event -onEraseBkGnd  (WM_ERASEBKGND). Having this
event
> > would give more control in how the background is erased (that annoying
> > flicker on resize). My only concern is would this effect the performance
> of
> > windows who do not explicitly use these events?
> >
>

Re: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)

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

Hi,

    Graphic control it's a specialized window for painting issue.
Graphic was created only for provide Paint event for user wanted to draw
specific stuff.
    Paint event, it's not usefull for standard/common control (button,
listbox, ...). And, for doing owner draw control, it's not WM_PAINT event to
use but WM_DRAWITEM/NM_CUSTOMDRAW.

For me, it's not a good idea to add this event for all control.
If you really need this event for a special case, it's better to use
HookEvent.

For performance, WM_PAINT it's a frequent event so adding it to every
control can slowdown application.

    But, It's a good idea to add -onEraseBkGnd event to Graphic control.

Laurent.

>
> I had  assumed that the Graphic control was some sort of windows thing.
It's
> not, its a perl thing. A graphic is simply a window, with XS code to call
> the paint and interactive events in perl. I must admit that other than the
> paint handler, I'm a bit stumped to come up with a reason why the Graphic
> control exits, other than in older versions of Win32::GUI normal windows
did
> not have the events associated with an "interactive" Graphic (mousemove
> etc). So if a normal window had a paint handler, why use a graphic
control?
>
> It also turns out there is an alternatives to using Windows
> BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how
> painting works for Graphic controls (ValidateRect is Validate in Perl
> speak). There are subtle differences to BeginPaint/EndPaint and
> ValidateRect/GetUpdateRect but I'll have to play to see what the effects
are
> in reality. You can use the Validate method on a DC for a hooked paint
> event.
>
> If adding an -onPaint event is a sensible thing (I think it is) I also
> suggest adding the event -onEraseBkGnd  (WM_ERASEBKGND). Having this event
> would give more control in how the background is erased (that annoying
> flicker on resize). My only concern is would this effect the performance
of
> windows who do not explicitly use these events?
>

Re: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)

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

On approximately 5/18/2004 7:49 AM, came the following characters from
the keyboard of Jez White:
> Ok, I've done some more digging and reading of Win API (is it just me, or
> does internet explorer freeze now and again when looking at MS
> documentation?)
> 
> I had  assumed that the Graphic control was some sort of windows thing. It's
> not, its a perl thing. A graphic is simply a window, with XS code to call
> the paint and interactive events in perl. I must admit that other than the
> paint handler, I'm a bit stumped to come up with a reason why the Graphic
> control exits, other than in older versions of Win32::GUI normal windows did
> not have the events associated with an "interactive" Graphic (mousemove
> etc). So if a normal window had a paint handler, why use a graphic control?

Perhaps so that it is a "widget" instead of a "window"?  (In perl speak, 
not Windows speak.)

> It also turns out there is an alternatives to using Windows
> BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how
> painting works for Graphic controls (ValidateRect is Validate in Perl
> speak). There are subtle differences to BeginPaint/EndPaint and
> ValidateRect/GetUpdateRect but I'll have to play to see what the effects are
> in reality. You can use the Validate method on a DC for a hooked paint
> event.

Hmm.  TMTOWTDI.  When there is only one known way, one just attempts to 
solves all problems in terms of that one way.  And one learns enough to 
do that, but maybe never comes to a true understanding of that one... 
one could just have "rote sequences" for doing desired things.  However, 
once one becomes aware of a second way to do things, then one must 
puzzle out a deeper understanding of the original way, as well as the 
new way, so that one can understand and choose which way is best for 
which solutions.  One probably learns more when TMTOWTDI.

> If adding an -onPaint event is a sensible thing (I think it is) I also
> suggest adding the event -onEraseBkGnd  (WM_ERASEBKGND). Having this event
> would give more control in how the background is erased (that annoying
> flicker on resize). My only concern is would this effect the performance of
> windows who do not explicitly use these events?

Well, all the events come into the GUI XS event messageloop.  So the 
more cases there are to test for, the slower all events become.  I think 
that is why the bitmap exists... for a quick check on the likelihood 
that there is a Perl function to be called for this event, or not.

I would think it is reasonable to bundle WM_ERASEBKGRND and WM_PAINT 
into the same bit of the bitmap, because they are likely to be used or 
disused, for the same windows (bits in the bitmap are a scarce resource)

But I don't think the addition of an extra event to check for would be a 
significant slowdown to all windows, unless much code is added just to 
determine whether or not it is "this event", and that is typically done 
with the switch statement, and the cost of an extra case in a switch 
statement, while not zero, is not generally high overhead.

>>>There were two new functions added not
>>>to long ago that may help with keystrokes, GetKeyboardState and
>>>GetAsyncKeyState. I've managed to get pseudo accelerator keys working on
>>>individual controls with them.
>>
>>Maybe there's some sample code lurking within your application there :)
> 
> I'll try and put an example together.

Thanks.

-- 
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] GUI.xs (BeginPaint and EndPaint)

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

Ok, I've done some more digging and reading of Win API (is it just me, or
does internet explorer freeze now and again when looking at MS
documentation?)

I had  assumed that the Graphic control was some sort of windows thing. It's
not, its a perl thing. A graphic is simply a window, with XS code to call
the paint and interactive events in perl. I must admit that other than the
paint handler, I'm a bit stumped to come up with a reason why the Graphic
control exits, other than in older versions of Win32::GUI normal windows did
not have the events associated with an "interactive" Graphic (mousemove
etc). So if a normal window had a paint handler, why use a graphic control?

It also turns out there is an alternatives to using Windows
BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how
painting works for Graphic controls (ValidateRect is Validate in Perl
speak). There are subtle differences to BeginPaint/EndPaint and
ValidateRect/GetUpdateRect but I'll have to play to see what the effects are
in reality. You can use the Validate method on a DC for a hooked paint
event.

If adding an -onPaint event is a sensible thing (I think it is) I also
suggest adding the event -onEraseBkGnd  (WM_ERASEBKGND). Having this event
would give more control in how the background is erased (that annoying
flicker on resize). My only concern is would this effect the performance of
windows who do not explicitly use these events?

> > There were two new functions added not
> > to long ago that may help with keystrokes, GetKeyboardState and
> > GetAsyncKeyState. I've managed to get pseudo accelerator keys working on
> > individual controls with them.
>
> Maybe there's some sample code lurking within your application there :)

I'll try and put an example together.

Cheers,

jez.

Re: [perl-win32-gui-hackers] Bitmap Scolling example.

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

Cool. I'll go through the comments and improve the calls.

Cheers,

jez.
----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Jez White" <je...@je...>
Cc: "guihackers" <per...@li...>
Sent: Tuesday, May 18, 2004 7:14 AM
Subject: Re: [perl-win32-gui-hackers] Bitmap Scolling example.

Re: [perl-win32-gui-hackers] Bitmap Scolling example.

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

On approximately 5/17/2004 2:02 AM, came the following characters from
the keyboard of Jez White:

> Assuming there is no problem with this example and people think it's 
> useful I'll commit it to the samples folder today.

Well, as long as it isn't committed yet....?  Or even if it is, perhaps 
another go-round would be acceptable.  I have read through the code now, 
and apologies if I say something stupid, because I'm tired and it is 
bed-time, but perhaps a few extra comments would make the sample even 
more useful than it already is.  I'll throw some in, but they may not be 
accurate, so please double check me.

Most of my comments are related to my thought that the NEM allows the 
writing of "generic" functions for particular functionality.  I haven't 
tried any of the stuff I'm suggesting here.... yet....

> ==================
> #This example creates a scrolling bitmap within another window. This 
> example uses
> #a hooked event to paint to the window directly, rather than using a Graphic
> #Control.
>  
> use Win32::GUI;
> use strict;
>  
> #create a new class which stops the WM_ERASEBKGND message from erasing 
> the background

# Because of this, it is necessary to redraw background explicitly 
if/when the bitmap changes size, especially if it becomes smaller.

> my $WC = new Win32::GUI::Class(
>     -name => "NoFlicker",
>     -style => 0,
> );
>  
> #Create the window and child controls.
> my $mainwin = new Win32::GUI::Window (
>     -pos         => [100, 100],
>     -size        => [330, 235],
>     -name        => "Window",
>     -text        => "Bitmap Scroll demo",
>     -pushstyle   => WS_CLIPCHILDREN,
>     -class       => $WC,
>     #NEM Events for this window
>     -onResize    => \&Resize,
>     -onTerminate => sub {return -1;}
> );
>  
> $mainwin->AddButton (
>     -name        => 'Open',
>     -pos         => [205, 20],
>     -size        => [110, 20],
>     -text        => 'Open Bitmap',
>     -onClick     => \&OpenBitmap,
> );
>  
> #Create a child window with a scroll bars.
> my $ChildWin = new Win32::GUI::Window (
>     -parent      => $mainwin,
>     -name        => "ChildWin",
>     -pos         => [0, 0],
>     -size        => [200, 200],
>     -popstyle    => WS_CAPTION | WS_SIZEBOX,
>     -pushstyle   => WS_CHILD | WS_CLIPCHILDREN,
>     -pushexstyle => WS_EX_CLIENTEDGE,
>     -class       => $WC,
>     -hscroll     => 1,
>     -vscroll     => 1,
>     -onScroll    => \&Scroll,
> );
>  
> #hook into the paint event of the child window
> $ChildWin->Hook(15, \&Paint);
>  
> #Create a memory DC compatible with the child window DC
> my $memdc=$ChildWin->GetDC->CreateCompatibleDC();
> #Define global variables
> my $bitmap;        #will hold the bitmap
>  
> #show both windows and enter the Dialog phase.
> $mainwin->Show();
> $ChildWin->Show();
> Win32::GUI::Dialog();
>  

# This Paint Hook uses an outer scope reference to the $ChildWin 
variable, tying it to this specific window.  It also used a global 
$memdc, tying it to that particular bitmap.  Factoring out these two 
items would make the function more generic.  Something like

> sub Paint {

# Can $ChildWin be derived from the parameters to the hook function?

   return & PaintHelp( $ChildWin, $memdc );
}

sub PaintHelp {
>   #Paint event handler, called when ever the window needs to be 
> redrawn/painted
>   return unless $bitmap;
>   #tell windows that we are starting to paint
>   $ChildWin->BeginPaint;
>   #get the DC of the child window
>   my $dc=$ChildWin->GetDC;
>   #Performa a bit block transfer of the memory DC into the child window DC
>   #The cordinates are based upon the possition of the scroll bars
>   $dc->BitBlt(0, 0, 
> $ChildWin->Width,$ChildWin->Height,$memdc,$ChildWin->ScrollPos(0),$ChildWin->ScrollPos(1));
>   #tell windows that we have finished painting.
>   $ChildWin->EndPaint;
> }
>  

# Again, if the $ChildWin could be derived from the parameters to the 
Resize event, this function could be generic to any Scrollable window, 
it would appear.

> sub Resize {
>   #Resize handler
>   my ($width, $height) = ($mainwin->GetClientRect)[2..3];
>   $mainwin->Open->Left($width-120);
>   #Resize the child window and set the scroll bar page of each scroll bar.
>   #This has the effect of increasing/decreasing the size of the bar 
> within the scroll bar
>   #as the window is resized.
>   $ChildWin->Resize($width-150,$height);
>   $ChildWin->ScrollPage(0,$ChildWin->Width);
>   $ChildWin->ScrollPage(1,$ChildWin->Height);
> }

# Three parameters ( $ChildWin, $bitmap, $memdc )  would make this 
function generic.

> sub OpenBitmap {
>   #Function to load in the bitmap
>   my $file = Win32::GUI::GetOpenFileName(
>                    -owner => $mainwin,
>                    -hidereadonly => 0,
>                    -title  => "Open an bitmap file",
>                    -filter => ['Bitmaps' => '*.bmp',
>                                'All files'    => '*.*',
>                               ],               
>                    );
>   $bitmap=new Win32::GUI::Bitmap($file);  
>   if ($bitmap) {
>     #if we have a valid bitmap, get the dimentions
>     my ($width,$height)=$bitmap->Info();
>     #select the bitmap into the memory DC so it can be maniplated later.
>     $memdc->SelectObject($bitmap);
>     #set the scroll bar range and position based upon the height and 
> width of the bitmap.
>     $ChildWin->ScrollRange(1,0,$height+20); #add 20 for the scroll bar
>     $ChildWin->ScrollRange(0,0,$width+20);
>     $ChildWin->ScrollPage(0,$ChildWin->Width);
>     $ChildWin->ScrollPage(1,$ChildWin->Height);
>     #set the scroll bars to 0.
>     $ChildWin->ScrollPos(0,0);  
>     $ChildWin->ScrollPos(1,0);
>     $ChildWin->InvalidateRect(0); #invalidate the child window so 
> windows triggers the paint event
>   }
> }

# This function appears to be generic to any scrollable window.  Can the 
technique shown here to obtain $win be applied to obtain $ChildWin in 
some of the above functions?  (Resize?  Paint?)

> sub Scroll {
>   #Scroll event handler. We have to explicitly "move" the scroll bars.
>   #Once they have been moved, we repaint the window.
>   my($win,$scrollbar, $operation, $position) = @_;
>   if($operation == SB_THUMBTRACK) {
>     $win->ScrollPos($scrollbar,$position);
>     }
>   elsif($operation == SB_LINEDOWN) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar)+1);
>   }
>   elsif($operation == SB_LINEUP) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar)-1);
>   }
>   elsif($operation == SB_PAGEDOWN) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar) + 
> $win->ScrollPage($scrollbar));
>   }
>   elsif($operation == SB_PAGEUP) {
>     $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar) - 
> $win->ScrollPage($scrollbar));
>   }
>  #invalidate the child window so windows triggers the paint event
>  $win->InvalidateRect(0);
> }

-- 
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.