HOWTO: Docking window WITHOUT user controlled dummy window

Agathorn · #1 12-06-2005, 09:55 PM

Hey all,

Thought i'd post this since I hadn't seen it done before and I like to share knowledge. If this has been done before then I apologize and feel free to shun me asa newbie

Anyway.. When dealign with dockign windows, IE a window that the user can click a button to make it shrink to a smaller size, quite often the mode of attackis to make a second "dumm"y window and when the user clicks the button you set the main window's location and size to that of the dummy window. In order to position the real docked window the user has to position this dummy window. IE The Fetish 6 way inventory.

One thing I always hated about this approach is it was not very user friendly in my eyes. I'm certainly not knocking the approach, as it is very clever and does a good job. I used it myself. However, after dealing with a confused user today I decided to take another look at the system and see if I could take it a step further and eliminate the user having to manipulate this "dummy" window so that it would be a lot easier and less confusing. I have come up with a solution so simple it practicly slapped me in the face but apparently so simple it was being overlooked. Really to make this work you only need to take things one step further. You still have the dummy window and use it for positioning and size but -- and here is the key in my mind -- the user never has to see it, touch it, or even know of its existence!

Let's say you have a checkbox that when checked it docks the window and when unchecked it undocks the window. When the user checks the window the window's location and size are set to the dummy window. On uncheck they are restored to normal. All you have to do is add some code to OnUnset so that when the user unchecks the button to restore the window to original size and location, you first update the dummy window with the current docked windows information. Whala.

Now when the user checks the button and docks the window, they can drag that window around to position it where they want. When they undock it its new position is updated and saved into the dummy window so next time they dock it boom it goes to where they put it. The dummy window still exists but is never seen or touched by the user.

I'm attaching the new Serenity UI Inventory window here as a sample for those who would like to see code. The dummy window code is currently in the eq2ui_inventory.xml file. I apologize for that but when I first made this I goofed upon placement and haven't gotten around to cleaning it up yet.

Merry Christmas and Enjoy!

Talyns · #2 12-06-2005, 11:16 PM

That's new.. I tried that when I built the my minimap plugin for the EQ2Map project. Me and zonx played around and discussed it back then.. We found that, you used to have to actually move the dummy window with the mouse for it to save location.

http://www.eq2interface.com/forums/s...ead.php?t=2839

Great find, Glad they updated the way the location saving works. Now I want to come back and play around with UI's just to see what else they've fixed and added.

edit: Something else I was thinking back then.

If it saves whether frames and titlebars are visible on the dummy dummy window you should be able to set it up to remember if the window was docked the last time you logged out also

Agathorn · #3 12-06-2005, 11:23 PM

Ahh crap. Well then. Guess I just stuck my foot so far into my mouth i'm chewing on my knee

I never even stopped to think about whether or not it saved to the INI file. I mean why the heck wouldn't it!

Well it doesn't so apparently the same issue you had before still exists. Crapola x infinity. Stupid bugs

Geesh who would have ever thought it wouldn't save.. wtf

Well ignore everything I just said. I'll just go stand in the idiots corner now

Talyns · #4 12-06-2005, 11:28 PM

That's a bummer, I don't understand the way they save locations.. It should save every location, size and state of frames, titlebars, and locked when you exit the client..

Sorry to burst your bubble.. I thought they actually added one of my wishes

Agathorn · #5 12-06-2005, 11:34 PM

I thought maybe it had somethign to do with the window being visible.. maybe.. so I tried togglign the window state to see if that woudl save but no.

My guess is the way the UI works is that whenever you drag a window, part of that movement code saves the window state. Apparently at logout it doesn't poll all the windows and save state which you would think it would do.

So terribly sorry about the false start

Morpheusdead · #6 12-06-2005, 11:39 PM

this is possible ONLY resizable windows save their location to the .ini to set the window to be user resizable and put a onhoverin of usersizable=no see when they mouseover it becomes non resizable but when not moused over it is resizable there fore the game saves its location to the user ini and walaa is this the answer to your problem??

Deathbane27 · #7 12-07-2005, 12:06 AM

Quote:

Originally Posted by Morpheusdead

this is possible ONLY resizable windows save their location to the .ini to set the window to be user resizable and put a onhoverin of usersizable=no see when they mouseover it becomes non resizable but when not moused over it is resizable there fore the game saves its location to the user ini and walaa is this the answer to your problem??

