Class1:
public computed property Foobar() as integer // INSPECTOR BEHAVIOR IS CHECKED
get as integer
return mFoobar
set (value as integer)
mFoobar = value
public property mFoobar as integer = 37
Class2
public property mFoobar as integer = 37
In Window1, Class1 has Foobar set to 999 in the Inspector.
Run and click the button:
Results:
Class11.Foobar = 0, Class11.mFoobar = 0 // these values make no sense, should be 999 and 37, or 37 and 37
Class21.mFoobar = 37 // this is as expected
You can see that the setter is being called with the correct value (999) which properly sets mFoobar to 999. It’s only called once. Yet, at some point later, mFoobar has been reset to zero.
Normally, you are right, but I’m doing this on purpose to illustrate what I believe to be a general bug. The fact that mFoobar is used inside the Foobar Getter and Setter may (or may not) be relevant. I’ll do another test to see.
Um, it seems extremely relevant. You’ve got 2 public methods initializing the same property. Order of operation (which is undefined, and may easily change from one release to the next, or even one save of the project to the next) comes into play as far as which value is assigned.
Note that your project is auto-saved when you run it, which could account for the differences you’ve seen between runs of the same project.
So something very weird is going on - could it have to do with either the names (alphabetical?) of the properties, or perhaps with the order of creation in the source code?
Order of operation differences certainly could explain foobar = 999 vs. foobar = 37, but it can’t explain foobar (and mFoobar) both being 0, which is what my first demonstration project “prop2” shows.
Can you explain how a order of operation difference could do that?
If the Inspector Behavior or Inspector value of one of them is set to 0, but the other is not, then the final result depends on which one is initialized last.
Also - for a computed property, there is no value allowed in the Inspector Behavior dialog box - you can set a value for regular properties, but not computed properties. However, if you check the box for a computed property, then you can set a value on the instance itself using the window / inspector.
This is basically a more elaborate version of the other thread
Buy Aaron Ballmans Book & read the sections entitled “How Stuff Works: Windows” & “Window.ImplicitInstance”
It will explain a LOT
To be absolutely 100% pedantic here, so there can be no confusion. In 29724, the first example I submitted “prop2” shows a situation where there can only be two logical outcomes:
Either
Foobar=999 and mFoobar=999 (if the Foobar setter happened after the mFoobar setter)
or
Foobar=37 and mFoobar=37 (if the Foobar setter happened before the mFoobar setter)
But what we see is
Foobar=0 and mFoobar = 0
THAT is the bug. There is no logical way that a Zero can be getting in here. Please focus on this issue and ONLY this issue in your analysis. Other topics (such as the order of operation) are interesting but not relevant.