Wasted huge time to discover that having a Window super class with Property of “Name” as String causes XOJO to assign the added .Name property the design-time name of the runtime window! Maybe I’m the only one to not know this “featured behavior”, then again, maybe there is something amiss inside XOJO…
Easy to see:
- New desktop project (let the Title default to “Untitled” and accept the default window name in the inspector of “Window1”
- Create a Window superclass and add 1 property, Name, of Type string
- Go back to new desktop project, add “msgbox Name” to the Open event, run it – and you’ll see “Window1”
Now, there are uses I could imagine for this “feature”, and it would be nice to hear what others think.
Thats called a shadowed property.
Make sure that your analysis warnings for shadowing are on.
What is interesting to me, is that “Name”, unlike “Left” or “Top”, etc., is not a public property of the Class or a Window. If wouldn’t have used say, “Width” because of the shadowing – but there is no Class.Name or Window.Name public property. An interesting artifact to add to the XOJO list … avoid using not only public property names, but also anything that appears in the Inspector too!
There are some the IDE will flat out stop you from using
For instance you cant name a property in your class TEXT or INTEGER or any of the intrinsic data types (string, Uint types color etc)
But you can add a property called Date or many of the reference types
IF you do this then you need to make sure you do it “properly” - like my blog post shows
If you happen to shadow one that the superclass uses and you dont do it in a way the super class property still gets set you can have lots of issues
Name is, in many ways, “special”
It exists on windows and on controls - but it is read only