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

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

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

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

>>Well, sorry, but there's a second problem....  when I first run the code
>>in prints an error:
>>
>>Win32::GUI::Window::AUTOLOAD called for object
>>'Win32::GUI::Window=HASH(1a53060)', method '', AUTOLOAD=Open
> 
> 
> Well, thats stumped me! I've no idea what could be causing this - never seen
> that error before:) Does it happen all the time? I'm using the latest
> version of Win32::GUI from cvs.

Indeed it was a debug message, which I have turned off in CVS.

-- 
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] Bitmap Scolling example.

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

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

>>Well, sorry, but there's a second problem....  when I first run the code
>>in prints an error:
>>
>>Win32::GUI::Window::AUTOLOAD called for object
>>'Win32::GUI::Window=HASH(1a53060)', method '', AUTOLOAD=Open
> 
> 
> Well, thats stumped me! I've no idea what could be causing this - never seen
> that error before:) Does it happen all the time? I'm using the latest
> version of Win32::GUI from cvs.

Once each time I start the sample.

I think I'm using the latest Win32::GUI from CVS also...

I wonder if I accidentally turned on a debug message, and just committed 
that....  oops if so.

-- 
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] Added GetOpenFileName.pl sample

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

I've just added GetOpenFileName.pl sample to CVS.  It isn't fancy, but 
it demonstrates several features of GetOpenFileName and also the new 
-multisel buffer allocation feature.

-- 
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] Bitmap Scolling example.

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

> Well, sorry, but there's a second problem....  when I first run the code
> in prints an error:
>
> Win32::GUI::Window::AUTOLOAD called for object
> 'Win32::GUI::Window=HASH(1a53060)', method '', AUTOLOAD=Open

Well, thats stumped me! I've no idea what could be causing this - never seen
that error before:) Does it happen all the time? I'm using the latest
version of Win32::GUI from cvs.

Cheers,

jez.

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

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

> The problem doesn't seem to happen all the time, but does happen fairly
> often, with changed size .bmp files.  So I suspect either a timing
> problem, or an uninitialized variable.  I haven't absorbed all the code
> yet, but it looks very interesting.

Arh, I know what this is:)

It's due to the smaller size of the new bitmap, not fully painting over the
previous bitmap.

I'll have a play, and fix it before I commit it.

Cheers,

jez.

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

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

On approximately 5/17/2004 1:24 PM, came the following characters from
the keyboard of Glenn Linderman:

> On approximately 5/17/2004 2:02 AM, came the following characters from
> the keyboard of Jez White:
> 
>> Hi,
>>  
>> The code below shows an example of using a child window containing a 
>> bitmap which is scrolled using the scroll bars of the child window. 
>> The example uses a hooked paint message to pain directly to the child 
>> window via a memory DC.
>>  
>> Assuming there is no problem with this example and people think it's 
>> useful I'll commit it to the samples folder today.
> 
> 
> This looks great!
> 
> The only problem I found is 

Well, sorry, but there's a second problem....  when I first run the code 
in prints an error:

Win32::GUI::Window::AUTOLOAD called for object 
'Win32::GUI::Window=HASH(1a53060)', method '', AUTOLOAD=Open

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

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

+ [Glenn Linderman] : Fix GetOpenFileName
  - GUI.h:
    + change VERSION
  - GUI.xs:
    + change  GetOpenFileName to  support -multisel =>  N, where  N is
      multiplied  by 4000  to  obtain the  results  buffer size.   The
      minimum results buffer size is 256 for N <= 0, and 4000 for N ==
      1.

-- 
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] 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:

> Hi,
>  
> The code below shows an example of using a child window containing a 
> bitmap which is scrolled using the scroll bars of the child window. The 
> example uses a hooked paint message to pain directly to the child window 
> via a memory DC.
>  
> Assuming there is no problem with this example and people think it's 
> useful I'll commit it to the samples folder today.

This looks great!

The only problem I found is that when displaying a sequence of BMPs 
smaller than the BitMap window, the prior BMP is not cleaned to the 
background color.  So fragments on prior displayed BMPs

bug.gif was generated by displaying first trifold.bmp, and then toc.bmp.

The problem doesn't seem to happen all the time, but does happen fairly 
often, with changed size .bmp files.  So I suspect either a timing 
problem, or an uninitialized variable.  I haven't absorbed all the code 
yet, but it looks very interesting.

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

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

On approximately 5/17/2004 11:08 AM, came the following characters from
the keyboard of Jez White:
>>I was so happy to find Win32::GUI to wrap most of the Windows stuff, but
>>the bugs and deficiencies forced me to dig deeper.  I'm still no Windows
>>expert, though.  And many of the bugs and deficiencies are getting
>>cleaned up -- I'm trying to help a little in that regard, but Steve Pick
>>(he must be hiding these days, but many thanks for what he has done),
>>and Laurent Rocher, and yourself have all well surpassed my abilities to
>>  contribute.
> 
> 
> I had an off list email conversation with Steve Pick not long ago, he
> mentioned that he's busy at the moment, but will be back. I'm flattered that
> you place me in the same category as Steve and Laurent, but I'm still
> learning XS and the windows API!

