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. For Example control calls invalidate invalidate calls API invalidate windows updates the invalid rect for that window. windows then sends a paint when msg q is empty control asks windows for the invalid rects accumulated then paints it 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. 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. 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 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. Peter _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus