Zugg Software :: View topic - [1.34] Local Only in child Packages prevents processing of triggers.

Magician Joined: 13 Oct 2000 Posts: 463

I have a Window package (let's call it 'Mud') and a child package (we'll name it 'BB'). I don't want to allow the main Mud window to alter or change any variables in the BB package... nor do I want any code in the BB package altering settings in the main window. So I change the 'Global' setting to 'Local Only'.

Now, my expectation when doing that is that the child window cannot access variables, functions, aliases, etc from outside that package. Code in the package stays in the package, so to speak.

But I do expect that package to still be able to trigger off text received in the Mud window, and I still expect to be able to type in aliases in the command line that are in the BB package and have them execute. But this does not happen. It seems that the BB package is completely cut off from any interaction at all from the Mud window... which makes it kinda useless.

This is not necessarily a bug, but what is the point of the 'Local Only' setting? What use is a package that is set to 'Local Only'? How can you interact with it? It can't trigger, and you can't use its aliases, so what CAN you do?

Posted: Fri Aug 17, 2007 6:21 pm

Create another module in the BB package and make it global. Put things you want to be global in the global module, and things you want to be local in the local module. Settings inside the global module will be able to see settings inside the local module (because modules in the same package are always visible to each other) but settings outside the BB package will only see those inside the global module.

Magician Joined: 13 Oct 2000 Posts: 463

Cool. I created a module called 'Interface', and that's working nicely. Thanks Fang.

Adept Joined: 04 Feb 2005 Posts: 246

Though my tests show that a trigger can't see settings in a local-only module of its package.

Posted: Sat Aug 18, 2007 1:23 am

Strange - I've been doing the same thing with no problems. Try forcing the trigger to recompile after changing the position of the variable or the trigger.

Adept Joined: 04 Feb 2005 Posts: 246

Yup, just confirmed with a package trigger using this code:

Posted: Sat Aug 18, 2007 1:46 am

I have a number of packages for testing things, and I was using one of those to test this. I decided to create a whole new package and test this, and you're right - with this example, it's not working that way.