Following the suggestion here Can I call a Project Script from a Gateway Timer Script?
I’m trying to read a project script variable from a Gateway Timer Script. The Gateway timer script errors with (name 'Gages' is not defined) where 'Gages' is the name of the project.
The line of code in the Gateway Script is Gages.Globals.printCount
params = {'msgID':'timer test',
'message':Gages.Globals.printCount,
'msgSource':'msgSource'}
Can anyone help?
This should be Gages.Globals.printCount() you are missing the () .
I get the same result with and without the ()s
Gages.Globals.printCount is an integer type variable if that helps?
The Gateway script (below) line with arrow is erroring
Possibly the project must be flagged as Inheritable?
Inheritable (and the ‘Gateway Scripting Project’ setting) are irrelevant here (making the project inheritable would guarantee this wouldn’t work, actually). You’re not leaving the project scope, even though you are executing on the gateway.
What happens if you move the try/except block you have in the timer script into a(nother) project library script? So the gateway timer script becomes only callMyProjectScript()?
If I’m understanding correctly. . . When I remove the try-catch error handling nothing happens at all. Nothing is logged via system.db.runNamedQuery. The only way to see the name 'Gages' is not defined error is by looking at the gateway logs
I removed the project name ‘Gages’ from the problem line and it works now. (see pic)
It’s confusing though I thought this would be out of the scope of the individual projects because it is (on the Gateway)?
Edit: If this matters, I am accessing the menus (Project)(Gateway Events)(Timer) from within the (Gages) project. But still, my understanding was that these scripts (Gateway Scripts) ran on the Gateway with a different scope. Regardless I seem to have gotten around my issue and appreciate you going over it with me. Thank you!
Oh. Right.
Okay, this takes some setup.
There’s two orthogonal concepts here:
As a related point - there is no way to conditionally reference or otherwise ‘qualify’ a reference to another project’s script library. You are either using your own script library (which could have inherited resources in it), or in the case of e.g. scripts on tags, since there is no associated project, you’re using the ‘Gateway Scripting Project’.
Out of curiosity, is there a defined reason as to why this shouldn't be allowed? Lets say we have a gateway with several different projects that essentially act as script libraries, that can all be individually managed and updated through git. As well as a project that implements some but not all of those scripts, since you can only have one inherited project than you must put this all in one project, making it harder to version control the separate individual sup-libraries inside of it.
Being able to fully qualify a script in another project would allow you to have multiple independantly controlled llibraries all in different repositories, but accessible to one or many projects?
My immediate thought would be that, effectively, we would have to always reload all scripts anytime any project updates its project library. That would be a big penalty for a very marginal use case.
Does that already happen for an inherited project? And furthering the question, is there a reason not to allow multiple inheritance for this same case?
What you are asking for is effectively multiple inheritance. Sorry, that's like, a big deal. Don't hold your breath.
Yeah I agree that's exactly what I am asking for, I guess my question is, is there a reason it shouldn't happen, more than "its a lot of work and likely wouldn't happen any time soon"
The best opportunity for multiple inheritance has passed. IMNSHO, it should have been implemented instead of hierarchical single-inheritance for v8.0. But nobody asked me. Huh.
Mixing hierarchical and multiple inheritance is horrifically complicated and likely bug-prone. So, not just a lot of work and not any time soon, but risky to deploy. /:
It's an explosion of resolution complexity, with associated maintenance and quality assurance burden.
It's hard, just on its own merits.
You're only asking for it in the context of scripting resources, but the obvious followup would be "why can't I do it for X resource type"? Also, inserting "special" behavior for special resource types is a large part of why 7.9's resource system was so fraught with weird edge case behaviors - right now, we're consistent throughout, which is a huge boon overall.
Last, as I alluded to - while it definitely would be useful to folks like you and Phil...it probably wouldn't be useful to a lot of our customers. The business case to justify a shakeup that fundamental probably just isn't there. I've learned to never say never, but right now the calculus just doesn't make sense.
Yes, 'upstream' changes to a project library will kick down to inheritors.
We are having an issue that might be tangentially related. Occassionally when we open a specific project (called the Gantry project) in the Designer, the timer scripts will suddenly stop executing. To fix this, all we have to do is Save or Update the project from the designer.
The issue happened again today, and I discovered errors in the logs that corresponded to the Gateway Timer Events:
The odd thing is that the package the error is referencing (called "project") is in the project that is executing the gateway event.
My working theory at the moment is that the Designer must be somehow "checking out" the script when it first opens, and if the timing is just perfect, it might somehow cause the Gateway to not see the scripts or packages until the Designer has merged its changes with the Gateway.
We have other projects which also have Timer events, and we have only seen this issue 1 time with any of the other projects, but the Gantry project is executing the Timer script every 1 second, which is why I think we see it more often with this project.
Any idea what might be happening?
