Well - im just green-lighting here but personally, I think your right on - we SHOULD be creating objects as the CHILDREN of SOMETHING. Whether that something should be a FRAME object or a new GROUPBOX object is open for debate. If we did decide go with a GROUPBOX object - it would be totally 100% compatible with the FRAME object - one would just have to replace the string FRAME with GROUPBOX in ones script. Only thing is - it wouldn't be TRANSPARENT.

But I guess we shouldn't lose site of one thing - this "bug" only appears when one dynamically creates or moves a control within a FRAME object - and only after the form has been realized. I don't think that this bug would appear in usual everyday usage. One doesn't see too many Windows apps with buttons and textboxes flying around all over the place. Plus - the fixed REFRESH method on the FORM object should work to mitigate this problem.

But it just bugs me that this problem is there - know what I mean ?

So yeah - I have no plans to obsolete the FRAME object ... in fact, when I want grouped controls ... I structure and host them in FRAMES just like you. When the FRAME moves, I want the controls to go with them. But at the same time, we have folks that use FRAMES in a different way - just for visual effect.

We (i) have to think more on how we can deal with this situation. All the green-lighting aside - think my preference is to just leave things as they are right now ... put out 2.0.4 with fixed refresh ... and continue to work on making the FRAME a more intelligent flexible control ... one idea is to add a new property that will set the FRAME background to TRANSPARENT or OPAQUE ... this wouldn't fix the problem - it would just hide it because a transparent FRAME would still behave in this fashion. But it would buy some time until the SMART FRAME was developed.

[ 12. September 2002, 18:36: Message edited by: Shawn ]