Quote:
|
Originally Posted by taylor13
Also, has anyone ever tried putting the HoTT window INSIDE the target window (or any other window for that matter)? Wouldn't that allow usage of the specific screenid which would cause the % labels to disappear? The only detail would be, what would happen if someone tried to open the window normally? =/
|
I've tried all sorts of ways to ''hijack'' ScreenID's to use them in another window, but have never gotten anything to work. EQ only makes use of a ScreenID once, so if it's in two places (even twice within its ''home'' window) only one instance will get the benefits of the ScreenID. In addition, when the HoTT window (as an example) is made a child of the Target window, its contents become children of the Target window as well, so HoTT-specific ScreenIDs stop functioning.
The only success I've had is where existence of one object can be toggled, so two objects with the same ScreenID can coexist, though only one is functional at a time. If memory serves, you can create a child Screen object with a close button, put a ScreenID'd object inside and one outside of it, and ordered so the one inside the Screen object is functioning. When the Screen object is ''closed'' the ScreenID'd object outside of the now-closed Screen object starts functioning.
Embedding the HoTT window in the Target window is also a pain due to the ordering of the two windows' XML files within EQUI.xml. You either need to edit EQUI.xml to change the order, or gut the Target window XML and put its contents in the HoTT window's XML file.
Basically, one solution would be for SOE to add ScreenIDs to the target window specifically for HoTT-related objects for UI modders to make use of. They've actually done this for the group window to add support for putting player information (mainly Role-related) by enabling ScreenIDs for group member ''0'' (zero).
Enok