Menu
▾
▴
perl-win32-gui-hackers
|
From: Jez W. <je...@je...> - 2004-05-14 14:23:02
|
Hi, Would any one have any objections if I change (fix depending on your = viewpoint:) ) the BeginPaint and EndPaint functions in GUI.xs?=20 I think these functions are left over from previous versions (along with = the other painting/drawing functions in GUI.xs). They are currently not = used by any other internal functions, nor are they documented anywhere. = The general usage would stay the same, but I plan to return the details = as an array (dc,x,y,x1,x2,flag) rather than messing with the object = itself. I think this would be cleaner, faster and more like other xs = functions. In general usage these functions would be used in conjunction with a = Hooked WS_PAINT message, allowing the users program to handle the = painting of window directly. A good example, would be the bitmap = scrolling example ask for by Glenn Linderman, instead of painting the = bitmap into a image control, it could be painted direct into the windows = DC (I'll try and put together an example this weekend). Comments? Cheers, jez.=20 |
|
From: Glenn L. <pe...@ne...> - 2004-05-14 16:03:29
|
On approximately 5/14/2004 7:22 AM, came the following characters from the keyboard of Jez White: > Hi, > > Would any one have any objections if I change (fix depending on your > viewpoint:) ) the BeginPaint and EndPaint functions in GUI.xs? > > I think these functions are left over from previous versions (along with > the other painting/drawing functions in GUI.xs). They are currently not > used by any other internal functions, nor are they documented anywhere. > The general usage would stay the same, but I plan to return the details > as an array (dc,x,y,x1,x2,flag) rather than messing with the object > itself. I think this would be cleaner, faster and more like other xs > functions. > > In general usage these functions would be used in conjunction with a > Hooked WS_PAINT message, allowing the users program to handle the > painting of window directly. A good example, would be the bitmap > scrolling example ask for by Glenn Linderman, instead of painting the > bitmap into a image control, it could be painted direct into the windows > DC (I'll try and put together an example this weekend). > > Comments? I'm in favor for a several reasons, one of them selfish :) 1) I've never used them, so it won't affect me (and that's not the selfish reason) 2) From a brief look at the functions, it sounds like an improvement in clarity, and possibly speed. 3) There's a good chance the functions will get better documented as a result, so people that didn't take the time to figure them out before, may get a benefit from them with this change... (hint, hint) :) 4) If I get a nice scrolling bitmap example code, I'll be really happy, and withdraw my request for adding back the old Win32::GUI::MDI object. (Yep, this is the selfish one, but slightly altruistic as well.) -- 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. |
|
From: Jez W. <je...@je...> - 2004-05-14 16:24:38
|
> 3) There's a good chance the functions will get better documented as a > result, so people that didn't take the time to figure them out before, > may get a benefit from them with this change... (hint, hint) :) That goes without saying:) > 4) If I get a nice scrolling bitmap example code, I'll be really happy, > and withdraw my request for adding back the old Win32::GUI::MDI object. > (Yep, this is the selfish one, but slightly altruistic as well.) It can be done without these functions 'fixed' by using an graphic:) Which would you prefer, a stand alone window with scroll bars, or a window within a window with scroll bars?:) I'll try and put something together this weekend, but if you have a look at Region.pl in the samples folder, it will give a few pointer to how it would be done. Cheers. jez. |
|
From: Glenn L. <pe...@ne...> - 2004-05-14 17:25:21
|
On approximately 5/14/2004 9:25 AM, came the following characters from the keyboard of Jez White: > That goes without saying:) I'm glad that is the case, but I wanted it to be explicit, because it is a benefit. >>4) If I get a nice scrolling bitmap example code, I'll be really happy, >>and withdraw my request for adding back the old Win32::GUI::MDI object. >> (Yep, this is the selfish one, but slightly altruistic as well.) > > > It can be done without these functions 'fixed' by using an graphic:) Is there a benefit of doing it one way or the other? I was looking at some sample code last night that doesn't have scrollbars, but did scrolling by detecting mouse movements. The technique used was rather interesting.... the whole "graphic" was put into a "label", and then the position of the label was moved around in response to mouse movements. This required very little "drawing" or "painting" code, which is a benefit, in my mind. On the other hand, it would also be nice to be able to place and draw a "cursor" (other than the Windows mouse cursor) on a particular spot in the image (if that spot is currently viewable). That would either require alteration of the image, or some specific drawing/painting code. This "cursor" is under program control, it reflects the program's idea of what is selected, rather than the exact spot the where the user clicked the mouse. > Which would you prefer, a stand alone window with scroll bars, or a window > within a window with scroll bars?:) In my existing application (which doesn't need the cursor mentioned above), I have a window with the bitmap consuming most of the space, but a row of buttons at the bottom for interaction. So I think the way I would express it is "a window with scroll bars, within a window", and so I'm not sure which of your choices that applies to, probably the second. My currently-developing application needs the cursor idea, but will be displaying a whole window with scroll bars containing a bit map, but needing no other widgets. But it would work for the window to simply contain no other widgets. > I'll try and put something together this weekend, but if you have a look at > Region.pl in the samples folder, it will give a few pointer to how it would > be done. I'm looking at it, and will look at it more. When I ran it last night, I didn't realize that it was particularly relevant to bitmaps, but now in looking at the source, I'm getting more of the picture of how it might be, as you are generating bitmaps in the process. (Beat me over the head with something, and maybe I'll get the idea.) Bonus points if the scroll bars only appear when the source bitmap exceeds the size of the viewing portal :) :) But at this point, I'm willing to leave scrollbars in sight at all times, if it will get things done with significantly less complication. I notice in the Region demo that clicking on the area between the arrows and the slider doesn't change the size of the region. -- 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. |
|
From: Jez W. <je...@je...> - 2004-05-14 18:59:12
|
> Is there a benefit of doing it one way or the other? Yes - but the cases are quite specific. Using a Graphic control makes a more elegant solution, while painting direct into a window involves hooked events. Using a Graphic control is usually the best bet. However, until this afternoon I always used an Graphic control to do all my painting, but I wanted to have a "floating" tool bar appear on the image when the user moves the mouse to the top corner. To cut a long story short, I was unable to get it working by using a Graphic control because the toolbar needs to be a child of the window, not the graphic control. It also seems that painted direct into the window DC is quicker than painting into a graphic DC - although I have not done any testing to confirm this. > I was looking at some sample code last night that doesn't have > scrollbars, but did scrolling by detecting mouse movements. The > technique used was rather interesting.... the whole "graphic" was put > into a "label", and then the position of the label was moved around in > response to mouse movements. This required very little "drawing" or > "painting" code, which is a benefit, in my mind. The way I'll build the example is similar to this approach. I'll load the bitmap into memory, create a memory DC, select the bitmap into it. When the user scrolls, or resizes the window the memory DC is BitBlt into the window DC (clipping to the correct size based upon the scroll bar positions). This approach will be extremely efficient, and flicker free. > On the other hand, it would also be nice to be able to place and draw a > "cursor" (other than the Windows mouse cursor) on a particular spot in > the image (if that spot is currently viewable). That would either > require alteration of the image, or some specific drawing/painting code. There are several new methods/functions that would achieve this effect (creating an icon with a mask would be the simplest). It is all based around the same basic principles - do all your operations in a memory DC, and plot into the window DC. > In my existing application (which doesn't need the cursor mentioned > above), I have a window with the bitmap consuming most of the space, but > a row of buttons at the bottom for interaction. So I think the way I > would express it is "a window with scroll bars, within a window", and so > I'm not sure which of your choices that applies to, probably the second. This is the kind of approach I have used - although I only have either a horizontal or vertical scroll bar, not both. > I'm looking at it, and will look at it more. When I ran it last night, > I didn't realize that it was particularly relevant to bitmaps, but now > in looking at the source, I'm getting more of the picture of how it > might be, as you are generating bitmaps in the process. (Beat me over > the head with something, and maybe I'll get the idea.) The whole DC/Bitmap thing takes a while to get your head around. I used to use GD as my graphics engine, but with all the changes that Laurent added, I was able to ditch it and use windows GDI. I was surprised to find that windows was actually faster, my exe's smaller and use less memory! > Bonus points if the scroll bars only appear when the source bitmap > exceeds the size of the viewing portal :) :) But at this point, I'm > willing to leave scrollbars in sight at all times, if it will get things > done with significantly less complication. Surprisingly enough, this is automatic:) > I notice in the Region demo that clicking on the area between the arrows > and the slider doesn't change the size of the region. Arh, I probably missed handling some of the scroll events:) > -- > 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. |
|
From: Jez W. <je...@je...> - 2004-05-17 09:40:13
|
Hi,
I've been looking into this change and there is a slight problem:)
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.=20
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)=3D@_;
#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?
Cheers,
jez.
----- Original Message -----=20
From: Jez White=20
To: guihackers=20
Sent: Friday, May 14, 2004 3:22 PM
Subject: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)
Hi,
Would any one have any objections if I change (fix depending on your =
viewpoint:) ) the BeginPaint and EndPaint functions in GUI.xs?=20
I think these functions are left over from previous versions (along =
with the other painting/drawing functions in GUI.xs). They are currently =
not used by any other internal functions, nor are they documented =
anywhere. The general usage would stay the same, but I plan to return =
the details as an array (dc,x,y,x1,x2,flag) rather than messing with the =
object itself. I think this would be cleaner, faster and more like other =
xs functions.
In general usage these functions would be used in conjunction with a =
Hooked WS_PAINT message, allowing the users program to handle the =
painting of window directly. A good example, would be the bitmap =
scrolling example ask for by Glenn Linderman, instead of painting the =
bitmap into a image control, it could be painted direct into the windows =
DC (I'll try and put together an example this weekend).
Comments?
Cheers,
jez.=20
|
|
From: Glenn L. <pe...@ne...> - 2004-05-17 16:24:14
|
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.
|
|
From: Jez W. <je...@je...> - 2004-05-17 18:07:23
|
> 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)=@_;
#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.
|
|
From: Glenn L. <pe...@ne...> - 2004-05-17 20:06:40
|
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.
|
|
From: Jez W. <je...@je...> - 2004-05-18 14:47:33
|
Ok, I've done some more digging and reading of Win API (is it just me, or does internet explorer freeze now and again when looking at MS documentation?) I had assumed that the Graphic control was some sort of windows thing. It's not, its a perl thing. A graphic is simply a window, with XS code to call the paint and interactive events in perl. I must admit that other than the paint handler, I'm a bit stumped to come up with a reason why the Graphic control exits, other than in older versions of Win32::GUI normal windows did not have the events associated with an "interactive" Graphic (mousemove etc). So if a normal window had a paint handler, why use a graphic control? It also turns out there is an alternatives to using Windows BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how painting works for Graphic controls (ValidateRect is Validate in Perl speak). There are subtle differences to BeginPaint/EndPaint and ValidateRect/GetUpdateRect but I'll have to play to see what the effects are in reality. You can use the Validate method on a DC for a hooked paint event. If adding an -onPaint event is a sensible thing (I think it is) I also suggest adding the event -onEraseBkGnd (WM_ERASEBKGND). Having this event would give more control in how the background is erased (that annoying flicker on resize). My only concern is would this effect the performance of windows who do not explicitly use these events? > > 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 :) I'll try and put an example together. Cheers, jez. |
|
From: Glenn L. <pe...@ne...> - 2004-05-18 15:33:58
|
On approximately 5/18/2004 7:49 AM, came the following characters from the keyboard of Jez White: > Ok, I've done some more digging and reading of Win API (is it just me, or > does internet explorer freeze now and again when looking at MS > documentation?) > > I had assumed that the Graphic control was some sort of windows thing. It's > not, its a perl thing. A graphic is simply a window, with XS code to call > the paint and interactive events in perl. I must admit that other than the > paint handler, I'm a bit stumped to come up with a reason why the Graphic > control exits, other than in older versions of Win32::GUI normal windows did > not have the events associated with an "interactive" Graphic (mousemove > etc). So if a normal window had a paint handler, why use a graphic control? Perhaps so that it is a "widget" instead of a "window"? (In perl speak, not Windows speak.) > It also turns out there is an alternatives to using Windows > BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how > painting works for Graphic controls (ValidateRect is Validate in Perl > speak). There are subtle differences to BeginPaint/EndPaint and > ValidateRect/GetUpdateRect but I'll have to play to see what the effects are > in reality. You can use the Validate method on a DC for a hooked paint > event. Hmm. TMTOWTDI. When there is only one known way, one just attempts to solves all problems in terms of that one way. And one learns enough to do that, but maybe never comes to a true understanding of that one... one could just have "rote sequences" for doing desired things. However, once one becomes aware of a second way to do things, then one must puzzle out a deeper understanding of the original way, as well as the new way, so that one can understand and choose which way is best for which solutions. One probably learns more when TMTOWTDI. > If adding an -onPaint event is a sensible thing (I think it is) I also > suggest adding the event -onEraseBkGnd (WM_ERASEBKGND). Having this event > would give more control in how the background is erased (that annoying > flicker on resize). My only concern is would this effect the performance of > windows who do not explicitly use these events? Well, all the events come into the GUI XS event messageloop. So the more cases there are to test for, the slower all events become. I think that is why the bitmap exists... for a quick check on the likelihood that there is a Perl function to be called for this event, or not. I would think it is reasonable to bundle WM_ERASEBKGRND and WM_PAINT into the same bit of the bitmap, because they are likely to be used or disused, for the same windows (bits in the bitmap are a scarce resource) But I don't think the addition of an extra event to check for would be a significant slowdown to all windows, unless much code is added just to determine whether or not it is "this event", and that is typically done with the switch statement, and the cost of an extra case in a switch statement, while not zero, is not generally high overhead. >>>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 :) > > I'll try and put an example together. Thanks. -- 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. |
|
From: Laurent R. <ro...@cl...> - 2004-05-18 16:04:11
|
Hi,
Graphic control it's a specialized window for painting issue.
Graphic was created only for provide Paint event for user wanted to draw
specific stuff.
Paint event, it's not usefull for standard/common control (button,
listbox, ...). And, for doing owner draw control, it's not WM_PAINT event to
use but WM_DRAWITEM/NM_CUSTOMDRAW.
For me, it's not a good idea to add this event for all control.
If you really need this event for a special case, it's better to use
HookEvent.
For performance, WM_PAINT it's a frequent event so adding it to every
control can slowdown application.
But, It's a good idea to add -onEraseBkGnd event to Graphic control.
Laurent.
>
> I had assumed that the Graphic control was some sort of windows thing.
It's
> not, its a perl thing. A graphic is simply a window, with XS code to call
> the paint and interactive events in perl. I must admit that other than the
> paint handler, I'm a bit stumped to come up with a reason why the Graphic
> control exits, other than in older versions of Win32::GUI normal windows
did
> not have the events associated with an "interactive" Graphic (mousemove
> etc). So if a normal window had a paint handler, why use a graphic
control?
>
> It also turns out there is an alternatives to using Windows
> BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how
> painting works for Graphic controls (ValidateRect is Validate in Perl
> speak). There are subtle differences to BeginPaint/EndPaint and
> ValidateRect/GetUpdateRect but I'll have to play to see what the effects
are
> in reality. You can use the Validate method on a DC for a hooked paint
> event.
>
> If adding an -onPaint event is a sensible thing (I think it is) I also
> suggest adding the event -onEraseBkGnd (WM_ERASEBKGND). Having this event
> would give more control in how the background is erased (that annoying
> flicker on resize). My only concern is would this effect the performance
of
> windows who do not explicitly use these events?
>
|
|
From: Jez W. <je...@je...> - 2004-05-18 16:37:51
|
How about adding -onPaint and -onEraseBkGnd just to windows and not all controls? An alternative would be to make the Graphic control more flexible, adding scroll bar support etc. jez. ----- Original Message ----- From: "Laurent ROCHER" <ro...@cl...> To: "Jez White" <je...@je...> Cc: "guihackers" <per...@li...> Sent: Tuesday, May 18, 2004 4:55 PM Subject: Re: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint) > Hi, > > Graphic control it's a specialized window for painting issue. > Graphic was created only for provide Paint event for user wanted to draw > specific stuff. > Paint event, it's not usefull for standard/common control (button, > listbox, ...). And, for doing owner draw control, it's not WM_PAINT event to > use but WM_DRAWITEM/NM_CUSTOMDRAW. > > For me, it's not a good idea to add this event for all control. > If you really need this event for a special case, it's better to use > HookEvent. > > For performance, WM_PAINT it's a frequent event so adding it to every > control can slowdown application. > > But, It's a good idea to add -onEraseBkGnd event to Graphic control. > > Laurent. > > > > > I had assumed that the Graphic control was some sort of windows thing. > It's > > not, its a perl thing. A graphic is simply a window, with XS code to call > > the paint and interactive events in perl. I must admit that other than the > > paint handler, I'm a bit stumped to come up with a reason why the Graphic > > control exits, other than in older versions of Win32::GUI normal windows > did > > not have the events associated with an "interactive" Graphic (mousemove > > etc). So if a normal window had a paint handler, why use a graphic > control? > > > > It also turns out there is an alternatives to using Windows > > BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how > > painting works for Graphic controls (ValidateRect is Validate in Perl > > speak). There are subtle differences to BeginPaint/EndPaint and > > ValidateRect/GetUpdateRect but I'll have to play to see what the effects > are > > in reality. You can use the Validate method on a DC for a hooked paint > > event. > > > > If adding an -onPaint event is a sensible thing (I think it is) I also > > suggest adding the event -onEraseBkGnd (WM_ERASEBKGND). Having this event > > would give more control in how the background is erased (that annoying > > flicker on resize). My only concern is would this effect the performance > of > > windows who do not explicitly use these events? > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X