Well, yes, they've probably done a bit more, but you've done more than 
me.  And I was the one doing the most talking at first :)  Maybe I talk 
better than I code!  Well, for sure regarding the Windows API.

> Does that bitmap scrolling example I emailed to the list work on your
> machine (It should do, as long as you have a newish version of  Win32::GUI)?
> Wouldn't that solve your MDI issue? 

Yes, but I hadn't seen it when I wrote the above.  I thought maybe your 
efforts had failed due to the issue in this message.  But then later I 
saw your other posting.  I found one issue, I'll reply to your posting 
with that.  But it looks great!

> 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 :)

>>So it seems that (the Windows API functions) BeginPaint/EndPaint are to
>>be called at the beginning/end of the WM_PAINT message processing.
>>-onPaint sounds like a good name for WM_PAINT message processing... and
>>it seems like there is an -onPaint event?  So I'm not sure what you are
>>asking here....

> There is an on paint event, but only for the Graphic control. The more I've
> thought about it today, it does make sense to have an -onPaint event  for
> windows too. The problem for having a generic paint handler is that Paint is
> actually fired for each control too.

Ah.  My research was too focused to notice the limits of the existing 
-onPaint.  I was just trying to figure out how it worked.  But a generic 
paint handler wouldn't be all bad, would it?  Just don't define -onPaint 
for the ones that can draw themselves?  Or am I missing another 
fundamental Windows API issue here?

>>Then the (Win32::GUI) BeginPaint/EndPaint functions are supplied so that
>>the -onPaint event can call the Windows APIs ... ??
> 
> I've no idea why or when the (Win32::GUI) BeginPaint/EndPaint were added.
> The only possible use (with the current) code line is for handling hooked
> paint events. In the past perhaps there was another use...?

Oh, so they don't work for the Graphic object -onPaint event?

>>So whereas the Windows API functions return a PAINTSTRUCT, it appears
>>that the Win32::GUI API functions return a PAINTSTRUCT_HASH (not named
>>that, of course), but corresponding?
> 
> Sort of - the hash is squirreled way, the main reason (that I can see)  is
> so that the PAINTSTRUCT can be refilled when EndPaint is called.

So maybe just return it "for real" instead of squirreling it away?  The 
Windows API exposes it, why shouldn't' Win32::GUI's (although 
transforming it might be appropriate, but seems slow... unless the 
-onPaint method needs it, why not just leave it as a Perl "packed" 
string containing the actual PAINTSTRUCT?  Whoops, OK see below.

>>So on the surface, which is all I can scratch at present, things seem to
>>be consistent with the Windows API requirements?
>>
>>So wouldn't the (Win32::GUI) BeginPaint/EndPaint properly function as:
>>
>>-onEvent => sub {
>>   ...
>>
>>   my %hash = $win->BeginPaint();
>>
>>   ... do painting ...
>>
>>   $win->EndPaint( %hash );
>>   return 1;
>>}
>>
>>If the above is the case, then I don't understand why there is a
>>problem.  If you try to explain it in terms a novice Windows programmer
>>can understand, maybe you will arrive at the solution.  I'm happy to
>>listen, and ask dumb questions.PERL
> 
> 
> To some extent, this is what happens now - except that the hash is kept
> within XS. The problem is that you want the paint event (the windows
> BeginPaint function) to return the DC and rectangle that needs to be
> repainted. If there was a generic paint event for a window, it would work
> something like this:
> 
> -onPaint => sub {
>   my ($win,$DC,$x,$y,$x1,$y1)=@_;
>   #do custom pain logic
>  return 1;
>  }
> 
> In XS, the pseudo code would be:
> 
> BeginPaint; #save the pointer
> call_perl_sub_ref; #pass in the relevant information from the pointer

If you mean # pass in the relevant information from the pointed to 
PAINTSTRUCT, then....

> EndPaint; #pass back the pointer
> 
> Does that make any sense?

Yes, that makes sense to me.

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

> I was so happy to find Win32::GUI to wrap most of the Windows stuff, but
> the bugs and deficiencies forced me to dig deeper.  I'm still no Windows
> expert, though.  And many of the bugs and deficiencies are getting
> cleaned up -- I'm trying to help a little in that regard, but Steve Pick
> (he must be hiding these days, but many thanks for what he has done),
> and Laurent Rocher, and yourself have all well surpassed my abilities to
>   contribute.

I had an off list email conversation with Steve Pick not long ago, he
mentioned that he's busy at the moment, but will be back. I'm flattered that
you place me in the same category as Steve and Laurent, but I'm still
learning XS and the windows API!

