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