Zugg Software :: View topic

Adept Joined: 18 Jun 2019 Posts: 279

So now, all of a sudden, a shitload of triggers are looping. How this is possible when only ONE trigger definition exists ANYWHERE in ALL of the code in all of the packages, is a mystery.

These triggers have been in existence for more than a year.

This doesn't seem like a code problem to me...AFTER MORE THAN A YEAR!!

For what it is worth the affected triggers have CAP and/or GAG statements.

Anyone have anything similar?

Posted: Mon Apr 04, 2022 11:48 pm

It sounds like the trigger is somehow visible to your child window, so it fired there and reprints to fire again.
Check the enabled packages on the advanced tab of the window in the settings editor.

I gave you the code to fix these issues over here.

Adept Joined: 18 Jun 2019 Posts: 279

Well here is the confusing thing, and I have never understood it:

Installed package has the scripts, triggers, etc but windows are always listed in the main session. If the package fires a trigger to capture text, it needs access to the main session (which they have) and the only selections are main session and package itself.

So yes, the triggers ARE visible to the child windows as the triggers are IN the packages but the windows are in the main session.

Eg., #TR {Character autosaved at} {#CAP INFO}

The trigger is in a 'channels' package but the window always appears as listed off the session tree. The only triggers writing to this window are from the main session and the 'channels' package.

Posted: Tue Apr 05, 2022 2:11 pm

It's a scoping issue.

Triggers (and other settings) are housed in the main (named for the session) window object by default, which acts as if it was a higher-tier folder than class objects.

Window objects by default aren't visible to each other. So they don't have the scope to react to whatever settings are housed in other windows.

Packages are typically global in scope, so everything in your session can 'see' them by default. But this behavior isn't always desired (as you have found out).

So you have the option to toggle which packages a given window has scope (access) to.

But as I explained in the other thread, there is a bug in which CMUD being forced to close from a system update can often re-enable all packages to all windows.

However, if you put the #FUNCTION and #EVENT from that other thread into each of your custom packages, it will ensure that only the main window of your session will have access to that package.