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.