Well, I will give some background in terms of what the problem is. The problem is that I'm trying to support two different ways of showing child controls in a frame.

1) Some folks create controls that are children of the form, then use a frame to visually group the controls. In this case, the frame must be totally transparent so that the child controls can be seen. If the frame is moved, the child controls do not move with. Plus, RadioButtons that are grouped this way are not mutually exclusive by default.

2) Other folks create controls that are children for the frame. In this scenario, the frame doesn't have to be transparent and if the frame is moved, the child controls move with it. RadioButons grouped in this fashion are mutually exclusive by default.

The second option is actually the one I had in mind for proper usage of a frame. If you actually look at VB .FRM statements, child controls "appear" to be children of the frame, and not the form. They seem to be created in a nested fashion.

So what I did, when I created Kixforms v2, was to make the frame non-transparent. The refreshing issue as we see it now, was not a problem. Plus, one could actually set the BackColor of a frame if one wanted. But - when I went back over some legacy scripts that I had - found some scripts that did things "the other way" and the frame hid all the controls underneath.

So caught between a rock and a hard-place right now. Its important to realize that BOTH methods are correct. For example in regular C++ dialogs, the child controls placed in a frame are not children of the frame, they are owned by the dialogbox itself. The frame is just used for visual grouping. The difference is that one doesn't noramally see controls appear and vanish on the fly - plus, C++ dialogs are statically declared and built before they are shown - with Kixforms and Kixtart scripting - the controls are built on the fly - thus we sometimes see them move and flash in certain circumstances. Thats why we usually defer showing the form until just before the DoEvents loop - to keep things hidden until the form is fully rendered.

To change the FRAME behavior this late in the game might be a mistake. The other option you might want to explore is to use the PictureBox object - which can also act as a container. To be honest - the PictureBox object is a FORM ... diff being that its owned by the parent form - its really a borderless sub-form. It has a persistent bitmap background just like a regular form, and can host child controls.

The next best option is to explore a new type of container control - which I've already started to do. dotnet has an object called a "PANE" with behave very much like a frame (its the dotnet version of a frame - its also called a GROUPBOX in some other circles) - the discussion will really center around whether this new control wil REQUIRE that the contained controls be created as children of the pane. My take is that this should be a requirement.

[ 06. November 2002, 16:43: Message edited by: Shawn ]