Computed Property

Is it possible to create a computed property that can ONLY be set via the Inspector.
So at Design time is is read/write, but at RunTime its read-only?

Only way I have come up with is to set a boolean flag during the Class OPEN event… so its “false” during initialization, and becomes true at OPEN
then in the SETTER of each property, only allow it to execute if that flag is still false

Not that i know of. Wouldn’t a method do the trick using Assigns ?

Let us say you have a computed property theValue, with a non computed mtheValue as storage. If you want to set the value in the IDE, you would have to do that to mtheValue anyway. So if you do not implement the setter in theValue, this is what you describe, right ?

I have to implement the SETTER in order to assign the Inspector Value to internal variable… SETTERS are called for all Computed Properties BEFORE the Constructor it seems… But I can’t make them constants as the developer needs to set them at design time.
I just used the method I described above and it works just fine… To see where/how/why… look at my custom TabBar control in another topic, that is where I needed to use this.

No, it can be – and usually is – a computed property. Every property and computed property can be made visible to the window editor if its scope is “public”.

Dave: just add “Hidden” in the attribute editor of the setter. It then will not show up in autocomplete.

Its not a matter of showing up or not showing up in autocomplete. The app CANNOT be allowed to change the value at Runtime…
Thanks for the responses, but I think what I have done works for now

Actually your OP is correct. There is no difference possible for between design-time and runtime. Not only in Xojo but in general when you think about it – the property needs to be set exactly one time, which means it needs a setter (even if it was in code and the user of the class could only set it once in the open event). So a guard variable is the way to go.

Another possibility would be to use two variables in the class: one to set the value in the window editor and one which holds the value:

[code]Class MyClass Inherits Control

Private mPropABC As Integer // the “real” property, not visible in the window editor
Public PropABC As Integer // Attributes: Hidden, can be set in the window editor

Event Open()

Sub Open()
mPropABC = PropABC // copy the value set in the window editor to the “real” property
RaiseEvent Open()

Function PropABC() As Integer
Return mPropABC // return the value from the “real” property


In a MyClass instance’s Open event:

System.DebugLog Str(Me.PropABC) Me.PropABC = 2 // will have no effect, in addition PropABC will not show in autocomplete System.DebugLog Str(Me.PropABC)

After all the debate I’d say the answer is “Yes” :stuck_out_tongue:
A set once computed property would be perfect
You could expose it to the user in the IDE and that value they set in the IDE would be set by the window’s initialization code so they could never alter it again at runtime - it could only take on the value set from the inspector
The only thing you need is a guard to make it so you can track if the instance property has been set

try this

Which is EXACTLY what I said in the OP…

in Open Event of the class a flag is set to TRUE
If that flag is TRUE then the SETTERS are ignored
And since the SETTERS are all called BEFORE the Open event, that flag will be FALSE for the first run thru all the SETTERS

More or less

If you stick breakpoints all over that example you’ll see that the instance on the window has its constructor & setter called before the open event

This is normal - as the basic structure of the code that is generated from the IDE is

     dim tmp as Control
     tmp = new your_custom_control
     tmp.set_all_properties <<< yeah this is magic but........

That FIRST call to set the properties is the one the IDE generates from whatever settings you have in the IDE inspector

And all this set up happens LONG before the open event occurs