The basics of the implementation code is to reduce the amount of erasing and repainting being done.  Everything that is moved has to be redrawn at least once, it is changed after all.  The idea is, for each move, only do it once.  Much of the time, usually, for each move, things are erased and redrawn multiple times.

For group boxes, they don't draw their interior.  With no change to the implementation, after the resizing is done, you see big spaces in the interior of a group box where it is not the dialog color.  This is very noticeable  So, for group boxes a style is added by ooDialog that fixes that problem.  But, adding that style causes erasing and redrawing to, possibly, be done more than once.  This is most noticeable if the group box is changing in size.  It is  not very noticeable if the group box remains fixed in size.

As a developer, I can't reasonably tell people to get better hardware so that what I've programmed looks better. ;-)  Likewise, I can't  tell them to change a global Windows setting to something different than what they are using.  If there was absolutely no flickering, then that would be great.  If I do detect flickering, then it constantly bugs me, because I keep thinking: is there something I could do in the implementation that would fix that, or is that just the  best that can be done. 


I'm not sure where we are standing with this at the moment but I would prefer to have what you Mark call 'special treatment' of static controls in the same way as group boxes so that the code in my example can resize correctly, with or without flicker. As I pointed out earlier, resizing is nothing one is doing all the time so by remembering the current window size as the default for the next session, the programmer can make resizing an infrequent action. My question is: is this flickering problem something specific to ooRexx or does it apply to all Windows applications written in C++ and the like?

Staffan