We’ll create a sample project to demonstrate why its a bad thing to do.<\/p>\n\n\n\n
Start a new desktop project.<\/p>\n\n\n\n
Add a new Class that is a subclass of \u201dCancelButton\u201d by dragging a CancelButton from the library to the Navigator.<\/p>\n\n\n\n
Name this new class \u201cmyPushButton\u201d<\/p>\n\n\n\n
Add a property to it – enabled as boolean<\/p>\n\n\n\n
Make sure the property is public<\/p>\n\n\n\n
Now on Window1 add an instance of this new button subclass.<\/p>\n\n\n\n
Name it \u201cMyPb\u201d<\/p>\n\n\n\n
Now add a bevel button and name it bevTestSubclass.<\/p>\n\n\n\n
Change its Caption to say \u201cbevTestSubclass\u201d<\/p>\n\n\n\n
In its action event put<\/p>\n\n\n\n
myPb.enabled = Not myPb.enabled\nmyPb.invalidate\n<\/code><\/pre>\n\n\n\nAdd a second bevel button and name it bevTestBaseClass<\/p>\n\n\n\n
Change its Caption to say \u201cbevTestBaseClass\u201d<\/p>\n\n\n\n
In its action put<\/p>\n\n\n\n
PushButton(myPb).enabled = Not PushButton(myPb).enabled\nPushButton(myPb).invalidate\n<\/code><\/pre>\n\n\n\nSave (if you care to) and Run<\/p>\n\n\n\n
If you push the bevTestBaseClass button the button enables & disables on each push. And it does this visibly.<\/p>\n\n\n\n
But if you click the bevTestSubclass button nothing happens.<\/p>\n\n\n\n
Why not ?<\/p>\n\n\n\n
Properties are not virtual. Quite literally there are two \u201cenabled\u201d properties and they are not the same one. The custom subclass contains one. And the base class contains one.<\/p>\n\n\n\n
So when the code knows you are referring to the subclass type the \u201cEnabled\u201d property that is used is the one in the subclass instance. And the framework doesn\u2019t look at this one at all.<\/p>\n\n\n\n
So the framework looks at the one in PushButton and redraws with whatever Enabled state that one says.<\/p>\n\n\n\n
And its not the same as the one in the subclass.<\/p>\n\n\n\n
But when you press the bevTestBaseClass button you do get the change you expected because the cast makes the code refer to the Superclass version of enabled.<\/p>\n\n\n\n
This specific use where a cast is involved isn\u2019t so hard to find with a search and replace. But it\u2019s also not the only way that shadowed properties cause problems. The really tricky ones are where the declared type of a variable is the superclass type and then you get much the same behaviour as with the casts. And this one is NOT easy to find.<\/p>\n\n\n\n
We\u2019ll demonstrate by adding additional code to the project so far.<\/p>\n\n\n\n
First lets define a new method – FlipSubClass – that takes a myPushbutton as a parameter.<\/p>\n\n\n\n
Public Sub flipSubclass(button as myPushButton)\n button.enabled = Not button.enabled\n button.invalidate\nEnd Sub<\/code><\/pre>\n\n\n\nAnd for good measure we\u2019ll add a new method – FlipSuperClass – that takes a Pushbutton as a parameter<\/p>\n\n\n\n
Public Sub flipSuperClass(button as PushButton)\n button.enabled = Not button.enabled\n button.invalidate \nEnd Sub\n<\/code><\/pre>\n\n\n\nThe only difference between these two is the type of the parameter.<\/p>\n\n\n\n
Now lets add two more bevel buttons to use these new methods.<\/p>\n\n\n\n
Add a bevelbutton and name it bevDimSubClass and set the caption to bevDimSubClass.<\/p>\n\n\n\n
In this bevel buttons action event put<\/p>\n\n\n\n
flipSubClass(myPb)\n<\/code><\/pre>\n\n\n\nAdd a second bevel button named bevDimSuperClass and set the caption to bevDimSuperClass<\/p>\n\n\n\n
And in this action event put<\/p>\n\n\n\n
flipSuperClass(myPb)\n<\/code><\/pre>\n\n\n\nAnd run.<\/p>\n\n\n\n
Note this time there is NO explicit cast required and we can safely pass a myPushButton to a method that takes a PushButton because a subclass IS always also the super class type (isA would be true if you checked myPb isa PushButton)<\/p>\n\n\n\n
And yet the bevDimSubclass button has no effect on the buttons appearance but the bevDimSuperClass button does.<\/p>\n\n\n\n
Its the exact same issue as before but this time it\u2019s even harder to detect because what natters here is not the actual type or the instance but the DECLARED type of the parameter. <\/p>\n\n\n\n
Since shadowing can cause such hard to track down bugs it better to avoid it.<\/p>\n\n\n\n
Now IF you cannot and really to require a subclass have its own \u201cEnabled\u201d property that actually works you should add it as a COMPUTED PROPERTY that in the getter simply casts SELF to the super type and returns the\u2019s supers property value. And in the getter again cast to the super type and set the supers property to that value given.<\/p>\n\n\n\n