> 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)[EMAIL PROTECTED];
#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.
