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.