29724 - Computed properties with inspector behavior set wipes out public properties


Run the attached project.

It contains two RectControl subclasses:

  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
  public property mFoobar as integer = 37

In Window1, Class1 has Foobar set to 999 in the Inspector.

Run and click the button:

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

Testing in RB 2012 R2.1, the results are different: class11.foobar = 999, classs11.mFoobar = 999, class21.mFoobar = 37

In 2013 R3, if you set a breakpoint at


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.

Also, in preparing this example the IDE had a NOE: <https://xojo.com/issue/29725> as I was renaming one of the properties.

In Class1, mFoobar should NOT be a public property. What’s the point of hiding it behind a computed property if you’re exposing it directly?

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.

I attached another demo project to the feedback case - it’s basically the same, but the names of the properties are different.

Results from this version:

xojo 2013 R3:
c11.alpha = 37, c11.beta = 37
c21.zebra = 37, c21.beta = 37

RB 2012 R2.1:
c11.alpha = 999, c11.beta = 999
c21.zebra = 999, c21.beta = 999

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?

Yes. See my comment above.

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.

But they are not - see the examples please.

And note that inspector behavior is used, regardless of whether it is checked to show in the inspector or not. (possible change in new release?)

Again, see the example: there is no 0 value anywhere.

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

If you can explain 29724 as “expected” behavior I’m all ears. I’m leaning heavily towards “bug” myself.

rearrange the items in the inspector behavior so beta and zebra are in a different order & be prepared to be surprised

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:

Foobar=999 and mFoobar=999 (if the Foobar setter happened after the mFoobar setter)
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.

I tried it with class1 and saw nothing change.
I tried it with class2, and both class1 and class2 changed.

So there are two issues here:

  • inspector behavior changes don’t propagate to the window instances immediately
  • inspector behavior order changes setter order (maybe not a bug, even could be a feature)

However, they both change to sensible values, and this does NOT explain the Zeros i’m seeing in the first example.

Explain the Zeros : that’s the holy grail here.