Stretchable EffectExamine window

[lordebon]

I've been playing with the EffectExamine a bit, but one thing I can't seem to get right is allowing the window to be resized and have the scroll area inside resize with it. I'm mainly looking to do this to get better screenshots of some of the really long effects in SF raids.

I can get the window itself to resize, but a few things I've tried so far don't get the scroll area and scroll bar to resize with the window. Since I can't think of any effects that require a scroll-bar that I can get on-demand, it's been hard to actually test things.

Anyone mind giving me a pointer as to what I need to change to have this work the way I'd like it to?

[Drumstix42]

Instead of using just the PackSize to to auto-size internal objects, you could try using the OnSize property to manually size things perhaps?

Dunno if that will help or not. Seems like the window's dimensions are set by the server somehow, or just go to the default size of the window. Seems to be the same examining items and what not...

[lordebon]

Originally Posted by Drumstix42

Instead of using just the PackSize to to auto-size internal objects, you could try using the OnSize property to manually size things perhaps?

Dunno if that will help or not. Seems like the window's dimensions are set by the server somehow, or just go to the default size of the window. Seems to be the same examining items and what not...

Yeah, trying to do it via script is what I haven't tried yet. PackSize is what I tried and it didn't work, it never wanted to resize that way (and trying to make it user resizable didn't seem to work either).

[Zonx]

I've played with this some in the past.

IIRC, changing the size settings in XML either doesn't produce any usable results or screws up the hardcoded layout such that lower level elements end up getting cropped by the window frame.

Kinda gave up dorking with it, but I think a workable solution would be to use onHover scripts to dynamically change the required sizing policies at runtime. This way the hardcoded layout can still do its thing, but onHover you can stretch the window.

Since these windows use template objects, to achieve the desired results, you're likely to have difficultly getting lower level object to respond to scripts. You may need to do some detective work to figure out what exactly the final nesting structure is within the window and what the resulting object names actually are.

[lordebon]

Bleh. I've been playing around with it, but no matter what I do script-wise it won't go longer than the existing limit. I haven't really done any fiddling with template objects in EQ2 before, so I'm not sure how (or if it's possible) to adjust the size of things inside the template.

[Zonx]

The main problem with templates is that the name of the final object might not be what the template is named, since it may get repeated. Location and size is also likely to be variable.

This can mean you have to do some creative scripting to work around referencing the template objects by name. Stuff that has worked for me...

First do a simple test to ensure the script event you're using works at all. I typically do this by setting some value to the toolltip, since it provides visual feedback at runtime.

Next test each object to see if you can target it via script at runtime.

If not, use script to check their names at runtime. If the runtime names are at least consistent across instances of the window, try targeting the runtime object names.

If none of that works, try giving the troublesome object an onHover script that pulls the desired values from its parent or variables assigned in the XML.

If that doesn't work, test to see if the template object is executing any scripts. Template objects might not get initialized with the expected event handlers.

If you can't target the object and the object wont fire its own script handlers, you're screwed. Ask Rothgar to look into fixing it.