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.

[lordebon]

Yeah I plan to mess with it some more this weekend. For simplicity I've just been using a button to do the actual script execution (that way I know it only fires when I want it to). Thanks for the suggestions, Zonx.

==EDIT: Posted for my reference==
Tooltips on DotTemplate and PlainTemplate don't work. OnHoverIn on DotTemplate doesn't work. OnHoverIn on PlainTemplate DOES fire. Also, each individual dot on the effects line seems to be an instance of PlainTemplate. All of which seem to be have Name=PlainTemplate =/

Ok, now I can get the scroll bar to get big, but the SpellEffects area is still small.

[lordebon]

Hmm. Well I can get the scroll bar to be longer now, and I can change the size of the "SpellEffects" page (observable because the scrollbar seems to get placed inside it and I can make it get clipped by changing the SpellEffects page size).

But even with extending the size of the SpellEffects page there is something that refuses to get bigger. (I've attached a screenshot of it -- you can see the SpellEffects page clipping the bottom of the scroll bar as well as the text staying stubornly in the same area).

At this point I'm starting to think that it's just hardcoded to stay that size, either that or it's in some kind of other page that I can't find.

[Drumstix42]

Okay, I did a lot of messing around with this because I just happened to be doing some edits with examine stuff...

Anyhow, this little bit will make you happy.
Remove or rename the ScrollTemplate object and you'll have a "close to desired" result (attached image).

Note, I wasn't in raid to try to grab any longer effects, but you could set a max size to the window with a scrollbar that affects the whole window perhaps?

*edit* and yes small effects will still show normally.

[lordebon]

Originally Posted by Drumstix42

Okay, I did a lot of messing around with this because I just happened to be doing some edits with examine stuff...

Anyhow, this little bit will make you happy.
Remove or rename the ScrollTemplate object and you'll have a "close to desired" result (attached image).

Note, I wasn't in raid to try to grab any longer effects, but you could set a max size to the window with a scrollbar that affects the whole window perhaps?

*edit* and yes small effects will still show normally.

Ahh thanks Drums . I never thought to completely remove the scrollbar. I can try putting one on the whole window like you said, although I can live even without it hehe.

[Zonx]

So here's what's likely going on behind the scenes...

You've got template objects with dummy data in them.

Templates get cloned with the same object name. This basically produces an array of objects with the same name, only we don't have access to the array or the internal object IDs. Say you have templatePageName="Foo".

Foo gets cloned at runtime, so you end up with

templatePageName="Foo"
templateCloneName="Foo"

Since the original template exists above the clone in the object tree, referencing "Foo" from outside always accesses the template and not the clone.

Scripts placed on the template should also get cloned, and should be able to access sub-objects or parent objects normally. The problem is referencing the clone from outside.

You might be able to use the OnTextChanged event for a repeated text object contained inside the scrollpage to change its parent's PackSize when the window is loaded. If PlainTemplate is inside the scrollpage, try that.

[Drumstix42]

Trying to manually set, lock, and force the scrollpage to a certain height showed no response via the scripting that I attempted. Not really sure what's going on behind the scenes.

I think with some more meddling you could probably get a cleaner outcome, but with most likely a messy coding work-around

[Zonx]

Based on your screenshot, my guess is that a Composit object is getting inserted into the SpellEffects scrollPage, and the PlainTemplate gets repeated inside that.

Use an OnHover script to check what the scrollbar's "Control" property is set to at runtime. That is most likely the mystery object you need to set PackSize on via script. My guess is that the resulting object tree looks like the following

ExamineEffect
|_ SpellEffects (Template)
|_ PlainTemplate (Template)
|_ ScrollTemplate (Template)
... (More templates and window dressing)
|_ SpellEffects (Clone)
   |_ ScrollTemplate (Clone)
   |_ Composit (Mystery Object Vertical layout)
      |_ PlainTemplate (Clone for non-dot description text)
      |_ Composit (Mystery horizontal layout, left padding to indent bullets)
         |_ DotTemplate (Clone)
         |_ PlainTemplate (Clone for dot text)

Oh and use an onHover script for the PlainTemplate with a buncha parent concats to get the actual parent trace.

onhover="
tooltip=Parent.Name
tooltip=Parent.Parent.Name ##.## Tooltip
tooltip=Parent.Parent.Parent.Name ##.## Tooltip
tooltip=Parent.Parent.Parent.Parent.Name ##.## Tooltip
tooltip=Parent.Parent.Parent.Parent.Parent.Name ##.## Tooltip
"

Should produce something like...
root.ExamineEffect.SpellEffects.MysteryObject

[Drumstix42]

My only thought is that the scrollbar is getting Cloned as well, and would kind of put a stop to any testing via the xml script. Not positive though, I just know I had trouble making that respond to sizing as well.

Doesn't hurt to try though and I'd say it's definitely the best place to start.

[lordebon]

The internal scrollbar I could get to resize, it was whatever was constraining the PlainTemplate clones that I didn't get to resize (meaning I had a nice big scroll bar to scroll through a small box).

It was exactly through cloning that did it, I put a OnHoverIn script on the scrollbar to resize it and when it got cloned it kept that script.

[Zonx]

Right, so an onHover script with parent.name concatenation piped to tooltip applied to the PlainTemplate should be able to look up the tree and give you the runtime structure of the cloned stuff.

Similar script on the cloned scrollbar should be able to give you the value of its "Control" property, which should be the name of the container its scrolling, and should be the object that isn't resizing.