This is about an issue I have solved (sort of) myself; I’m just wondering whether what I’ve observed was to be expected or whether it might be a bug …
I have defined a class WindowPlus as a subclass of DesktopWindow and added a number of properties. Under ‘Inspector behavior’ I’ve added a subset of those properties to the inspector pane. Now when I create a new window in a project and set its Super to WindowPlus my properties do show up in the inspector pane and I can enter their intended values.
However, when I created instances of such a window the values specified in the inspector were ignored; they still had the default values as specified in the original property declarations instead.
I had tried various things to no avail until out of desperation I resorted to remove the default values from the property declarations altogether – and lo and behold that worked. The values entered in the inspector were no longer ignored.
Is this supposed to work like this – i.e. that you may not specify default values for properties you want to set in the inspector?
In fact that was the first trail I had followed but in vain – the values from the inspector were never applied, neither before, after, or during the constructor nor before, after, or during the opening event. Like they didn’t even exist.
Right from the start the properties had their original default values and that never changed through all the steps until the window was shown. I could set the properties to the desired values either in a constructor or in the opening event handler (which was my initial workaround) but if I didn’t the default values stuck.
To clarify the class/instance hierarchy was like this:
DesktopWindow
has a subclass WindowPlus (here a number of properties are declared with their default values, and added to the inspector)
has a subclass myWindow (here the property values get set in the inspector)
has an instance myWindow1 (here the properties still have the default values defined with WindowPlus, ignoring the values from the inspector for myWindow)
What does work is this:
DesktopWindow
has a subclass WindowPlus (here a number of properties are declared without any default values, and added to the inspector)
has a subclass myWindow (here the property values get set in the inspector)
has an instance myWindow1 (here the properties do show the values as set in the inspector for myWindow)
Again, it depends on where you expect these things to work. The Constructor (or any methods called by the constructor) won’t because that runs before any other code gets to run. Once the Constructor finishes and returns, a special method is run that flies through and sets all of the initial default values and then the Opening event fires.
I had no particular expectations in this case, just that the values defined in the inspector would be set at some point. Only they are not, except when those properties have no (explicitly declared) default values to begin with. According to your description of the process I would expect the properties to be set to the inspector values once the Opening event is raised but again, this isn’t what is happening – when I check in the Opening event handler they still carry their default values. Can this be regarded as a bug?
That’s what I’m doing now and to be sure it works (as described above). But how can this be regarded as the correct behavior? The properties get their original default values in one class (WindowPlus in my case) and the values set in the inspector apply to a subclass of that class. Shouldn’t the default values set in a subclass override the defaults set in a superclass?
If the current behavior is indeed the intended one it probably should be mentioned in the documentation somewhere that when you use Inspector Behavior to set property defaults in a subclass you must not declare default values in the super class.
(If you provide default values when you declare a property in the superclass and add the properties to the inspector, the inspector for a window declared as a subclass will initially show the default values of the superclass, but these can then be changed. There is no warning that whatever you enter in these fields will be ignored as the defaults of the super always prevail.)
Are the properties in the super class regular properties or are they computed properties?
FWIW, I have not seen the behavior you are describing except in cases where you’ve shadowed the properties, that is, declared them in both the super and in the subclass.
There is a class WindowWithProperties with Super DesktopWindow and two properties, SomeInteger (default: 0) and SomeString (default: “Default string”). These properties were then added to the inspector.
There is a window Window1 with WindowWithProperties as its super, and in the inspector the properties were set to 42 and “My string”, respectively.
Now when the app runs and Window1 is opened, its two TextFields fetch the property values in their Opening event handlers and display these.
Result is 0 and “Default string” rather than the expected 42 and “My string”.
That’s odd (I’ve never ever seen that “Obsolete” group myself). And why does “Has Title Bar” show up there? HasTitleBar is an official, non-deprecated property of DesktopWindow after all and is certainly not obsolete. Could this be because you are using Xojo 2024r4.2 whereas I’m working with the newer 2025r1 and have created the example project with that version?
In a new project I inserted a new class, named it “WindowWithProperties”, and set its Super to DesktopWindow
Added a public property SomeInteger of type Integer with 0 as the default value
Added a public property SomeString of type String with “Default string” as the default value
Opened Inspector Behavior and selected the entries for those two properties to be included in the inspector
Inserted a new Window and set its Super to WindowWithProperties
Entered 42 and “My string” as the values of SomeInteger and SomeString in the inspector
Added two TextFields to the window with Opening event handlers with the code “me.Text = Str(self.SomeInteger)” or “me.Text = self.SomeString”, respectively
Curiouser and Curiouser … I mean, in my case there was a single isolated issue; everthing worked as it should except that property defaults declared in the super stuck and couldn’t be overridden by entering different values in the inspector for a subclass. But now for some those properties don’t even show up in the inspector (for some – they continue to do for me), and a built-in property like DesktopWindow’s HasTitleBar shows up as “obsolete” (not on my computer though).
Having said that, I did notice some new issue in 2025r1: Implicit Instance appears to be gone from the inspector (although it should be available under “Window Behavior”, according to Inspector Behavior). The property is still there of course and it is still true by default but the inspector for a DesktopWindow doesn’t show it and you cannot easily turn it off. (Implicit Instance is still shown for the deprecated old Window class, only DesktopWindow is affected.)
I’ve downloaded the old 2024r4.2 again and when I open my example project created with 2025.r1 I get a warning about opening a project created with a newer version, and when I ignore that warning the inspector does look as Greg has shown:
So Greg’s “Obsolete” issue results from using an older version of Xojo. Incidentally comparing these screenshots also shows how Implicit Instance has gone missing in 2025r1.
Anyway, my original issue with default values not being overridden by inspector values in a subclass could also be reproduced with 2024r4.2 so this is not a new issue introduced with the new version of Xojo.
I have recreated my example project in Xojo 2024r4.2 and indeed the properties don’t show up in the inspector at all (which they do in 2025r1). This suggests another bug (probably this one: https://tracker.xojo.com/xojoinc/xojo/-/issues/76101), unrelated to my issue, that was fixed in 2025r1. Unfortunately 2025r1 now hides the Implicit Instance setting …
