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