The way I handle this sort of thing is to provide a custom "Settings" window tied to the window you need variability in. The settings window has a series of "Preset" buttons you manually click to load up the settings for a particular class/scenario. These then pull the values from a file embedded as a separate include for easy editing out of game.
While this approach does require the user to select what they want, the nice thing is that they can have more than one setup for a given class, for example a "Raiding" set and a "Grouping" set.
Let me rephrase my earlier comment...
Zoning is known to sometimes re-initialize entire windows. This means any values set to said window that aren't fed directly by DynamicData, the client's hardcoded functions, or embedded in the XML files may be tossed.
Your class check should be setup to fire any time the dependent window is shown.
The technical reasons for anyone that cares...
Window XMLs are read by the client and used to instantiate objects in memory as needed. These object typically persist and are what receives any changes applied at runtime (changing text, variables assigned by script, etc).
Occasionally the client will try to do some memory management to free up system resources (most likely during zoning but could be any time). When this happens, it may decide to ditch a window object from memory and only reload it from the XML if needed. When a window in memory gets tossed, any settings made at runtime are lost. DynamicData and changes made by client functions are reapplied automatically, but script changes aren't unless they are somehow tied to the window's initialization.
From what I can tell, there is a prioritization to what windows get tossed from memory first. Custom windows are first to go, followed by anything not in MainHUD. Using the /hide_window xxx command also seams to immediately ditch the window.
|