Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

I don't know if this is a bug or what. However, I seem to be having problems with enabling and disabling classes and triggers.

For example, if I have a trigger "This is not a test" and the value is:

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

If you're doing it wrong, it happens to be a method that is working for me.

Try setting it up in the Untitled session. If it works there, then the issue is purely with your package, either something related to corruption or compile issues (ie, syntax error or glitch somewhere) or to the specific usage you're trying to do (ie, not a bug, just something you are deliberately not allowed to do).

You reinstalled recently, I recall? If you haven't had any AVs since then, I'd start considering redoing all your (problem) packages by hand--no importing, no .MUD file conversion, no copy and pasting. If they are old enough to cross several versions, they're probably suffering an artifact left over from a fixed bug.

Yeah, it's not fun, but if that's where the problem lies then reinstalling or upgrading isn't going to fix anything.

Wizard Joined: 17 Jun 2006 Posts: 1201

#Trigger {This is a test.} {#T+ Tracking/Test}

Is that wrong?

Anyway, I thought Zugg stated somewhere that we should be able to export to XML and then reimport it to get around these corrupted files every time? If every single time I install a new version, it is going to corrupt my package files I think that is ridiculous. This was never a problem with Zmud because they were simple text files.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I noticed this in this version myself. Oldguy did this work in 1.34?

To get it to work I had to do "#T- PackageName|class|subclass" I'm pretty sure "#T- PackageName/class/subclass" Will work too. I don't know if this was a new issue or not. Time constraints and all that jazz...

Wizard Joined: 17 Jun 2006 Posts: 1201

No. Sometimes it does and sometimes it doesn't work in 1.34. It always works if I put it in an alias though so that is what I did. I was using aliases on some of them anyway to make it easy to implement disabling a class throughout a variety of triggers.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Well, the alias thing is also proper. I just didn't want to go through all of my settings and do that.
I could say it was laziness but on the other hand I went through and added the package name to everything so I guess the laziness is moot.

The thing is with trigger scoping they look in the window settings that caused them to fire.
Aliases on the other hand look in the package that they are in.

Posted: Mon Nov 05, 2007 7:57 pm

Keep in mind that:

#T- Tracking/Test

is a *relative* path reference. This says to disable the "Test" class, within the "Tracking" class, within the *current* scoping class. If you do this within a trigger, then it will be relative to the current class of the window that causes the trigger. If you do this within an alias, then it will be relative to the current class of the module that contains the alias (unless the SetAsDefault option for the class containing the alias is enabled, in which case it is relative to the class containing the alias itself).

So, as you can see, the above command depends upon a lot of stuff. That's why you need to be careful with relative references. You probably want to use:

#T- /Tracking/Test

instead. This is an absolute reference within the current window/module. And for most people who just have one window, this is all you need. If your trigger or alias is running in a different window, then you might need the syntax

#T- //ModuleName/Tracking/Test

However, the *best* way to handle all of these issues is to just make sure your class names are unique. If your classname is unique, then you can just do:

#T- Test

and it will search for the "Test" class within the current scope. In this example, "Test" is probably a bad name. But if it was something more specific and unique, then it wouldn't matter what the current class was...it would search the available scope (looking in the current class first, then the current window, then finally any global or external modules) and will find the class no matter where it is.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

I am confused

I thought to disable a class you now used the #CLASS command and to disable triggers you use the #T command.

In one of my scripts I have two triggers that I wanted to disable at the same time so I thought I would put them in a class and use the class command but that didn't work..

So when I disabled the class it just disable the class but not the triggers in the class, which I thought was unusual.

Posted: Mon Nov 05, 2007 9:16 pm

The #t- and #t+ commands can be used to disable or enable any kind of setting - there's an optional parameter to name the type of setting to avoid naming conflicts. I prefer #t+ and #t- to the #class command because it can't accidentally create classes.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Thank for the information Fang.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Giant list of questions moved to a new thread to avoid threadjacking.