Is there any chance that you’re not accounting for the debugger calling the getter of the computed property? So the “differences” you are seeing might be a difference in how the debugger is working?
Good question, but I see the issue when just using MessageBox - no debugger involved.
Easy
mFoobar is not exposed in view behavior but IS a public property
The call we make sets the properties in the following order (I’m literally looking at the code)
Class11.Enabled = true
Class11.foobar = 999 // the property value ON the instance in the layout
Class11.mFoobar = 0
NOW for fun edit the view behaviour on Class1 so mFoobar is BEFORE foobar
The cut & paste the Class11 instance (this is stuarts bug)
Run again
Again this is something you can test out by hand by simply writing in the Open event of the window
dim c as new Class1
c.foobar = 999 // the property value ON the instance in the layout
c.mFoobar = 0
Then write it as
dim c as new Class1
c.mFoobar = 0
c.foobar = 999 // the property value ON the instance in the layout
its the same issue over & over & over - really
[quote=35315:@Norman Palardy]Easy
mFoobar is not exposed in view behavior but IS a public property
[…]
Class11.mFoobar = 0
[/quote]
That’s a bug - the default value of mFoobar (which is set in the Class definition, AND is also visible in the Inspector Behavior panel ) is 37. In prior versions of the IDE, the value shown is 37 and that’s the value you get.
Having it be set to zero, which seems to have started in [edit]2013 R2 (inconsistently) and now in 2013 R3 (reliably) is a bug.
make sure you add the instance to the window AFTER altering the view behaviour for the base class or you will get Stuarts bug
when I remove the instance and add a new one it comes out as expected
[quote=35318:@Norman Palardy]make sure you add the instance to the window AFTER altering the view behaviour for the base class or you will get Stuarts bug
when I remove the instance and add a new one it comes out as expected[/quote]
Agree: if I take that prop2 sample project and add another instance of Class1, then that 2nd instance behaves differently:
Class11: foobar=0, mFoobar=0
Class12: foobar=37, mFoobar=37
So would it be fair to say the issue is something like this?
“Changing the default value of a public class property, for a control subclass, then adding an instance to a window, will result in an instance with properties that are not properly initialized, as compared to an instance that is added after the default value was changed”
It’d be fair to say “You’ll experience bug 12337”
The issue is EXISTING instances will not update the value, new ones will which isn’t what you stated
[quote=35326:@Norman Palardy]It’d be fair to say “You’ll experience bug 12337”
The issue is EXISTING instances will not update the value, new ones will which isn’t what you stated[/quote]
This doesn’t explain how the behavior is different in 2013 R3 as compared to 2012 R2.1.
My hunch is that in older versions of the IDE, the project Load process would clean up the issue, whereas in 2013 versions the problem survives the save/load process intact.
[quote=35326:@Norman Palardy]It’d be fair to say “You’ll experience bug 12337”
The issue is EXISTING instances will not update the value, new ones will which isn’t what you stated[/quote]
Oops - I mean to say “after adding” not “then adding”.
I stand corrected:
One the instance has the old value, that sticks and is present across save/reloads, and this happens both with 2013 and 2012 versions of the IDE.
What appears to be different is that the order of property setting has changed from 2012 to 2013 - it looks like the Foobar() setter is called after the mFoobar setter in 2012, which hides the issue.
Bottom line: if you think it’s 12337, what’s the chance we can get 12337 fixed for good? That would be nice.
Actually you can demonstrate the order issue by altering the View Behaviour
Drag the items into a different order
Not sure
I hope Paul is taking notes on https://forum.xojo.com/4933-framework-resets-public-control-properties-after-c and this thread. This episode needs a very well documented part including best practices and gotchas.
Yeah what we already told everyone
Use the open event and avoid the pain and suffering
Not 0.3% of a small group of “everyone”, Norman.
Who did not read those threads didn’t know details.
Do Xojo will stop having new customers? They will need this knowledge from the docs.
I didn’t see a “How class instantiation and it’s interaction with works, dos and don’ts and whys” in the docs.
Next time 999 times will just need to say “Please, read the Fundamental’s guide, Class chapter, it’s all there”. Today, it’s not. If prefer to repeat this thread forever in the future, ok then. 
Page 143 User Guide Fundamentals - says
Initializing Control Subclasses
If you need to initialize an instance of a control subclass, dont use the constructor. Instead, put the code that does the initialization in the Open event of the control.
I knew I should have left this thread muted
I’ve been using RealBasic since 2001 and I definitely didn’t read or hear about having to initialize in the open event of controls until now.
I think I qualify as a fairly seasoned user after 12 years of growing along with the language. Stuff said in the forums does not disseminate to everyone. We read all the threads.
Even worse, us experienced users have less and less compunction to re-read the user manual.
Best practice issues like,
- Never allow implicit windows
- Always initialize controls in their open event instead of their constructor
- Don’t rely on any event order
- Don’t update the GUI from a thread
etc
Have been gradually and inconsistently discovered (by luck) while reading the threads I do happen to visit.
Is there a nice repository of best practices?
[quote=35347:@Norman Palardy]Yeah what we already told everyone
Use the open event and avoid the pain and suffering[/quote]
Norman appears to be again intentionally dodging the issue.
It’s simple: The IDE has a feature, called “Inspector Behavior” which allows one to set per-instance values in the IDE. I paid for this feature, and it generally works great. It does, however, have some very serious bugs.
Please just fix them.
Saying “use the open event like we always told you” is a the same as saying “Inspector Behavior is not usable or can’t be fixed” but without admitting that’s what you are saying.
That’s far than sub optimal, Norman. I’ve read that single line too.
Besides Guy’s point, there is no mention about the interrelation on the instantiation chain.
But I see you have made your choice, then ok. I have no intentions of staying here talking boring stuff.
I know enough, i’m ok, good luck with the newcomers and misuses of the “Inspector Behavior”. 
Besides the documentation problem, Michael made findings, now Christian too.
For the good of the community, drink a beer, have some rest, and take them seriously after, please.
Bye.
[quote=35381:@Guy Kuo]I’ve been using RealBasic since 2001 and I definitely didn’t read or hear about having to initialize in the open event of controls until now.
I think I qualify as a fairly seasoned user after 12 years of growing along with the language. Stuff said in the forums does not disseminate to everyone. We read all the threads.
Even worse, us experienced users have less and less compunction to re-read the user manual.
[/quote]
The LR and the threads are MOST of the information you need.
But the Users Guides have new information in them all the time - like this - which has been there since at least 2008 (possibly before).
(I’m honestly not sure where in a LR you’d put this kind of information)
I can’t force anyone to reread the manuals but I can say at least some of this has been documented for quite some time.
I knew about this back in 2006 because I ran into it - as did some others which is why Aaron eventually blogged about it.