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 onlycallMyProjectScript()?
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
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!
Where the script is actually being executed. This is the client/designer vs gateway scope.
Where the script is defined. Basically, everything you configure in the designer (with the exception of event scripts actually on tags) is scoped within a particular project (even if it’s being run on the gateway!) - thus, even though gateway timer scripts, as the name implies, are executing on the gateway, they are still within the context of a particular project, and thus implicitly have access to that project’s script library.
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?
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.