Zugg Software :: View topic - [2.03] Variable scope in multiple packages.

Magician Joined: 17 Apr 2005 Posts: 496

If you have a global module with some variables, then triggers from other packages which assign values to variables will use [those variables], even if the package containing the variables is not enabled for the module containing the trigger. Aliases from other packages will NOT use [those variables], unless the package containing the module is enabled for the module containing the alias. Could this be standardized, preferably to the first method mentioned?

Posted: Mon Sep 10, 2007 3:35 am

I believe this works as expected. Remember triggers always run in the context of the window, so if the Window has these Global modules enabled then the triggers will have access to them. Aliases work as described and expected. If you want access to it, you have to enable the module.

Magician Joined: 17 Apr 2005 Posts: 496

I think it would make more sense (and be easier besides) if aliases inherited the context of whatever called them. Aliases on the command line would have the context of that window, aliases in triggers would have the context of the trigger which would be the window, etc. Anyway, just my two gold.

Posted: Mon Sep 10, 2007 11:52 am

Aliases don't have to be called from the context of a window. They can be called by events, directions, the mapper, room scripts, anything. Triggers are always triggered by text appearing in a window.

Personally, I agree that the inconsistency outweighs any benefit having it this way round might give (though I honestly don't know what those benefits are...). But that's the logic for having it this way.

Magician Joined: 17 Apr 2005 Posts: 496

That's what I think is best about the inheritance idea. Almost* everything could eventually be traced back to a window, after all, events don't just raise themselves. You could have an event raised from an alias which was called from a trigger that was triggered by text in a window, and it would set one variable, and then you could have it raised some how from a different window in a different package and it'd set the variable in that package instead (going up the different levels and checking to see if that variable exists at each level)... Anyway, I think it'd be neat.

* The things that wouldn't would be include right click > Execute Script, and some of the triggers like alarm, etc., when they're used as the first or only state in a trigger.... Interestingly enough, using execute script on a trigger in a separate package, which shouldn't be able to see the variables I'm talking about, was still able to set said variable.