I have been studying the message paths and calls made by the InvalidateRect Update Paint…
+ From: Peter Dyson
+ I have been studying the message paths and calls made by the
+ InvalidateRect Update Paint et al. There seems to be an awful
+ lot of message passing which can be got rid of if we have to
+ encapsulate the windows behaviour.
+
[snip]
+ Now if TWinControl handles its own invalid regions
+ thats one less msg to spew out, we will still have to
+ get an invalid rect from the window manager as only
+ it knows about other windows affecting this one.
Hmm... you may win one message.... I don't think it's worth it. You now have to handle regions at two places.
+ Child controls should get handled in much the same
+ way as now, this is only required for the few instances
+ where large drawing areas are used.
Hmm.... have thought about how the InvalidateRect API call should be handled this way? (The api doesn't know LCL)
+ Also when the control calls class method update to
+ force a refresh, the API call UpdateWindow is called
+ along with windows posting a wm paint message back.
+ No gain if you want to force another window but one
+ nested API call and one deep msg q in less if the
+ TWinControl can call its own paint method without
+ going through all that.
???? Can you explain
+ Can anyone see any disadvantages in TWinControl
+ maintaining its own invalid rect and internal painting.
+ It would not affect the public interface of the class
+ and would encapuslate a part of the WinAPI within
+ the class heirachy, which certainly makes it different
+ to Delphi while still compatible.
I say OK as long as you have a way to handle the API functions: InvalidateRect
InvalidateRgn
UpdateWindow
ValidateRect
ValidateRgn
But I cant see how you would manage this platform (and if possible LCL) independent, so I have my doubts.
I think you'll end up with lot of the same work.
Marc