When used in a procedure called in a timer, info('trigger") returns “Menu.View.” followed by the procedure name. This was unexpected. I haven’t seen Menu.View in a trigger before, and it seems rather obscure when applied to a timer. Are there other triggers in which Menu.View would be returned, or can we rely on it being returned only in timers?
There is no triggering event for timer code, so you shouldn’t use info(“trigger”) in timer code. That function is just going to return whatever the last trigger event happened to be, which apparently in your case was an item in the View menu. But it could be anything. To close – don’t use the info(“trigger”) function in timer code, because it doesn’t return anything informative.
It would be kind of a weird case, but I suppose you could have a procedure that was called by a timer code and by some other sort of code, for example a button. In that case, you could use settrigger in the main timer code.
settrigger "My Timer"
call "Generic Action"
Then in the Generic Action procedure, you could use info(“trigger”) to determine whether it was called by a button, a menu, or your timer. However, even then, I think a better approach would be to add a parameter, for example
call "Generic Action","My Timer"
or when called from a button, use
call "Generic Action","My Button"
Of course these parameter values are just goofy examples, you could probably come up with something better that is more meaningful for your application.
Thanks, Jim, glad I asked. I’ll set a fileglobal with a value earlier in the timer, like fTrigger = “timer” (after having initialised it with null in .Initialize) to be able to allow the procedure to respond as required.
If you do that I think you’ll just have the same problem for the same reason. Your fileglobal value won’t disappear once the timer ends. So if some other procedure checks the value of that variable after the timer runs, it will think the timer is still running. If no other procedure is going to check the value, then why do you even need a variable?
I feel like I’m not being super constructive here, but that’s because I don’t know what you are trying to do. I’ve never needed timer code to know “why” it was triggered – if the code is in the timer, then that’s how it was “triggered”. It can’t possibly be triggered any other way. If some other code needs to know that, I question the modularity of the design. If at all possible, I don’t think any subroutine called by a timer should need to know that it was called by a timer, in fact a subroutine usually shouldn’t need to know anything about the code that called it. To the greatest extent possible, a subroutine should stand on it’s own.
Your fileglobal value won’t disappear once the timer ends. So if some other procedure checks the value of that variable after the timer runs, it will think the timer is still running.
Not if the timer code is
code {
fTrigger="timer"
Call ProcA
Call ProcB
Call ProcC
fTrigger=""
Call ProcS}
Procs A, B and C can be run individually from menus as well as being called by the timer. Each of them calls the same ProcS, but it’s quite long so I don’t want it to run over and over in the timer, just once after A, B and C are all done.
But as you suggested I’m going to pass parameters to suppress their three calls to ProcS, as this is neater and self contained, not requiring the external variable.
code {
Call ProcA,"timer"
Call ProcB,"timer"
Call ProcC,"timer"
Call ProcS}
1 Like