Working around things the IDE prevents

Sometimes when you want to subclass a control you want to retain the property name the Xojo control uses, but you want to add some custom functionality by putting a computed property in place in your subclass.

In the long run this makes your subclass a better drop in replacement. You dont end up with the case where the superclass has a property named one thing, like Text, and your subclass has a similar property named something else, like Caption.

For some properties the IDE will prevent you from doing this at all. Basically IF the property you want to do this with is named TEXT you cant create a subclass with a computed property named TEXT because the IDE will stop you – TEXT is a data type and Xojo will stop you from using that name since TEXT is a data type.

Most times you’re stuck.

Notice I say “most times”

There ARE ways to make this work – but it involves working AROUND the IDE outside of the IDE. And it can be “fragile” – if you do anything that would alter the signature in the IDE it will fix it for you then you have to redo things.

When I have wanted to do this I will name my property something memorable – often “Caption” or something mostly suitable but still not the name I really want.

Then I save as text (xml would also work since its mostly plain text). Then I open my project in a text editor like BBEdit & I find the item I named “Caption” and rename it “Text”. Save the edited text and now get the IDE to reload the project.

And there’s my property named “Text” as I expect and I can then also edit and fix any code in the getter & setter and the IDE wont fight me.

I’ve submitted a feature request to make it so that if there is a property on the super class that has the same name as a data type like Text that the IDE permit me to make a computed property on a subclass that shadows that one.

In the mean time this is a workaround.