Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Opinion: Who Should Move a Control
Message
 
To
16/07/1999 19:13:01
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00242574
Message ID:
00242719
Views:
24
I agree 100% with this approach. It's the only worthwhile approach as far as I am concerned.

Michel.

================== Your original message follows ==================

>>Which is the most commonly accepted method:
>>
>>I want a form/container that will resize and I want the controls within the form to respond to the resize event. My question is - what object should perform the move on the controls.
>>
>>The form has just been resized:
>>
>>1. Should the form inspect each of the objects and change their coordinates according to it's requirement.
>>
>>2. Should the form notify each of the objects that is has been resized and let the object inspect the form's requirements and change their own coordinates.
>>
>>In my opinion #1 is most effective method, but then I fairly new to OOP and this is why I am asking...
>>
>>...tim
>
>I will go ahead and disagree with everyone else. It is rare, IMO, that a form can just "know" what to do with each control. IOW, some controls should move with the bottom of the form, but not with the right side, and some should stretch with the right side and with the bottom. This means that you should be able to configure each control's behavior at design time.
>
>In my framework, all visible base class controls have a few custom properties for this. FloatWithBottom and FloatWithRight are logical properties used to determine a control's reposition behavior. Grids, pageframes, containers and editboxes, each have these properties in addition to two more: ResizeWithRight and ResizeWithBottom, that determine the control's resizing behavior. All controls have a Float method and the grids and stuff also have a Resize method. Internal properties are used to store the control's initial position and size relative to the form (DistanceToFormTop and DistanceToFormRight). These properties are set in the control's init method.
>
>The form's resize event has code that loops through all controls, first check for the presence of the behavior propreties, and then checks the value. If present and true the form calls the control's Resize and/or Float methods.
>
>Laid out this way, I can have a form with a grid on top, an editbox below that, a button on the bottom left, and a button on the bottom right. I would set the propreties at design time like:
>
>Grid.ResizeWithRight = .T.
>Grid.ResizeWithBottom = .F. (Default)
>Grid.FloatWithBottom = .F. (Default)
>Grid.FloatWithRight = .F. (Default)
>EditBox.ResizeWithRight = .T.
>EditBox.ResizeWithBottom = .T.
>EditBox.FloatWithBottom = .F. (Default)
>EditBox.FloatWithRight = .F. (Default)
>LeftButton.FloatWithBottom = .T.
>LeftButton.FloatWithRight = .F. (Default)
>RightButton.FloatWithBottom = .T.
>RightButton.FloatWithRight = .T.
>
>Now, by only changing 6 properties from default, I have a form that intelligently resizes itself, with all controls cooperating with each other.
>
>All of the generic "resize" classes I've seen are totally useless to me, because they don't give this kind of necessary flexibility.
Previous
Reply
Map
View

Click here to load this message in the networking platform