Zugg Software :: View topic

Posted: Sat Aug 04, 2007 9:34 pm

Whats the trick for getting highlights to show up in child windows again?

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Put the highlight trigger as a child setting under the window module? (Just guessing. I don't use multiple windows myself.)

Posted: Sun Aug 05, 2007 12:30 am

Yes, though "window module" is a bit misleading ;P

If you open the package editor, you'll see two windows. They have an icon that looks a bit like a couple of open windows and when you select them, the title says they're windows. Just create the triggers inside the child window rather than the parent.

Posted: Sun Aug 05, 2007 6:31 am

I moved my entire highlights class to the window module... highlights are still working in the main window, but not in the child

Posted: Sun Aug 05, 2007 8:00 am

What do you mean by "window module"? It should look like this:

No modules involved.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Sorry for using the phrase "window module," but in my tree hierarchy the modules I defined are parallel to my window, so I consider the window to be a module of a specific sort, I guess...

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

That's what they are. The operate on different rules, but a window is indeed a module with a pretty face attached.

Posted: Sun Aug 05, 2007 9:18 pm

Yes indeed, it's just that there's no need to invent a term "window module" when "window" already means the same thing. Shalimar's use of the term coupled with the triggers not working makes me believe that they're in the wrong place - hence asking for more info.

Posted: Sun Aug 05, 2007 10:34 pm

yes, it looks just like that, except the triggers are in a class which is in the child window

Posted: Mon Aug 06, 2007 4:16 am

Did you drag them, or did you cut and paste them? I remember there was a bug a while ago with dragging settings that sometimes caused them to stop working. Might've been fixed, I'm not sure - try forcing a recompile, and then try adding another trigger in that class that's exactly the same as an existing one and see if that trigger starts working.

Posted: Mon Aug 06, 2007 5:05 am

actually, i used the 'copy to' option on the right click menu

not sure if it matters but some of them are stringlist variable highlights

Posted: Mon Aug 06, 2007 5:52 am

That'll cause a problem only if the variables are still in the old window - the moved triggers won't be able to see the variables. Are your non-stringlist highlights working, then?

Posted: Mon Aug 06, 2007 7:04 am

moved the variables and now its all working, but just in the child window...

currently i am using this code for target adding new members off of the 'who' output for my mud... with proper #T+'s and #T-'s:

#LOOP %numwords(%line) {#IF (!%ismember(%word(%line, %i), {@prof})) {#VAR %eval(@prof) {%additem(%word(%line, %i), @{@Prof})}}}

Oh, and after deleting the color folder from the main window, (so i dont try to worry about two instances of the same settings), the color isnt working in the main window.

the names are my main concern for the child window... maybe i just need to reference that the stringlist is in the other window instead of the current highlight triggers i have:

#TR {%q{@stringlist}%q} {#CW color}

Is there a proper way to get the color working in two windows with just one instance of the various settings?
I really want to get away from having duplicate settings.

Posted: Mon Aug 06, 2007 7:13 am

Yes there is. This behaviour of windows is deliberate - settings inside windows are only visible to that particular window unless you reference them explicitly. So you have two options - you can use the //moduleorwindow/class/varname syntax to reference the variable, or you can create a module (which is the way I'd do it).

All you need to do is create a module as well as to the two windows and put shared settings in there. While settings inside the child window aren't visible to the parent and vice versa, settings inside the module will be visible to both. You should end up with something like this

in contrast to my earlier example. You don't need to reference variables in the module with the //moduleorwindow/class/varname syntax as long as there are no other variables with the same name. The only thing you should need to put in the module is the mutual variable, though you might find it useful to put shared triggers and other things in there as well.

Posted: Mon Aug 06, 2007 7:40 am

okay, i tried this

deleted the color class (with all variables and triggers inside it) except for the copy within the new module.

now no color works at all

went back to the module, changed it to global instead of local, and still all the color is now dead

Posted: Mon Aug 06, 2007 7:49 am

The global/local setting should be irrelevant - as long as it's not external, you should be okay.

The first step would be to create another trigger in the module (could be anything) to see if it's firing in the windows. This is working for me (if I type #fire "highlight trigger" on the command line of either window in my example above, the trigger fires). If this is working, it's a problem with your script and not a problem with the scope. If it's not, then something much stranger is going on.

Posted: Mon Aug 06, 2007 7:51 am

not only that... but now all of a sudden, all my blank spaces are showing up as having an orange background.... something odd is definately going on

Posted: Mon Aug 06, 2007 8:04 am

okay i figured it out... somehow in all the shifting around, all my variables got deleted, and since one of the triggers had a orange background... that was causing my trouble... now i just have to repopulate my variables... a nuisance, but i can manage

thanks for your help, stuff is at least now working