> So I'm currently in-between a rock and a hard place... I'd like to move
> my applications forward to the latest GUI so I can use "hook" functions
> to overcome menu keystroke limitations (I want to distinguish between
> upper and lower case characters if I can, and also allow function keys
> and control keys to be distinguished, if I can), but the removal of the
> Win32::GUI::MDI in the latest versions prevents that, since I'm
> currently using that for BitMap display and scrolling (and it was
> removed with no replacement functionality documented).

Does that bitmap scrolling example I emailed to the list work on your
machine (It should do, as long as you have a newish version of  Win32::GUI)?
Wouldn't that solve your MDI issue? 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.

> So it seems that (the Windows API functions) BeginPaint/EndPaint are to
> be called at the beginning/end of the WM_PAINT message processing.
> -onPaint sounds like a good name for WM_PAINT message processing... and
> it seems like there is an -onPaint event?  So I'm not sure what you are
> asking here....

There is an on paint event, but only for the Graphic control. The more I've
thought about it today, it does make sense to have an -onPaint event  for
windows too. The problem for having a generic paint handler is that Paint is
actually fired for each control too.

> Then the (Win32::GUI) BeginPaint/EndPaint functions are supplied so that
> the -onPaint event can call the Windows APIs ... ??

I've no idea why or when the (Win32::GUI) BeginPaint/EndPaint were added.
The only possible use (with the current) code line is for handling hooked
paint events. In the past perhaps there was another use...?

> So whereas the Windows API functions return a PAINTSTRUCT, it appears
> that the Win32::GUI API functions return a PAINTSTRUCT_HASH (not named
> that, of course), but corresponding?

Sort of - the hash is squirreled way, the main reason (that I can see)  is
so that the PAINTSTRUCT can be refilled when EndPaint is called.

> So on the surface, which is all I can scratch at present, things seem to
> be consistent with the Windows API requirements?
>
> So wouldn't the (Win32::GUI) BeginPaint/EndPaint properly function as:
>
> -onEvent => sub {
>    ...
>
>    my %hash = $win->BeginPaint();
>
>    ... do painting ...
>
>    $win->EndPaint( %hash );
>    return 1;
> }
>
> If the above is the case, then I don't understand why there is a
> problem.  If you try to explain it in terms a novice Windows programmer
> can understand, maybe you will arrive at the solution.  I'm happy to
> listen, and ask dumb questions.PERL

To some extent, this is what happens now - except that the hash is kept
within XS. The problem is that you want the paint event (the windows
BeginPaint function) to return the DC and rectangle that needs to be
repainted. If there was a generic paint event for a window, it would work
something like this:

-onPaint => sub {
  my ($win,$DC,$x,$y,$x1,$y1)=@_;
  #do custom pain logic
 return 1;
 }

In XS, the pseudo code would be:

BeginPaint; #save the pointer
call_perl_sub_ref; #pass in the relevant information from the pointer
EndPaint; #pass back the pointer

Does that make any sense?

Cheers,

Jez.

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

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

On approximately 5/17/2004 2:36 AM, came the following characters from
the keyboard of Jez White:
> Hi,
>  
> I've been looking into this change and there is a slight problem:)

And it sounds much too Windows-y for me to be able to comment effectively.

I was so happy to find Win32::GUI to wrap most of the Windows stuff, but 
the bugs and deficiencies forced me to dig deeper.  I'm still no Windows 
expert, though.  And many of the bugs and deficiencies are getting 
cleaned up -- I'm trying to help a little in that regard, but Steve Pick 
(he must be hiding these days, but many thanks for what he has done), 
and Laurent Rocher, and yourself have all well surpassed my abilities to 
  contribute.

So I'm currently in-between a rock and a hard place... I'd like to move 
my applications forward to the latest GUI so I can use "hook" functions 
to overcome menu keystroke limitations (I want to distinguish between 
upper and lower case characters if I can, and also allow function keys 
and control keys to be distinguished, if I can), but the removal of the 
Win32::GUI::MDI in the latest versions prevents that, since I'm 
currently using that for BitMap display and scrolling (and it was 
removed with no replacement functionality documented).

> EndPaint (windows function) needs to have passed a structure that 
> contains the same painting information that was retrieved from 
> BeginPaint (windows function). Somehow this information needs to be 
> stored  between the calls.
>  
> In the Perl world, you would do something like:
>  
> $win->BeginPaint;
> #do painting here
> $win->EndPaint;
>  
> Which means that the pointer returned from BeginPaint (or the contents 
> of the pointer) need to be stored somewhere. The current approach is 
> to create a hash and associate it with the window. The ideal way would 
> be to associate the pointer to the window - not the data.
>  
> Or perhaps an alternative approach might be more suitable? Something like:
>  
> $win->BeginPaint( \&Paint);
>  
> sub Paint {
>   my ($DC,$x,$y,$x1,$y1)=@_;
>   #do painting
> }
>  
> Where BeginPaint, is passed a reference to a sub, BeginPaint then calls 
> windows BeginPaint,  the sub ref is called, passed all the parameters, 
> then finally calls EndPaint?  But, then why not define the Paint event 
> directly (ie, -onPaint)?
>  
> Thoughts?

