Access project script from a Gateway Timer Script?

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?

gtwy

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:

  1. Where the script is actually being executed. This is the client/designer vs gateway scope.
  2. 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?

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. /:

2 Likes

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.

1 Like