setting sizes, interface too slow?
 

i'm setting the size of one widget within a onShow event and right after that setting the size of another widget to the size of the previously set widget (next line of command in the same event).

but somehow the second widget always receives the size of the first widget prior to resizing. is this caused by the UI not responding that quick or what is it?

(edited to clarify)

it's two nested widgets. the inner one is sitting with packsize=proportional inside the outer one. i resize the outer one and want another widget set to the size of the now automatically resized inner widget. and that's what not functioning.

i'm under the impression that autoscaled sizes aren't pushed to the client somehow. setting some widget to the size of X will force this widget to always return the value X for it's size, no matter what happened via autoscale. is that right?

All addressable object properties are available at runtime, weather autoset or not.

Generally, any objects/properties you can see in the XML are addressable. Hard-codeding is generally a problem of not being able to address objects, code, or properties that aren't exposed in the XML.

The issue you described sounds like either a timing problem or a script ordering problem. Check the following potential problems...

1) Commands are executed right to left, then top to bottom.

Example:
Result, A=C not the original value of B. Since the commands are on the same line, the right command is executed first, followed by the left command. In your case, if you wrote
You're actually asking for the size before its been changed.

To avoid execution order problems, I recomend always line breaking between commands.

Example:
result, A=B

2) Unoptimized graphical objects can result in rendering taking longer than the script that forced a redraw. Excessive image tiling in particular can cause this. Avoid using Rectangle styles that tile tiny image slices.

Example: You have a FrameStyle applied to a page that tiles a 1 pixel image to draw a border. The first line of your script resets the window's size. It takes 2 seconds to render the new size because all those tile positions have to be calculated. 1/2 sec after the first line of script fired, the script tries to get the size of a child object of that window, but it hasn't finished drawing so the child object hasn't changed.

thanks, wasn't aware of the right to left execution. but this hasn't been the problem here, used line breaks between the commands.

i'm not using "unoptimized" objects. at least i guess so. it's just a page object with no style attached. maybe the problem sits in the amount of resizing. i'm blowing it from sizes like 70 to 10k and back to 100 right in the next line.

this also explains another weird problem i encountered. guess i have to find some other way to do what i want :D

Post your script. If there aren't any styles applied to the objects being resized, it should happen fairly quick, though 10k pixels is prety ginourmious.

what i want to do is using nested pages as calculator. in this case to calculate the player's current resist cap.

the testing xml:
commented script code:
i use this code as an underlay in the persona window to give a visual feedback on how much room is left to increase a stat. it's not a representation of the actual mitigation, it's just the progress towards the cap. currently it's towards the cap of a level 70 player cause i don't get the current cap calculation to work.

i also tried it with three nested pages, this would do away the dummy pages. but with three nested pages the innermost page gets (directly via textfield's localtext) resized before the second layer page is resized via it's proportional setting. this leads to the innermost page always getting set to the maximum size (outer size of 100 vs. inner size of 1000++)

Ok played with this for a bit. There are a couple problems.

1) There is deffinetly a timming issue. With my other tweaks, I can see the results differ if each command is executed manually vs auto.

2) Although EQ2 script is prety good about processing unquoted strings, sometimes it has problems. Best to quote any comma separated values.

3) Not possitive, but it seamed in my tests that it was confused by the "Container" label, so I changed it.

In this sample code, I've split each command out to a separate button and dasy-chained them with scripted button presses. The problem occurs with the 4th button press. If its executed via script, the Inner size gets called before its been resized. If you press the button manually, it works as intended due to the delay between pressing the 1st and 4th buttons.
Note: You'd probably have better results just using math to calcualate the values. Math will produce decimals, but they get truncated when passed as a size value. Try this formula

oh man... i must have been blindfolded. of course simple math fits my problem better. sorry for being dumb Oo

thanks for all the testing tho. at least now i'm certain there's issues with timing :D