So it seems that (the Windows API functions) BeginPaint/EndPaint are to 
be called at the beginning/end of the WM_PAINT message processing. 
-onPaint sounds like a good name for WM_PAINT message processing... and 
it seems like there is an -onPaint event?  So I'm not sure what you are 
asking here....

Then the (Win32::GUI) BeginPaint/EndPaint functions are supplied so that 
the -onPaint event can call the Windows APIs ... ??

So whereas the Windows API functions return a PAINTSTRUCT, it appears 
that the Win32::GUI API functions return a PAINTSTRUCT_HASH (not named 
that, of course), but corresponding?

So on the surface, which is all I can scratch at present, things seem to 
be consistent with the Windows API requirements?

So wouldn't the (Win32::GUI) BeginPaint/EndPaint properly function as:

-onEvent => sub {
   ...

   my %hash = $win->BeginPaint();

   ... do painting ...

   $win->EndPaint( %hash );
   return 1;
}

If the above is the case, then I don't understand why there is a 
problem.  If you try to explain it in terms a novice Windows programmer 
can understand, maybe you will arrive at the solution.  I'm happy to 
listen, and ask dumb questions.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] GUI.xs (BeginPaint and EndPaint)

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

Hi,

I've been looking into this change and there is a slight problem:)

EndPaint (windows function) needs to have passed a structure that =
contains the same painting information that was retrieved from =
BeginPaint (windows function). Somehow this information needs to be =
stored  between the calls.=20

In the Perl world, you would do something like:

$win->BeginPaint;
#do painting here
$win->EndPaint;

Which means that the pointer returned from BeginPaint (or the contents =
of the pointer) need to be stored somewhere. The current approach is to =
create a hash and associate it with the window. The ideal way would be =
to associate the pointer to the window - not the data.

Or perhaps an alternative approach might be more suitable? Something =
like:

$win->BeginPaint( \&Paint);

sub Paint {
  my ($DC,$x,$y,$x1,$y1)=3D@_;
  #do painting
}

Where BeginPaint, is passed a reference to a sub, BeginPaint then calls =
windows BeginPaint,  the sub ref is called, passed all the parameters, =
then finally calls EndPaint?  But, then why not define the Paint event =
directly (ie, -onPaint)?

Thoughts?

Cheers,

jez.




  ----- Original Message -----=20
  From: Jez White=20
  To: guihackers=20
  Sent: Friday, May 14, 2004 3:22 PM
  Subject: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)


  Hi,

  Would any one have any objections if I change (fix depending on your =
viewpoint:) ) the BeginPaint and EndPaint functions in GUI.xs?=20

  I think these functions are left over from previous versions (along =
with the other painting/drawing functions in GUI.xs). They are currently =
not used by any other internal functions, nor are they documented =
anywhere. The general usage would stay the same, but I plan to return =
the details as an array (dc,x,y,x1,x2,flag) rather than messing with the =
object itself. I think this would be cleaner, faster and more like other =
xs functions.

  In general usage these functions would be used in conjunction with a =
Hooked WS_PAINT message, allowing the users program to handle the =
painting of window directly. A good example, would be the bitmap =
scrolling example ask for by Glenn Linderman, instead of painting the =
bitmap into a image control, it could be painted direct into the windows =
DC (I'll try and put together an example this weekend).

  Comments?

  Cheers,

  jez.=20

Re: [perl-win32-gui-hackers] GetOpenFileName enhancement

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

> Yes, this 4096 is allocated only when the function is called.
> 
> It's automatically reserve space on stack. (it's only one assembler
> instruction).
> When you use malloc you call to OS for reserve memory space in HEAP.
> It's a longer than reserve space on stack.


Thanks for the explanation - makes sense.

Cheers,

jez.

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

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

Hi,

The code below shows an example of using a child window containing a =
bitmap which is scrolled using the scroll bars of the child window. The =
example uses a hooked paint message to pain directly to the child window =
via a memory DC.=20

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

Cheers,

jez.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#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
my $WC =3D new Win32::GUI::Class(
    -name =3D> "NoFlicker",=20
    -style =3D> 0,
);

#Create the window and child controls.
my $mainwin =3D new Win32::GUI::Window (
    -pos         =3D> [100, 100],
    -size        =3D> [330, 235],
    -name        =3D> "Window",
    -text        =3D> "Bitmap Scroll demo",
    -pushstyle   =3D> WS_CLIPCHILDREN,
    -class       =3D> $WC,
    #NEM Events for this window
    -onResize    =3D> \&Resize,
    -onTerminate =3D> sub {return -1;}
);

