Close Button that just makes window page visible=false?
 

I've been tinkering and working on some improvements for my browser window mod. It's always a challenge to figure out what is hard coded into the UI and how to work around those things.

I noticed that there are a lot of ways to make a close button. Most of the default windows have the close button as AnyWindow.WindowFrame.Close. The names "WindowFrame" and "Close" can't be changed. Some old style windows have a button called "WC_CloseButton" but this button seems like it has to be at the first level of your window. I just saw some other windows where people just Parent up to the top of the window and set Visible=false.

Is there any real difference with these methods? I'm going to be using "WC_Titlebar" and "WC_Frame" to store some settings so I'll have to use something other than the normal WindowFrame.Close button.

If a window supports a close button, I tend to use that one to be on safe side, but you can usually macro a /hide <Window> as well.

If you want to use a close button on another level, you can put a WC_CloseButton in your window root, set it to visible=false and use another button whereever you want that presses the WC_CloseButton when you click it.

The old WC_ notation and the new "WindowFrame" formats are identical in function.

You can also just invis a window, but it will still be there and active and not be closed - e.g. an invis chat window still receives chat input, whereas a closed chat window will not.

Ok, I'm going to try seeing what a WC_Closebutton at the first level of the window does. I just tried Parenting to the first level and setting Visible=false and an unintended feature is that you can close and open the browser window and the browser is still exactly as you left it.

I just wonder if this is more taxing memory-wise than a normal close button. I only hear my hard drive loading up the Mozilla DLLs the first time I open up the browser.

That's what I meant, just setting visible=false keeps the window active and thus using resources.

The windows are loaded from disk the first time you open them in game. Afterwards they stay in memory even after you close them. However, the engine keeps two copies of it, a copy of the file on disk (in the root tree) and a copy of the active window you are seeing (in the root._HUD tree). Closing the window resets that second copy. Logging to char select also resets the entire active tree but keeps the other tree. However, you can also script changes to that one to make changes persistent over different characters (it's not written to disk however).

Whether that also applies to the Mozilla DLLs as well (which I doubt) or whether you just don't hear your hard drive because your operating system kept those DLLs cached in memory I cannot answer.