Essentially, you can corrupt your project by turning on a property in the Inspector Behavior dialog and subsequently converting it to a computed property. The IDE creates references the computed property OR another property (!) in code that can’t be seen in the IDE. This is Very Bad because the computed property’s Set method is called with an empty value; this can silently clear out any values that are being set previously, and there is no way to trace the code that is calling the Set method.
However, it kind of looks as if these Feedback issues were merged, and then closed, but without the issue(s) ever being fixed? It should be good if someone could take a look at this and clarify…
Looks like it might have been the same bug, but it’s hard to tell from the descriptions. My report has the advantage of a sample project and a short list of steps to reproduce. Hopefully this can get fixed, because the only solution is to edit the raw XML and remove the offending code, risking the integrity of the file in the process.
I think what you’re seeing is the normal initialization of properties. It has been this way as long as I remember. For a computed property, be aware that
Set will be called during creation of the object (possibly twice, once with the default value, once with the value set in the inspector.
Get will be called during debug when the values are displayed in the debugger.
Also be aware that you can get confusing results if you change the class after you have placed an instance on the window. That may be considered a bug or not, but it is the result of some design decisions that are probably difficult to change at this point.
“BUG” is entirely debatable but it is expected behavior.
Not new either.
It has everything to do with how Window instance is created & any objects on the layout, including non-visible ones, are created and initialized at run time.
Basically it comes down to IF you have a defined property (computed or not) that has a default value set in the inspector behavior that default gets set immediately after the instance is created on the layout.
If the code were not that way then any default values you set on the class would NOT get set and we’d have other issues reported as bugs (ie/ where the default values are not set on the instances as expected)
You shall be damned if you don’t document. I’m now going to file a bug against the debugger, because it should make it clear what the hell is happening here. It appears as though the call to property.Set is coming from nowhere.
As far as you can tell it is from nowhere. There’s nothing useful you can see in the stack.
This issue about properties on class instances on a layout is (or was) documented at one time
Cant say I’ve read the user guides in a long time so it may still be there or not - I don’t know.
It’s not really a “language” issue so I’m pretty sure its not in the language reference.
Hopefully this can get fixed, because the only solution is to edit the raw XML and remove the offending code, risking the integrity of the file in the process.