Oh man, I’ve just spent the last 2 hours tracking down some errors that were caused by trying my project in 2015r4.1.
Both issues were eventually narrowed down to properties of a canvas subclass being set by 2014r2.1, which are not visible in the properties pane of the IDE. These properties are not set to show in the inspector, which is why it took a long time to discover.
Transparent became disabled, erasebackground became disabled and a computed property was being set at control construction time, which is a wrapper for some declares…
I immediately went back to 2015r4, but these trouble stayed until I figured out what the problem was.
Could it be youd have to add something to <https://xojo.com/issue/42459> resp. 17052?
Ive been spending a few hours too trying to find out what overrid the settings of a control and can imagine doing so again in the future this is a hard to remember oddity.
I can accept that an instance remains with the old value.
What I don’t understand i why a new instance is with the old value. The copy should happen at creation time (when I create the instance) and should reflect the default value I use. Otherwise I have 2 place where I have to change the default value or in other term the default value I set in the inspector (after I put a control in a window, even if i delete it) has no meaning and could be removed from the interface.
BTW we are talking of properties that I don’t set in the behavior pane, so this fix with the original value is unknown for most of the user.
[quote=246607:@Norman Palardy]Instances COPY things as set AT THE TIME YOU PUT THE INSTANCE ON A LAYOUT
This behaviour isn’t new to 2015r4.1 - its existed for 10+ years
There is a feature request filed (dont know the number) to have a means to “reset” an instance to whatever the class currently is set to[/quote]
All the changes I had made in r4.1 were code changes, not interface changes. So I didn’t any new instances of elements to the interface.
If I get time, I go back to the backup from the day before, confirm it works in r4 and then open it in r4.1 and see if it does again.
it just seems very much the same as others where people create an instance, then change the base class, and are surprised those changes (either to default values etc) are not replicated to the instances
maybe I’m misunderstanding what you’re describing occurred ?
[quote=246671:@Norman Palardy]it just seems very much the same as others where people create an instance, then change the base class, and are surprised those changes (either to default values etc) are not replicated to the instances
maybe I’m misunderstanding what you’re describing occurred ?[/quote]
I could understand if I had done that and then it had occurred, the only difference was going from r4 to r4.1 and Tim is right, hidden properties got changed, including a Computed property which now gets a value set, before the open event of the control has fired.
a diff of vcp projects before & after would give me a better idea of whats going on and even possibly why
heres what I just did
created a new project in 2014r2.1
added a subclass of canvas
then added an instance of this subclass to the default window
saved as text into a dir named “before”
duplicated “before” and renamed the dir “after”
open the project in after in 2015r4.1
added and then removed an event handler from my subclass (so it was definitely dirty)
moved the instance on the layout (again so it was dirty)
here’s the compressed apps
yeah love the name untitled folder 17
the ENTIRE list of changes
In Class1.xojo_code
at line 71 added
EditorType=“Integer”
at line 111 added
EditorType=“String”
at line 117 added
EditorType=“String”
in Untitled.xojo_project
line 2 altered to
RBProjectVersion=2015.041
line 41 removed - it read
UseLLVM=False
In Window1.xojo.window
line 41 changed to read
Left = 42
every difference makes sense
2014r2.1 may NOT have listed the correct editors in the view behaviour - 2015r4.1 adds them if they are absent
2015r4.1 rewrites the manifest so it makes sense it adds the RBProjectVersion for this version used
It also removes extraneous settings like UseLLVM false as that IS the default value
And the last change of Left makes sense - I moved the control
None of the other items changed so … an example with steps helps
[quote=246674:@Sam Rowlands]I could understand if I had done that and then it had occurred, the only difference was going from r4 to r4.1 and Tim is right, hidden properties got changed, including a Computed property which now gets a value set, before the open event of the control has fired.
[/quote]
This however isn’t that new
Properties get set when the item is constructed
They HAVE to
Quite literally on a window the code is roughly, in the window constructor,
dim tmp as SamsCoolControl
tmp = New SamsCoolControl // <<< your constructor WILL get called here
// <<< hence the requirement you have a 0 parameter constructor
tmp.SetProperties // <<< so EVERY property on your control will get set here
They HAVE to get set there otherwise your controls aren’t initialized to the values you set in the layout editor
Well I’ll be… Shows all versions of my project going back to last week show these problems… I’m stumped, but obviously there’s no evidence to support my original claim. Going back further is before I created the new control.
This makes sense.
So I formally rescind my accusation. Sorry for the noise. I think I’m losing my mind…
[quote=246681:@Sam Rowlands]Isn’t it “We got one…”?
Apparently I didn’t get the role as the secretary in the new Ghostbusters movie, they used Thor instead.[/quote]
You lost your mind, and Norman found one.
It’s okay, Sam, it just means it’s time for lunch.
If you have to change the default value, a solution is to change the property scope to private, save, reset to public so all the internal default value are reset to the new value and synchronized.
The side effect is that also the instances will have the new value, not only the new instance.
