Hi Evan,
You're right that this might solve this particular problem (althogh it fails to take into account that there might be a Visible_Assign() method, either now or in the future).

But it doesn't solve the main problem, that is that the FFC has code in it's methods that I don't want.

A harder example: the _Resizable.LoopThroughControls() has a [#define BASE_CLASS "Commandbutton Combobox Checkbox Listbox ....."] line in it that does not include Container in the list of controls that it will resize. It also doesn't drill down into the controls inside a container. I can't conceive of trying to spend the time to try and keep using the _Resizable.LoopThroughControls() method. I just had to re-write it, but I might still want to include the code in _Resizable's parent.


>Bill,
>
>Try this in the NavigateTo() method of your subclass:
>
>*-- Prevent the current form from displaying changes
>_SCREEN.ActiveForm.LockScreen = .T.
>
>*-- Perform the default behavior
>DODEFAULT()
>
>*-- Make the control invisible
>*-- NOTE: You could just as easily assign this
>*-- from a property of the subclass,
>*-- using a syntax something like the following:
>*-- THIS.Visible = THIS.ilVisibleOnNavigate
>THIS.Visible = .f.
>
>*-- Allow the current form to display any changes
>_SCREEN.ActiveForm.LockScreen = .f.
>
>I believe this will address the issue of "screen blink" to which you're referring.
>
>
>
>>Hi Evan,
>>
>>>but wouldn't it work to:
>>>A) subclass the FFC class
>>>B) In the method you want to change, issue a DODEFAULT()
>>>C) In the *same* method, follow the DODEFAULT() with the code you want (there's no rule that says you can't execute code that changes or mucks with the default behavior you just executed)
>>>
>>I've already found 2 FFC methods that only need one line changed. I don't want the original line to execute at all.
>>
>>In _HyperlinkBase.NavigateTo() they have ...Visible=.T.. Sometimes I want it to be invisible. If I execute the method() as is and then put ...Visislbe=.F., there is a flash on the user's screen.
>>
>>
>>>Hi Bill,
>>>
>>>Maybe I'm missing something here...
>>>
>>>but wouldn't it work to:
>>>A) subclass the FFC class
>>>B) In the method you want to change, issue a DODEFAULT()
>>>C) In the *same* method, follow the DODEFAULT() with the code you want (there's no rule that says you can't execute code that changes or mucks with the default behavior you just executed)
>>>
>>>IMHO, this would allow updates to the FFC behavior while keeping your desired subclass behaviors intact. You might need to revisit these subclasses and adjust THEIR behavior if the FFC changes significantly between versions, and those changes mess up your custom behavior -- big deal. That's what, once a year or so? Any changes to the FFC would (most likely) be well documented in the "What's New" section of the version's help file. Besides, you can document those changes in YOUR subclasses as well, thereby providing an audit trail.
>>>
>>>HTH...
>>>
>>>>I'm using VFP 7.0
>>>>
>>>>I'm creating an app using VFP's Foundation Classes.
>>>>I would like to keep the app in a condition to received any MS updates to the FFC.
>>>>
>>>>When I find an FFC method() that doesn't work the way I want (example: _HyperlinkBase.NavigateTo sets .Visible=.T., I want to leave it invisible sometimes).
>>>>How can I change the behavior and still leave the app capable of receiving updates to the _HyperlinkBase class?
>>>>
>>>>If I modify the class directly, the update wipes out my changes.
>>>>If I re-write the method (no dodefault()) in my sub-class then the update is skipped.
>>>>
>>>>I'm guessing that the only solution is to document all my changes to the FFC and implement any updates manually. Is there a program out there that will simplify that process?
>>>>
>>>>Do I have any other choice?
>>>>
>>>>TIA