Nope: it saves the location of the default player window, map window, inventory window, persona window, etc. even though they're not resizable.

The character ini file will save any user-made changes, but no UI-scripted changes.

Laffs · #8 12-07-2005, 09:07 AM

I have used docking windows in a few of my mods as well but never had any problems as the page that snaps to the docking window is not user movable anyway ... But the window as a whole is.....

If "clickthrough" would just hold its setting then you could just make the docking window / dummy window as you call it full screen then set pack location etc etc maybe?
I mean if its full screen then no need for anything to save its position lol (well maybe "allow windows offscreen" would fubar this but I dont think so)

Agathorn · #9 12-07-2005, 10:33 AM

Really I think if we could just get it so that custom scripted proprties on a window saved to the INI, then a huge door of opportunity would open to us. Then we wouldn't even need dummy windows at all, we could save locatio/size information in cusotm fields in the xml. We could save states of window settings, advanced options, etc could all be saved and loaded properly if only cusomt properties would save with the window

But if wishes were horses... (never did understand that statement lol)

**Drumstix42** · #10 12-07-2005, 01:42 PM

Quote:

Originally Posted by Talyns

That's a bummer, I don't understand the way they save locations.. It should save every location, size and state of frames, titlebars, and locked when you exit the client..

Sorry to burst your bubble.. I thought they actually added one of my wishes

Yes, and it should save in an easy to read INI file like EQ1 *cough cough*.

**Zonx** · #11 02-25-2006, 04:09 PM

I've long had my suspicions about what's actually happening with this, here's what I think...

I suspect there are actually 2 location and 2 size properties, similar to how text objects have LocalText and Text properties. The commonly used "Location" and "Size" properties are the equivalent of LocalText, i.e. temporary values that are never saved. Scripting size and position changes to these likewise will never be saved.

However, there are other location and size properties we haven't discovered, or just don't fully understand, that are saved if the window is set to UserMovable and UserResizable. The only reason we're getting saved loc and size when changed by a user is that the hard coded event handler is updating both the temp and save values. I'm betting scripted changes would likewise be saved if the mystery save values were updated.

So the big question is, what are these mystery props?

I suspect they are PackLocProp and PackSizeProp, I just have never had the chance to dork with scripting them. Frankly I'm not sure the scripting lang can handle what may be needed to set these properly ingame. I believe some of the atributes for these props are derived form other factors like current screen size to default size ratio. Still, it may be possible to do some basic stuff with it, like pass it to a variable to be used in restoring window state.

Maybe someone with more time than I can play with it more

mother9987 · #12 02-25-2006, 06:13 PM

There might be additional hidden properties, but I don't believe their the pack ones. In messing with my map spoiler project, I dumped the pack properties completely from the text files to shrink my files... The game client recalculates them when the window loads.

So, I don't think that is the right path. Interested in anyone else's findings though.

**Zonx** · #13 02-25-2006, 07:55 PM

They may not be the props used, but not having them in the template doesn't really rule out the posibility. Here's how I think its working...

Client reads the template and creates an instance of the window in its workspace (_HUD) at the default "Location" established by the template. It then checks if the window is set to UserMovable. If true, it checks the character.ini for a saved PackLocProp and moves the window. If false, it recalculates the PackLocProp.

Once in game, the client's OnMove handler sets Location and recalcs the PackLocProp. OnSave it again checks for UserMoveable. If true it saves the PackLocProp. Notice how this doesn't depend on the template having a PackLocProp.

If my guess is correct, the problem stems from not recalcing the PackLocProp from script. Even if the window is set to userMoveable, the last drag location is saved and not a subsiquent script move. Easy enough to test this using a text field populated with the PackLocProp value of a window with some buttons to move the window via script. If the Prop changes with a script move, these aren't the properties being saved. If it doesn't change, there's a good chance they are what's dumped to character.ini.

Deathbane27 · #14 02-25-2006, 11:01 PM

Good plan, Zonx. I'd also do something to check that it does, in fact, update PackLocProp on a user drag.

**Zonx** · #15 02-26-2006, 01:35 AM

Yah, I'm also interested to see if the prop changes when screen reso is different than default and PackLoc is set to proportional. I'm betting it does, which is why they don't care what the template's Prop is.

I'm of the oppinion PackLocProp in the templates is mainly for optimizing nested object positioning, not windows.