Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Option group blues...
Message
From
30/08/2000 17:37:18
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00410538
Message ID:
00411056
Views:
34
>Hi Craig,
>
>>Create a subclass with several buttons, say 6 or 8. Then do a REMOVEOBJECT() in the OptionGroup.Init for those you don't want. Each individual button can be customized in the class…
>
>I do manipulate the option group objects programmatically - ex: we have a SetOrder utility that walks trough the tags and customizes an option group accordingly.
>Are you advising to do that at the class level? Create a subclass with 8 buttons and the remove some of them in the Init – what for??

I'm taking the opposite approach. What I'm saying is to take the option group class and give it more buttons that you need. It could be 5, 6, or 8. IMO, any more than that and you should use a combo or list. In the class, customize each button with the desired behavior and attributes. Add a custom property called nButtonCount. Then in the Init, you can do:


LOCAL lnCounter, lcButton
WITH This
FOR lnCounter = .nButtonCount + 1 TO .ButtonCount
lcButton = "Option" + ALLTRIM(STR(lnCounter)
.RemoveObject(lcButton)
ENDFOR
ENDWITH


In the class instance, set nButtonCount to the number of buttons you want to have visible. It's a bit of a pain at design time because all the buttons are showing, but it does allow you to customize the buttons.

>What I wanted was my own option group visual class (myOpg - subclassed from the VFP optiongroup base class) “populated” with my own option buttons (myOpb - subclassed from the VFP optionbutton base class). When I increase the ButtonCount, I’d like that the added buttons to be of myOpb class (so that they’ll inherit, for instance, the autosize property setting of myOpb). Is this possible?
>
>
>>… You can't rename the buttons because they are members of the class.
>
>OK, I learned that, and it probably should be that way…
>It’s probably connected with another weird thing:
>I changed some label names in our myBaseForm class
>
>Example: label named Label1 changed to lblFormTitle. The caption says “Form Title”.
>
>What happened, was that on all existing forms, the labels that I’ve changed the name, lost their caption!!! Modifying the forms would show the new name for the labels (lblFormTitle), but the caption went back from let’s say “Maintenance” to “Form Title” - the value set in myBaseForm. I’ve opened the .scx, and in the properties memo there still was the old name Label1 and caption “Maintenance”. I wrote a little program that walked through all .scx files and replaced all occurrences of the old names (Label1) with the new names (lblFormTitle), and that fixed it… The “fix” works only if applied before modifying & saving the forms.
>
>So, the name property has a special regime:
>- you can only change it in the class, not in subclasses, nor in instances.
>- if you change it in the class, all properties set in the existing instances are lost.
>Am I wrong?
>
>
>I guess you didn’t experience the behavior I described in Q3?
>
>dz
>
>PS Sorry for the long post...
Craig Berntson
MCSD, Microsoft .Net MVP, Grape City Community Influencer
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform