TD-23569: Global variables sequence has effect on initialization timing

Post found bugs and possible workarounds.
Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 484
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

TD-23569: Global variables sequence has effect on initialization timing

Post by Dave Rabelink » 24 May 2017, 12:07

I think it is a defect. Or at least, having the constructors in TD for classes could lead to unwanted results.

This is the case:

When a class has a constructor, it can access any defined global variables (base types like boolean, string etc) in the application. It can set them and also read them.
The constructor is clearly executed before On SAM_AppStartup.

So, based on what the constructor can do with global variables, we would expect when the constructor sets global variable values, they will be available at the point when On SAM_AppStartup is executed.

Well, this is actually true ONLY when the global variable is defined BEFORE the class UDV object. When the sequence is different, where the variable is defined AFTER the class UDV object, the global variable is reset (or re-initialized) before SAM_AppStartup.

This is unwanted behavior as it can break application depending on the sequence of global variables. The sequence for base types should not matter.

See testcase.

InitGlobalVarsTiming.zip

Run it and see there are 2 messageboxes shown:

First msgbox: shown on the constructor of the class. It clearly shows that the global variable is set to TRUE and the constructor can read it.
Second msgbox is at SAM_AppStartup. It will read the global boolean and show the value in the msgbox.

Initially the testcase works like expected. The boolean is TRUE in both cases.

Now change the code. Move the global gbInitDone boolean variable AFTER the UDV variable named guBase.
In this case, the first msgbox still shows TRUE for the variable, but FALSE in the second msgbox.

The TD runtime is initializing the variables in sequence of definition so it seems.
So when the UDV constructor has set the global variable, the TD runtime will initialize the global variable afterwards and clearing the previously set value.

IMHO, the TD runtime should be more intelligent and first initialize all base variables (booleans, strings etc) and then (in sequence) init all UDV variables.

When the TD runtime does this, the issue would be gone. All base types are initialized before any constructor is executed and is able to set values which will be available from the SAM_AppStartup time and further.


This has been registered as:

Ticket # 3041468: Global variables sequence has effect on initialization timing
TD-23569
You do not have the required permissions to view the files attached to this post.
Last edited by Dave Rabelink on 20 Jun 2018, 09:04, edited 1 time in total.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Jeff Luther
Site Admin
Site Admin
United States of America
Posts: 124
Joined: 04 Mar 2017, 18:34
Location: Palm Springs, California

Re: Global variables sequence has effect on initialization timing

Post by Jeff Luther » 24 May 2017, 16:19

Hmmm... I'm running the original v7.0 build 49447, Dave, and see the "Expected Behavior" msg. box for your apt as you've attached it, and after I swap the decls. for the 2 UDVs in Global Vars. Could this be a new 7.0.1 issue??

Maybe someone else can try this as well...
Jeff Luther @ PC Design
Palm Springs, California
TD info. & samples: http://www.jeffluther.net/TD/

Uwe van der Horst
Site Admin
Site Admin
Germany
Posts: 62
Joined: 05 Mar 2017, 14:21
Location: Wetter (Ruhr), Germany

Re: Global variables sequence has effect on initialization timing

Post by Uwe van der Horst » 26 May 2017, 08:00

With Build 50852 and Win 7 prof. I have the same results as Dave.
Best regards,
Uwe van der Horst
Advo-web GmbH

Christof
Germany
Posts: 9
Joined: 06 Mar 2017, 07:27
Location: Frankfurt, Germany

Re: Global variables sequence has effect on initialization timing

Post by Christof » 26 May 2017, 12:38

I don't agree with you that this should be a defect.

For all OOP languages, it is considered as "Bad Practice", when referencing global objects from within constructors or destructors (where available).
If you do so, your class looses its independency from its environment. Also you should never count on the order of creation and disposing of global objects.

Just my 2 cents, Cheers!
Christof

Jeff Luther
Site Admin
Site Admin
United States of America
Posts: 124
Joined: 04 Mar 2017, 18:34
Location: Palm Springs, California

Re: Global variables sequence has effect on initialization timing

Post by Jeff Luther » 26 May 2017, 16:01

Christof: I will give my 2 cents in reply as well, so when you wrote that
For all OOP languages, it is considered as "Bad Practice", when referencing global objects from within constructors or destructors (where available).
I understand and agree with you that referencing global vars might be bad practice.

BUT... according to my testing with the original v7.0 release, it did work in that version to declare the 2 global vars in either order. And in any event, the order of the variables for the declarations list should not matter.

To me, this is where the bug is: I'll take Dave's word and your word that your later v7.0 release build 'broke' something and that Dave's test appl. shows this to both of you. But it did work in the original TD v7.0 release. And while we agree that it is not good programming, it is still 'legal' coding.
Jeff Luther @ PC Design
Palm Springs, California
TD info. & samples: http://www.jeffluther.net/TD/

Christof
Germany
Posts: 9
Joined: 06 Mar 2017, 07:27
Location: Frankfurt, Germany

Re: Global variables sequence has effect on initialization timing

Post by Christof » 29 May 2017, 07:04

In the book "dev.pdf" in TD6.0, there is a warning regarding ObjectDestructor and global objects:
Warning: Do not refer to globals in an ObjectDestructor method. The order in which globals
are destroyed is unpredictable and a global that you refer to can no longer exist. You can control
the order that globals are destroyed somewhat by assigning OBJ_Null to them.
(dev.pdf page 8-22, chapter "Creating user-defined objects")
I read this like there was never a guaranteed order of creation or destruction of global objects.

Return to “Bug Reports”

Who is online

Users browsing this forum: Ccbot [Crawler] and 0 guests