Update - first off - I fixed a problem with the REFRESH method for ALL objects. This will be a (better) work-around fix in 2.0.4.

Secondly - Alex - your right - it would seem that Windows has a dozen different ways to refresh a window - and a dozen different different parameters for each way. But the krux of the problem is with the FRAME object itself ... its very unusual as far as windows control go.

I originally designed the FRAME object to have a non-transparent background. That is to say, if you placed a FRAME object over a group of OPTIONSBUTTONS that were created on the FORM, the options buttons would be hidden behind the frame. In order to create option buttons inside the frame, you had to create them as children of the frame. By the way - this is the only way that multiple optionbutton groups can be created (groups of mutually exclusive optionbuttons that is to say).

But then I saw that folks were using the FRAME object as a framing tool ... to frame controls already created on the form. So I switched back to a transparent frame ... but the thing is that there is a refresh problem when moving children on the frame now (current problem).

VBA handles this problem easily by just having a FRAME object that is non-transparent. There is no option to make it transparent. Haven't checked VB yet.

C++ (straight windows) handles this problem in a curious fashion. Frames are transparent but you can't really create multually exclusive optionbuttons that are children of the FRAME and have it work as expected. FRAMES are simply stand-alone OBJECTS that simply frame a group of controls. Early on, I was going to take this approach and decided against it

For example, in Kixtart/Kixforms parlance, if you wanted to create two FRAMES - each with two mutually exclusive option buttons, you would code this:

code:
$Form = CreateObject("Kixtart.Form")
 
 $Frame1 = $Form.Frame
 
  $Option1 = $Form.RadioButton
 
  $Option1.TabGroup = 1
 
  $Option2 = $Form.RadioButton
 
 $Frame2 = $Form.Frame
 
  $Option3 = $Form.RadioButton
 
  $Option3.TabGroup = 1
 
  $Option4 = $Form.RadioButton
Bascially what this is saying is that $Option1 and $Option3 are the "beginnings" of a set of mutually exclusive RADIOBUTTONS. Some other highlevel (COM) languages use this strategy as well (i think ACCESS VBA uses it and I've seen some others).

The big benefit of this strategy is that you can create mutliple sets of mutually exclusive RADIOBUTTONS on a form, with having to frame them inside FRAMES ... so I think that the TABGROUP property would be good to have, even without this problem.

Anyways, if anyone has any thoughts, please advise ... im going to continue to work on this ...

[ 12. September 2002, 14:20: Message edited by: Shawn ]