Does anyone know why a Computed Property on a Class with a super (e.g. Canvas) that has been added to a Window has all its public Computed Properties initialised without any code being called or them even being on the Inspector?
To add to that, you can add an Integer which gets initialised to 0, change its type to a string and the 0 carries over, it doesn’t even reset the string to empty.
Is this a bug, a feature or am I missing something?
Do I really need to change the computed property to a method just to stop this happening?
You have to replace your object in your window.
The “class setup” is already in your window and you can’t change it.
More exactly you can:
make the property available to the IDE with Inspector Behaviour, change “0” to “” and remove the property from the inspector
but in this way on open the “set” will be called (I don’t know if your desire)
Otherwise:
Export the window as Text and remove the “setup line” (in this way on open the “set” will be not called)
Otherwise:
replace the class in your window (it’s the same as before but you can do this in you can’t export the window as Text)
[quote=406529:@Antonio Rinaldi]Otherwise:
Export the window as Text and remove the “setup line” (in this way on open the “set” will be not called)[/quote]
Thanks Antonio, that got around the problem.
So is that a bug in the IDE then, where it adds all Public Properties to the object and initialises them even though the Property has not been exposed using the Inspector Behaviour? Because, other than dropping into a text editor, there doesn’t seem any way to stop that happening.
Yeah it was there, but I couldn’t clear it to stop it calling the Set. I tried setting it to Empty string then removing it from the Inspector using Inspector Behaviour but it just came back as a 0 when I switched the Class Property back to an Integer.
Oh well thats because integers are intrinsic types and theres always a default value of zero. Just like Strings have a default value of and Booleans start out set to False.
I think to remember that there has been a Blog post about this “Computer Property Initialization”… but I can’t find it right now
The short story is: all computed properties (need to) be initialized, so their setter is always being called. Why this is or needs to be like that, I believe that Blog has it explained.
Anyway - this behavior may lead to issues if the setter is performing code, while the whole UI is not yet fully in place.
A workaround mentioned was to use a Boolean property (e.g.: ebControlIsOpen), which you set to true after Event .Open. And code in computed properties check this flag, and just bail out of not yet “fully opened”.
I don’t think I’m explaining the problem correctly.
New project
Add a Property to Window1 called SomeSetting
Convert SomeSetting to Computed Property (using menu)
Go into the Set and put a breakpoint on mSomething = value
Run program
The breakpoint isnt triggered.
Add a container control to the project
Add a Property to ContainerControl1 called AnotherSetting
Convert AnotherSetting to Computer Property (using menu)
Go into the Set and put a breakpoint on mAnotherSetting = value
Drag ContainerControl1 onto Window1
Run program
The new breakpoint IS triggered.
Why?
Using the IDE, how do I stop that happening?
Why do I need to export that WIndow to a text file, remove the line that says: " AnotherSetting = 0" then re-import it back into the IDE for it NOT to hit the new breakpoint?
Why does doing 3 above NOT cause things to break
Why does the IDE store another local copy of AnotherSetting and call ContainerControl1.AnotherSetting.Set when adding the control to the window when it works fine without it.
Because in Xojo (I’m not debating if it’s right or not since there are pros and cons) if it’s a public computed property when you update the window the setup is written in window
Having a break in the set
So if you have have pub prop and drag the object -> break
Change to private -> no break
Change to pub -> break
Change to private and change the instanceName then change to pub -> no break
change some other info (width for example) -> break
So it’s clear that a default value for the instance is used for pub props, this default is the value you setted as default or with the behaviour, and is recorded in the window even if you “remove” the prop (private for example), but it’s linked to the object (so if you change name doesn’t exists) but is written again if you modify anything in your window.