$mainwin->AddButton (
    -name        =3D> 'Open',
    -pos         =3D> [205, 20],
    -size        =3D> [110, 20],
    -text        =3D> 'Open Bitmap',
    -onClick     =3D> \&OpenBitmap,
);

#Create a child window with a scroll bars.=20
my $ChildWin =3D new Win32::GUI::Window (
    -parent      =3D> $mainwin,
    -name        =3D> "ChildWin",
    -pos         =3D> [0, 0],
    -size        =3D> [200, 200],
    -popstyle    =3D> WS_CAPTION | WS_SIZEBOX,
    -pushstyle   =3D> WS_CHILD | WS_CLIPCHILDREN,
    -pushexstyle =3D> WS_EX_CLIENTEDGE,
    -class       =3D> $WC,
    -hscroll     =3D> 1,
    -vscroll     =3D> 1,
    -onScroll    =3D> \&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=3D$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();

sub Paint {
  #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=3D$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),$ChildW=
in->ScrollPos(1));
  #tell windows that we have finished painting.
  $ChildWin->EndPaint;
}


sub Resize {
  #Resize handler
  my ($width, $height) =3D ($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);
}

sub OpenBitmap {
  #Function to load in the bitmap
  my $file =3D Win32::GUI::GetOpenFileName(
                   -owner =3D> $mainwin,
                   -hidereadonly =3D> 0,
                   -title  =3D> "Open an bitmap file",
                   -filter =3D> ['Bitmaps' =3D> '*.bmp',
                               'All files'    =3D> '*.*',
                              ],               =20
                   );
  $bitmap=3Dnew Win32::GUI::Bitmap($file);  =20
  if ($bitmap) {
    #if we have a valid bitmap, get the dimentions
    my ($width,$height)=3D$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);  =20
    $ChildWin->ScrollPos(1,0);
    $ChildWin->InvalidateRect(0); #invalidate the child window so =
windows triggers the paint event
  }
}

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) =3D @_;
  if($operation =3D=3D SB_THUMBTRACK) {
    $win->ScrollPos($scrollbar,$position);
    }
  elsif($operation =3D=3D SB_LINEDOWN) {
    $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar)+1);
  }
  elsif($operation =3D=3D SB_LINEUP) {
    $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar)-1);
  }
  elsif($operation =3D=3D SB_PAGEDOWN) {
    $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar) + =
$win->ScrollPage($scrollbar));
  }
  elsif($operation =3D=3D SB_PAGEUP) {
    $win->ScrollPos($scrollbar,$win->ScrollPos($scrollbar) - =
$win->ScrollPage($scrollbar));
  }
 #invalidate the child window so windows triggers the paint event
 $win->InvalidateRect(0);
}

Re: [perl-win32-gui-hackers] GUI samples

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

On approximately 5/14/2004 11:17 AM, came the following characters from
the keyboard of Laurent ROCHER:

>>More complex sample program ideas:
>>
>>Program like Notepad using Win32::GUI
>>Program like Paint using Win32::GUI
>>Calculator program using Win32::GUI
> 
> I have started a notepad clone in Win32::GUI. I add it when finished ;o)

Excellant!  If everyone does a little.... lots can get done.  Thanks.

And an extra, special thanks, for all your continuing work on 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] GetOpenFileName enhancement

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

On approximately 5/14/2004 12:43 PM, came the following characters from
the keyboard of Laurent ROCHER:
> 
>>>I think it's not a problem to upgrade default stack buffer to 4096 by
>>>default.
>>>Stack allocation is generally same speed for 256 and 4096.
>>>And only dynamicly allocate a buffer when desired size isn't enough.

If performance were critical, or ever important, for this routine, I 
would agree.  I agree anyway, but there is one other consideration....

> In this case (in GetOpenFilename context) speed difference it's not a
> problem (Need to wait user interact with dialog). Do, it's possible to
> always use safemalloc. 

The problem is that there are several exit points to the function, and 
each of them needs to do the buffer cleanup.  So making a more complex 
technique, of having a static buffer, and allocating a dynamic one only 
when the static one isn't big enough, makes the buffer cleanup routine 
quite a bit bigger, and it has to be duplicated several times, or else 
the several exit points merged into one.  Neither of those seem 
appealing, since performance isn't particularly important here.

-- 
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] GetOpenFileName enhancement

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

>
> > I think it's not a problem to upgrade default stack buffer to 4096 by
> > default.
> > Stack allocation is generally same speed for 256 and 4096.
> > And only dynamicly allocate a buffer when desired size isn't enough.
> > Something like that :
> > void
> > GetOpenFileName(...)
> > PPCODE:
> >     ...
> >     char filename[4096];
> >
>
> Quick question - are you saying that this 4096 is allocated only when the
> function is called? Or would it be allocated all the time? If it's the
> later, why not always dynamically allocate the memory? Does it come down
to
> memory use VS. speed?

