Initialization of global using component properties

I understand that global variables can only be be initialized with values already defined - no function calls, no other global variables, etc. Attempting to violate this rule should illicit an error.

One might also expect readable component properties to be off limits (until after ScreenX.initiaize is called). However, in the example below, I do not get an error when I use Clock1.TimerInterval to initialize a global variable.

Clock1 has TimerEnabled and TimerAlwaysFires boxes checked and TimerInterval set to 15000.


When Button1 is clicked, the following is displayed:

There is no error indication, but rather an incorrect value is displayed for the global variable "Interval". I am guessing that it is no coincidence that the displayed value, 1000, is the "default" value of TimerIntervali rather than 15000 which I set in the design section.

I assume the way to fix/workaround this would be to re-set the global variable "Interval" early in Screen1.initialize to Click1.TimerInterval.

But is this a bug? another set of objects (component properties) that cannot be used to initialize globals? something else that I do not understand?

Thank you for reading thus far and for any comments/help you may offer.

Kind regards,

1 Like

while the global variable initializer allows you to reference components and their readable properties

Well, I guess that is my question: "are you allowed to reference component properties in global definitions?" I would suggest that if the values are not predictable, referencing them is not of much use (even dangerous) and just as well be prohibited (in documentation and an error generated at compile or run time) - correct?

BTW, I did see that post from last year, and, while it addresses how to work with this type issue, I did not get a clear indication as to whether or not AI2 is designed to require such a workaround - making it not a workaround but a required syntax.

Kind regards,

It is simply a timing issue (excuse the pun)





I would prefer to not defer initialization unless it is necessary.

Hence my question: Is this behavior a bug which might be corrected, or is it the intended functionality: invalid syntax but tacitly allowed (compile time and run time)?

Further, if intended behavior, I'd vote for some form of an empty/NUL/zero expression like a numerical zero, an empty text string, etc. But maybe that's being too picky :slight_smile:

Kind regards,

You are allowed to do it, but in your case as @TIMAI2 explained

so just don't do it... imho it also does not make much sense to do it... why using an additional global variable? Kiss - Keep it simple stupid


Hi Taifun,

Thanks very much for chiming in!


And in my application, that's just what I did... initially... I simply read from the clock's TimingInterval when I needed it - but the pause/resume technique I used (perhaps a bad one :slight_smile: ) involves noting the time remaining in the game when it is paused and then on resumption (of the game) setting the game clock TimingInterval to the time remaining that had been stored when it was paused

Elsewhere in the code I when I referenced the original GameClock.TimingInterval - OOPS - this cannot be relied upon to have the full game time (initial) value, since it could have been paused :frowning:

So I added a global variable for the origina lGameTimerInterval which would never be modified. I simply initialized it on declaration using the GameClock.TimerInterval... which was set in properties to15000.

[BWT, this app is a modified version of the "Whack-a-mole" tutorial.... surprisingly 2 of my grandkids like to play it.... so there are other timers also (mole movement timers) whose initial property value is 1000. I decided to go ahead and create a global variable for them too, in anticipation of an enhancement I was considering... so what I observed is that the GameClock timer TimingInterval was read incorrectly while the mole movememt timer values SEEMED to have been read correctly - of course, they were not read correctly, they simply had the initial design component value of 1000.]

So, bottom line: I am ok with doing what has to be done, but I would hope that somewhere in the documentation this is pointed out...and/or in the future it is trapped by the compiler or runtime.

In my humble opinion, this is not a bug that beginner, grade school programmers should have to deal with in their code...

Me? I can take it! I am 74 and began coding over 50 years ago ([Fortran IV using punch cards on an IBM mainframe and assembly via paper tape on a H316 )... although it probably took me far too long to find this bug in my code. :grin:

Kind regards,

1 Like

My first FORTRAN was Kingston FORTRAN 2.

Your problem needs the Clock component's Milliseconds since 1970 value to capture start times and deadlines. You get it from Clock1.Systemtime, and it is a math-friendly integer.

The Timing interval can be left at one second once you transition to checking current time against deadline timestamps.

Well, I am sure there are better ways to do it... But the end-of-game and/or bonus round processing is done from the timer event, so it seemed easy enough to postpone its firing by disabling it during a pause and then re-enabling it with time remaining set as the TimerInterval when it is resumed.

Fortran II - first time I can recall ever hearing of it...

Ahh.... the appearance of the user defined subprogram and the COMMON block. Now that's some programming power! :muscle: