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.
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.
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
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 ) 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
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.
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...
) 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
