I am converting a legacy app from RB to Xojo and have ran into a situation where computed properties are acting differently.
The computed properties are on a canvas control and are not available in the layout editor’s Inspector.
The canvas controls are placed on a window or in a container that is placed on a window.
What I am finding, is that the RB version of our app (compiled using 2006/2007/2008) does not call the setter when the control is instantiated. However, the Xojo version of the code does call the setter. I have created new test projects that confirms this is not a quirk of our project (ie: due to the control definition changing after being placed on the window).
I was under the impression that Xojo, like RB, would only execute the setter if the property was available in the Inspector. I’ve searched the Xojo documentation and cannot find anything useful. I’ve also searched the forums but again, I cannot find a definition that is 100% clear.
so Is it correct behaviour that Xojo calls all setters when a control is instantiated no matter if the properties are available in the Inspector or not?
If this is expected then I will have to adjust our code accordingly. It is a bit annoying though as it means our code will now be called with bogus values (the RB method seems much more logical to me).
The functionality definitely seems to have changed at some point as our app has ran the best part of 10 years without this problem. The fact that I can create new projects in RB and Xojo which shows the difference backs up my theory.
Luckily, we found it quite quickly as our app crashes after a few clicks. The setter is calling a superclass function which manipulates a property. Unfortunately, the property is Nil as the Open event which initialises it hasn’t triggered yet )-:
I must admit i’m not sure why there would have been a need to change the RB functionality. Since the property cannot be manipulated by the Inspector there is no default value to set. Calling the setter with whatever value the framework decides should be the default seems unnecessary and a waste of CPU cycles.
I guess I can work around this by storing a flag indicating if the Open event has been called and exiting the setter if it hasn’t. It just means me pouring over lots of code trying to find out where I will need to do this.
Ah this is case 29383
I can see what changed and that I did try to fix it once & had to revert the changes I made as they had other issues
The issue that occurs is this
Suppose you add a computed property - a boolean - that is NOT exposed in the inspector behaviour but you set the default value to TRUE
If we only set those values that are exposed then this property of yours doesn’t end up with the value set in the inspector behaviour
It’s all rather messy
I think Karen has reported other similar issues with setting default values in the inspector behavior and on the property itself
[quote=302488:@Norman Palardy]Ah this is case 29383
I can see what changed and that I did try to fix it once & had to revert the changes I made as they had other issues
The issue that occurs is this
Suppose you add a computed property - a boolean - that is NOT exposed in the inspector behaviour but you set the default value to TRUE
If we only set those values that are exposed then this property of yours doesn’t end up with the value set in the inspector behaviour
It’s all rather messy
I think Karen has reported other similar issues with setting default values in the inspector behavior and on the property itself[/quote]
I’ve just had a look at 29383 and I can imagine this only came about because of the change in functionality I am experiencing. If the setters were not getting called (ie: RB2006/2007/2008 functionality) then 29383 probably wouldn’t be relevant.
The workaround suggested doesn’t make sense to me. Shouldn’t the value in the Inspector behaviour dialog only be relevant if the property is visible to the Inspector? If a value is set and the property isn’t visible to the Inspector then as far as i’m concerned it should be ignored (after all, it is called Inspector Behaviour).
When I needed to set a default value for computed properties I simply added the relevant code to the Open event.
No
Wish that were the case but no its not
NOT doing this affects framework code in a way that silently breaks projects
And doing this affects projects in the way you’ve hit upon
Inspector behaviour is “does this property show up in the inspector and does it have a default”
Have yet to find a suitable middle ground that doesn’t break either
[quote=302783:@Norman Palardy]No
Wish that were the case but no its not
NOT doing this affects framework code in a way that silently breaks projects
And doing this affects projects in the way you’ve hit upon
Inspector behaviour is “does this property show up in the inspector and does it have a default”
Have yet to find a suitable middle ground that doesn’t break either[/quote]
I think the only way out without upsetting anybody is to have a project setting / preference that controls what the Inspector Behaviour means. To me (and apparently in older versions of RB) it means that you can make a property available to the Inspector and if it is visible, set its default value.
It sounds like at some point the purpose of the Inspector behaviour panel has changed / been abused.
I think I know what an “ideal” fix would be there’s just not any decent way to make it happen.
Yet.
And without that support I dont have a decent way to even test out my theory as to how I could make this work.
And until I can everything else has had negative impacts one way or the other so there’s no middle ground as of today.