Yes, this 4096 is allocated only when the function is called.

It's automaticly reserve space on stack. (it's only one assembler
instruction).
When you use malloc you call to OS for reserve memory space in HEAP.
It's a longer than reserve space on stack.

In this case (in GetOpenFilename context) speed difference it's not a
problem (Need to wait user interact with dialog). Do, it's possible to
always use safemalloc. But, for some high frequency called function, it's
better to avoid safemalloc for fixed small size buffer.

I arbitrary set 4096 so it's probably enough in much case when using
multisel (probably more than 100 files).

Laurent

Re: [perl-win32-gui-hackers] GetOpenFileName enhancement

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

> I think it's not a problem to upgrade default stack buffer to 4096 by
> default.
> Stack allocation is generally same speed for 256 and 4096.
> And only dynamicly allocate a buffer when desired size isn't enough.
> Something like that :
> void
> GetOpenFileName(...)
> PPCODE:
>     ...
>     char filename[4096];
>

Quick question - are you saying that this 4096 is allocated only when the
function is called? Or would it be allocated all the time? If it's the
later, why not always dynamically allocate the memory? Does it come down to
memory use VS. speed?

cheers,

jez.

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

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

> Is there a benefit of doing it one way or the other?

Yes - but the cases are quite specific. Using a Graphic control makes a more
elegant solution, while painting direct into a window involves hooked
events. Using a Graphic control is usually the best bet. However, until this
afternoon I always used an Graphic control to do all my painting, but I
wanted to have a "floating" tool bar appear on the image when the user moves
the mouse to the top corner. To cut a long story short, I was unable to get
it working by using a Graphic control because the toolbar needs to be a
child of the window, not the graphic control. It also seems that painted
direct into the window DC is quicker than painting into a graphic DC -
although I have not done any testing to confirm this.

> I was looking at some sample code last night that doesn't have
> scrollbars, but did scrolling by detecting mouse movements.  The
> technique used was rather interesting.... the whole "graphic" was put
> into a "label", and then the position of the label was moved around in
> response to mouse movements.  This required very little "drawing" or
> "painting" code, which is a benefit, in my mind.

The way I'll build the example is similar to this approach. I'll load the
bitmap into memory, create a memory DC, select the bitmap into it. When the
user scrolls, or resizes the window the memory DC is BitBlt into the window
DC (clipping to the correct size based upon the scroll bar positions). This
approach will be extremely efficient, and flicker free.

> On the other hand, it would also be nice to be able to place and draw a
> "cursor" (other than the Windows mouse cursor) on a particular spot in
> the image (if that spot is currently viewable).  That would either
> require alteration of the image, or some specific drawing/painting code.

There are several new methods/functions that would achieve this effect
(creating an icon with a mask would be the simplest). It is all based around
the same basic principles -  do all your operations in a memory DC, and plot
into the window DC.

> In my existing application (which doesn't need the cursor mentioned
> above), I have a window with the bitmap consuming most of the space, but
> a row of buttons at the bottom for interaction.  So I think the way I
> would express it is "a window with scroll bars, within a window", and so
> I'm not sure which of your choices that applies to, probably the second.

This is the kind of approach I have used - although I only have either a
horizontal or vertical scroll bar, not both.

> I'm looking at it, and will look at it more.  When I ran it last night,
> I didn't realize that it was particularly relevant to bitmaps, but now
> in looking at the source, I'm getting more of the picture of how it
> might be, as you are generating bitmaps in the process.  (Beat me over
> the head with something, and maybe I'll get the idea.)

The whole DC/Bitmap thing takes a while to get your head around. I used to
use GD as my graphics engine, but with all the changes that Laurent added, I
was able to ditch it and use windows GDI. I was surprised to find that
windows was actually faster, my exe's smaller and use less memory!

> Bonus points if the scroll bars only appear when the source bitmap
> exceeds the size of the viewing portal :) :)  But at this point, I'm
> willing to leave scrollbars in sight at all times, if it will get things
> done with significantly less complication.

Surprisingly enough, this is automatic:)

> I notice in the Region demo that clicking on the area between the arrows
> and the slider doesn't change the size of the region.

Arh, I probably missed handling some of the scroll events:)


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

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

> 
> More complex sample program ideas:
> 
> Program like Notepad using Win32::GUI
> Program like Paint using Win32::GUI
> Calculator program using Win32::GUI
> 

I have started a notepad clone in Win32::GUI. I add it when finished ;o)

Laurent.

Re: [perl-win32-gui-hackers] GetOpenFileName enhancement

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

