VFP subclasses and hidden members 1

chpicker

Properties and methods in a class definition are Public by default: code in other classes or procedures can set the properties or call the methods. Properties and methods that you designate as Protected can be accessed only by other methods in the class definition or in subclasses of the class. Properties and methods designated as Hidden can be accessed only by other members in the class definition. Subclasses of the class cannot "see" or reference hidden members.



Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

Subclasses of the class cannot "see" or reference hidden members.

I understand this...I am not trying to reference the hidden member from the subclass. The original class code is trying to do it and failing. It works fine as long as I don't try to override it. When I do so, I still need it to do its original function, so I call it. Shouldn't that still work? DODEFAULT() is supposed to just tell the parent class to do its thing. For some reason it doesn't think it can anymore.

Ian

Taking the rules of OOP in mind, and reading what you are trying, it should work how you have described it.

As an example (it's tested in VFP6SP5):


o = createObject('oopExtended')
? o.getData()

define class oop as custom

hidden cData
cData = "Hello"

procedure getData
return this.cData
endProc

enddefine

define class oopExtended as oop

procedure getData
? "To everyone "
return doDefault()
endProc

enddefine


When executing those statements, it will display To everyone Hello

If you can't figure it out, post some code.


Charl

Hey Charl,

Yes, that is EXACTLY what I am talking about. I get an error that, were it in your code, is the equivalent of:

Property CDATA is not found.

Now, granted it IS a bit more complex. The class that contains the hidden members is a custom control I made. It is a series of buttons (New,Edit/Save,Delete,Cancel/Exit) that is supposed to be dropped into data entry forms. This control is one of the members of my data entry form class (DATAENTRY). The error is occurring in one of my SCX files which is based on DATAENTRY. In that SCX file I override one of the functions in my custom control. Here is the code in the override:
[tt]
DODEFAULT()
IF This.getmode()=0
Thisform.GetData()
ENDIF
Thisform.Grid1.SetFocus()
[/tt]
getmode() is a Public accessor function (which is not overridden anywhere, I might add). The error actually happens twice: once during the DODEFAULT() (in the original code for my custom class, this function tries to read a hidden property) and once when it calls getmode() (which is ALSO trying to read the hidden property). BOTH of these functions are found in the same class that the hidden property is found.

As far as I could tell, and your code above confirms this, the original class functions should still be able to access the hidden member, but they are not.

In any case, thanks for the help. At least you confirmed for me that VFP is supposed to properly support the OOP visibility rules. There must be something else I've missed.

Ian

Hi Ian,

I already supposed that your situation was a little more complex (it's always mine problem to when posting something to tek-tips). And I posted the code above, so you could test if the basic code tested by someone else is working on your installed VFP environment. And it did, as I can make up out of your thread.

It's very difficult to help you out, but a few suggestions you could try.
In stead of using a form .scx, use a class library or a .prg file, so you can see what code is behind the form, maybe the strange part is happening by the add class to the form. Because described mine example above and what you are doing is something not fully OOP. (Like forms in a .scx aren't fully OOP, because they are already an object instead of a class you are sub classing.

What are you doing:

Define Class DataEntry as Control (= Define a class)

Add Object DataEntry (= Create an object from the class DataEntry)

DODEFAULT() (= overide a method of an object NOT OOP)
IF This.getmode()=0
Thisform.GetData()
ENDIF
Thisform.Grid1.SetFocus()


Following OOP rules, mine example above (mostly you will (I to) choose for the way you do it, but lets consider this option):

Define Class DataEntry as Control (= Define a class)

Define Class ExtraDataEntry as DataEntry (= subclass dataEntry, and override the method here)

DODEFAULT() (= overide a method of a class FULL OOP)
IF This.getmode()=0
Thisform.GetData()
ENDIF
Thisform.Grid1.SetFocus()

ADD OBJECT ExtraDataEntry (= define an object, and add it to your form)

I haven't tried the thoughts above, but maybe this is were VFP is messing it up, the differences between objects and class (I've seen it before, VFP messing up some "basic ideas&quot

(if you find the problem, let me know, I'm curious)

Good luck,


Charl

That's a great suggestion, Charl, and it makes perfect sense. After all, what exactly IS a VFP form? Is it an object itself already? According to OOP you shouldn't be ABLE to change the behavior of an OBJECT, only the CLASS...so if that were true, you shouldn't be able to change the properties or methods of a form.

Anyway, I will try your second suggestion sometime this week and let you know how it goes. It's a lot easier to subclass my Data Entry class and change the form to be based on that class than to turn it all into a PRG with DEFINE CLASS statements. For forms, I tend to prefer .SCX files and DO FORM rather than using CREATEOBJECT(). The only exception is when I make a dialog to gather info from the user...then it's easier to use CREATEOBJECT().

Anyway, enough rambling. Thanks again!

Ian