I noticed some new framework behavior that is new in XOJO 2013r3 that might be useful for others to know.
These were yielding some bizarre behaviors that were difficult to pin down after switching from 2013r2 to 2013r3.
In a simple app, you might not notice, but we implement an complex MVC structure that uses several layers of objects, each needing initialization before use.
The sequence of constructor firing for windows and embedded containerControls has dramatically changed. Previously, one could expect the constructor of embedded controls to fire before the window’s constructor attempted to access those objects. Constructor firing sequence now seems less hierarchal. You should now explicitly initialize contained objects via your own initialization methods rather than relying on the object constructors to fire in their former order.
window.visible = true and window.visible = false no longer hide/show a window. Formerly, setting the visibility of a window could change whether a window is visible without altering stacking order. Setting those properties no longer changes whether a window is seen on screen. Instead you must use window.show or window.hide to actually alter whether a window can be seen on screen. This DOES change window stacking order.
[quote=34460:@Guy Kuo]I noticed some new framework behavior that is new in XOJO 2013r3 that might be useful for others to know.
These were yielding some bizarre behaviors that were difficult to pin down after switching from 2013r2 to 2013r3.
In a simple app, you might not notice, but we implement an complex MVC structure that uses several layers of objects, each needing initialization before use.
The sequence of constructor firing for windows and embedded containerControls has dramatically changed. Previously, one could expect the constructor of embedded controls to fire before the window’s constructor attempted to access those objects. Constructor firing sequence now seems less hierarchal. You should now explicitly initialize contained objects via your own initialization methods rather than relying on the object constructors to fire in their former order.
window.visible = true and window.visible = false no longer hide/show a window. Formerly, setting the visibility of a window could change whether a window is visible without altering stacking order. Setting those properties no longer changes whether a window is seen on screen. Instead you must use window.show or window.hide to actually alter whether a window can be seen on screen. This DOES change window stacking order.[/quote]
I’d be very interested in seeing an example of both of these.
The only constructor change I can think of is that the class for control instances needs to have a default constructor - one with no parameters.
After looking at this some more, it turns out the sequence of constructor firing is correctly hierarchal. What DOES seem to be awry is that a property set during the constructor of a canvas is not correctly readable by its parent, enclosing container control during the contain control’s constructor.
The property value is correct when accessed by the canvas, but not by the container control.
This is despite the canvas constructor verifiably completing BEFORE the container control’s constructor fires.
AH I know what Case #29646 is & how to deal with it
[quote=34460:@Guy Kuo]I noticed some new framework behavior that is new in XOJO 2013r3
[/quote]
But its not new.
It does this in 2013r2, r2, 2012r2, 2012r1.
It should have done this from the beginning of time.
The IDE writes the code to create the layout.
So it first calls the constructor for the instances. Your code logs this call & sets a public property.
The IDE then has a method to set EVERY public property on EVERY control on the Window.
And this overwrites the value you set it in the Constructor.
Don’t make those properties on your control public & use a get / set pair of methods & you wont have this issue.
[quote] The IDE then has a method to set EVERY public property on EVERY control on the Window.
[/quote]
Wow. Would never have guessed that is being done to all the public properties.
Pretty big gotcha if one uses constructors to do initial setup programmatically if one does not know about properties being overwritten by the framework after constructor is done.
Something must have changed to code firing timings that made this issue become apparent in 2013.r3. This completely disabled our MVC display system because we use a public property to let other objects know that it is okay to start using each other. Ironically, this was initially done to avoid problems due to code firing order.
Guy - I ran into a different issue in R3 where overloaded/shadowed properties (e.g. a Label subclass with a .Caption computed property) was affecting loading / saving of projects. I doubt that it’s related to your issue, but on the off chance it is I thought I’d mention it.
[quote=34677:@Guy Kuo]Wow. Would never have guessed that is being done to all the public properties.
Pretty big gotcha if one uses constructors to do initial setup programmatically if one does not know about properties being overwritten by the framework after constructor is done.
Something must have changed to code firing timings that made this issue become apparent in 2013.r3. This completely disabled our MVC display system because we use a public property to let other objects know that it is okay to start using each other. Ironically, this was initially done to avoid problems due to code firing order.[/quote]
No - nothing changed
I ran this in 2012r1, r2 and r3 and get the exact same sequence there as I do in 2013r1 2 and 3
I even went do far as to run it in 2008 r4.2 and you get the exact same calling sequence there
I’m rather amazed you haven’t had this issue before
Pretty amazed here too. Unfortunately, for the issue to appear in r3 and not in earlier compilers you have to test against our much larger MVC implementation – too big to upload as a good test sample.
I agree, in this stripped down demonstrator, the behavior is the same between 2013r2 and 2013r3. On the big, actual app, enough other stuff happens that the problem is masked in earlier RS and XOJO compilers in the last few years. 2013r3 has something new other than the issue here. At this point, we don’t know what the other hidden difference is. Pragmatically, it doesn’t matter now that we have two work arounds.
The point going forward is that all properties of controls from this point on need to be made private in scope.
We’re going to go back and change all existing properties to private. That’s actually a good default to have in the IDE come to think of it.
2,000+ pages of code are in Cosalient EHR. This is going to be fun…
[quote=34617:@Norman Palardy]The IDE writes the code to create the layout.
So it first calls the constructor for the instances. Your code logs this call & sets a public property.
The IDE then has a method to set EVERY public property on EVERY control on the Window.
And this overwrites the value you set it in the Constructor.[/quote]
Rick, the latter is also what I had expected the framework to do, but as Norman has just told us. It actually goes behind (our backs) and changes values of public properties AFTER our constructors finish.
Values of properties changing independent of ones code is surprising like
x = 1 + 2
and later finding out that x now contains 15353 without any intervening (visible to programmer) code actions.
Norman, is this ONLY for public properties of controls or are there other types of items the framework reassigns silently?
Imagine that for a public computed property on a non-constructed object. #Disaster. I’ve been confounded at times by this order of things too, but the important thing, as far as I’m concerned is that it’s now documented here. It would be great to get this into the LR and user docs.
Sincerely, I believe I need to think a bit more about the effects, but right now 10:25pm (22:25) I don’t feel I am able to give a very correct answer. Right now I just “feel” it can be done in some way better.