>
> So then I think your point, translated to implementation requirements,
> would be to:
>
> 1) Use a 256 byte buffer for -multisel => 0  (why waste memory)
> 2) Use a 4000 byte buffer for -multisel => 1  (allow more files to be
> selected normally, even if the user hasn't caught on to doing memory
> management)
> 3) For simplicity, and smaller numbers, one could just multiply
> -multisel by 4000 with a minimum of 256 bytes for the zero case, and
> achieve all these goals.  And a 4000 byte granularity on allocation of
> the buffer is probably not a big deal for people that need big buffers.
>
> I've made these adjustments.  I'll hold off committing them until next
> week, in case there are other comments.
>

I think it's not a problem to upgrade default stack buffer to 4096 by
default.
Stack allocation is generally same speed for 256 and 4096.
And only dynamicly allocate a buffer when desired size isn't enough.
Something like that :

void
GetOpenFileName(...)
PPCODE:
    ...
    char filename[4096];

    ...
    filename[0] = '\0';
    ofn.lpstrFile = filename;
    ofn.nMaxFile = 4096;
    ...

            } else if(strcmp(option, "-multisel") == 0) {
                next_i = i + 1;
                SwitchBit(ofn.Flags, OFN_ALLOWMULTISELECT,
SvIV(ST(next_i)));
                if ( ofn.nMaxFile < (MAX_PATH * SvIV(ST(next_i))) ) {
                    ofn.nMaxFile = MAX_PATH * SvIV(ST(next_i));
                    ofn.lpstrFile = (char *) safemalloc(ofn.nMaxFile);
                    ofn.lpstrFile[0] = '\0';
                }
            }

    ...

   if(retval) {
      if (ofn.Flags & OFN_ALLOWMULTISELECT) {
        ...

         if (ofn.lpstrFile != filename)
            safefree(ofn.lpstrFile);

         XSRETURN(i);
        ...

Laurent.

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

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

On approximately 5/14/2004 9:25 AM, came the following characters from
the keyboard of Jez White:

> That goes without saying:)

I'm glad that is the case, but I wanted it to be explicit, because it is 
a benefit.

>>4) If I get a nice scrolling bitmap example code, I'll be really happy,
>>and withdraw my request for adding back the old Win32::GUI::MDI object.
>>  (Yep, this is the selfish one, but slightly altruistic as well.)
> 
> 
> It can be done without these functions 'fixed' by using an graphic:)

Is there a benefit of doing it one way or the other?

I was looking at some sample code last night that doesn't have 
scrollbars, but did scrolling by detecting mouse movements.  The 
technique used was rather interesting.... the whole "graphic" was put 
into a "label", and then the position of the label was moved around in 
response to mouse movements.  This required very little "drawing" or 
"painting" code, which is a benefit, in my mind.

On the other hand, it would also be nice to be able to place and draw a 
"cursor" (other than the Windows mouse cursor) on a particular spot in 
the image (if that spot is currently viewable).  That would either 
require alteration of the image, or some specific drawing/painting code.

This "cursor" is under program control, it reflects the program's idea 
of what is selected, rather than the exact spot the where the user 
clicked the mouse.

> Which would you prefer, a stand alone window with scroll bars, or a window
> within a window with scroll bars?:)

In my existing application (which doesn't need the cursor mentioned 
above), I have a window with the bitmap consuming most of the space, but 
a row of buttons at the bottom for interaction.  So I think the way I 
would express it is "a window with scroll bars, within a window", and so 
I'm not sure which of your choices that applies to, probably the second.

My currently-developing application needs the cursor idea, but will be 
displaying a whole window with scroll bars containing a bit map, but 
needing no other widgets.  But it would work for the window to simply 
contain no other widgets.

> I'll try and put something together this weekend, but if you have a look at
> Region.pl in the samples folder, it will give a few pointer to how it would
> be done.

I'm looking at it, and will look at it more.  When I ran it last night, 
I didn't realize that it was particularly relevant to bitmaps, but now 
in looking at the source, I'm getting more of the picture of how it 
might be, as you are generating bitmaps in the process.  (Beat me over 
the head with something, and maybe I'll get the idea.)

Bonus points if the scroll bars only appear when the source bitmap 
exceeds the size of the viewing portal :) :)  But at this point, I'm 
willing to leave scrollbars in sight at all times, if it will get things 
done with significantly less complication.

I notice in the Region demo that clicking on the area between the arrows 
and the slider doesn't change the size of the region.

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

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

On approximately 5/14/2004 9:19 AM, came the following characters from
the keyboard of Jez White:

>>Well, when I compare what I have in my old build area (downloaded
>>snapshot) to what I now see via CVS, they appear to be not there.  It is
>>not clear to me where they would then be added from, or what technique
>>of "not there" was used other than deletion :)
> 
> 
> Humm. I'm wrong then. I was under the assumption that the examples CVS
> folder was a relatively new addition:)

Maybe the confusion stems from what was in the "release" distribution or 
PPM, vs what was in the source distribution.  It has been my thought 
that the tutorials and samples should have historically been part of the 
release distribution, but they weren't... they were part of the source 
distribution.

>>>Many previous examples (even the one's that work) use none
>>>standard coding, which just cause confusion - for me anyway:)
>>
>>I certainly have no objection to samples being modified to use standard
>>coding, but I'm not sure what non-standard coding was used that was
>>confusing.
> 
> Many of the smaller examples are ok, but the larger examples use code that
> hacks into the internals (typically for functionality that now exists in
> base code). A smaller problem is that all of the old examples use OEM.

Yes, OEM was pervasive!  It was all there was!  I think it is still OK 
to have OEM samples, but maybe they should be clearly marked OEM 
samples, and perhaps a nice new sample that shows how to convert from 
OEM to NEM would be nice.

>>If there isn't time to update the sample to use better coding, one could
>>add some comments to it (no risk in adding comments) describing the
>>non-standard-ness of the coding, but leaving the sample for whatever
>>educational value it might have.  ???  I learned a good bit of GUI
>>coding from those old samples, although I agree that I got a bit
>>confused by some of them, also.
> 
> Good idea. I guess it's more of a question to who will do it?:) I don't mind
> doing a few, but perhaps someone should "own" the task and divide it out to
> those who are willing?

Yeah, "Where are the warm bodies?" is always a problem.  Like you, I 
wouldn't mind doing a few, especially when I write some test code to 
learn how something works... a few extra lines of documentation, and 
presto, a new sample.  But it is always hard to find time to go back and 
fix the old stuff...

I will rework my test code for GetOpenFileName and contribute it for a 
sample.  As I find minutes, I will try to address some of old ones.  But 
  I'm about to be on vacation for a couple weeks.

> I like the idea of having simple examples for all
> controls/core functionality, (say treeview1.pl, treeview2.pl, listview1.pl
> etc), as well as more complete applications, such as win32::gui notepad,
> paint, calculator etc. Again it would take someone to own, organise and dish
> out the tasks.

Maybe a start would be to put the following content as a file 
(readme.txt ?) in the samples directory:

Goals:

This file is meant to inspire contributions to the sample programs 
collection in this directory.  Below is a list of sample code that 
someone would like to see, or feels that it would have been helpful to 
the process of learning Win32::GUI.

If you find yourself writing small programs to figure out how something 
works in Win32::GUI, consider spending a few extra minutes adding some 
comments, and contributing it as a sample program, so that it will be 
easier for the next person to figure out the details of how to do what 
you are learning.

Organization:

This directory is a great place to put single file sample programs. 
Pick a name different from other names, of course.

For samples that require a small number of auxiliary files, if you can 
name the files with a common prefix, so that the are all sorted together 
by directory listings, then they can also go in this directory.

If there are quite a files, or the names cannot be grouped, then create 
a new subdirectory to contain all the files of the sample.


Desired sample programs:

Treeview
.
.
.

More complex sample program ideas:

Program like Notepad using Win32::GUI
Program like Paint using Win32::GUI
Calculator program using 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] GetOpenFileName enhancement

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

On approximately 5/14/2004 9:12 AM, came the following characters from
the keyboard of Johan Lindstrom:

> Hehe :)
> 
> My point is that the module should hide the memory management junk from me.
> 
> If I use the module, I want the user to select files, I don't want to 
> allocate memory. I don't want to have to care about that. So the default 
> behaviour should work for most people, most of the time. No surprises. 
> The performance overhead in this case can obviously be ignored.
> 
> The default behaviour should be overridable for those moments where the 
> default buffer is too small or too large. But that's a bonus.

Thanks for the clarification.  (Isn't it amazing how many ways things 
can be interpreted?)

So then I think your point, translated to implementation requirements, 
would be to:

1) Use a 256 byte buffer for -multisel => 0  (why waste memory)
2) Use a 4000 byte buffer for -multisel => 1  (allow more files to be 
selected normally, even if the user hasn't caught on to doing memory 
management)
3) For simplicity, and smaller numbers, one could just multiply 
-multisel by 4000 with a minimum of 256 bytes for the zero case, and 
achieve all these goals.  And a 4000 byte granularity on allocation of 
the buffer is probably not a big deal for people that need big buffers.

I've made these adjustments.  I'll hold off committing them until next 
week, in case there are other comments.

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

> 3) There's a good chance the functions will get better documented as a
> result, so people that didn't take the time to figure them out before,
> may get a benefit from them with this change... (hint, hint)  :)

That goes without saying:)

> 4) If I get a nice scrolling bitmap example code, I'll be really happy,
> and withdraw my request for adding back the old Win32::GUI::MDI object.
>   (Yep, this is the selfish one, but slightly altruistic as well.)

It can be done without these functions 'fixed' by using an graphic:)

Which would you prefer, a stand alone window with scroll bars, or a window
within a window with scroll bars?:)
I'll try and put something together this weekend, but if you have a look at
Region.pl in the samples folder, it will give a few pointer to how it would
be done.

Cheers.

jez.