Resize a window programmatically if it's not a <dynamic /> window?

[zuilin]

I have a window that's not <dynamic /> and when I try to setSize() on it it won't work.

If I change it to a <dynamic /> window, the setSize() works most of the time, but many times I get sizes that don't make sense.

Thoughts?

[Moon Wizard]

Top-level windows will attempt to resize to fit the controls within the windows. This might be what you are seeing.

JPG

[zuilin]

Seems like it.

Does a window need <dynamic / > to resize it programmatically?

[zuilin]

Here's an even better question....

Is there any method that fires after it's done its automatic resizing as you mention above?

Right now I'm doing my .setSize() in .onInit() for the window, but perhaps there some other callback that fires well-after .onInit() and after the window is completely done drawing itself where I could put my own resize in instead.

I'd really like to be able to confidently set the size of the window immediately before the user starts interacting with it.

Thoughts?

[zuilin]

FYI I tried onFirstLayout() but that fires before onInit(). I do my resizing in onInit() and it seems that it should work if the built-in layout is done before onFirstLayout(). It doesn't seem to have predictable behaviour from my hours of testing

[Moon Wizard]

In normal operation, the onInit event fires for each control and then the window instance; then the layout is performed which triggers onFirstLayout events. If you inject calls into the onInit events that trigger a layout, the onFirstLayout could potentially trigger before onInit.

Try adding simple Debug.chat output in those events without any other script code, so that you see the default flow without having your code injecting alternate code paths.

Regards,
JPG

[zuilin]

In normal operation, the onInit event fires for each control and then the window instance; then the layout is performed which triggers onFirstLayout events. If you inject calls into the onInit events that trigger a layout, the onFirstLayout could potentially trigger before onInit.

Try adding simple Debug.chat output in those events without any other script code, so that you see the default flow without having your code injecting alternate code paths.

Regards,
JPG

I did and it seems like the main onInit fires after the main onFirstLayout.

[Moon Wizard]

Taking a quick look at the code. Top-level windows are laid out before onInit is called; but embedded windows (containers/lists) are laid out after onInit is called.

Regards,
JPG

[zuilin]

Taking a quick look at the code. Top-level windows are laid out before onInit is called; but embedded windows (containers/lists) are laid out after onInit is called.

Regards,
JPG

I got to thinking about that and so I called window.notifyUpdate and I think I'm getting closer. Not there yet, but closer.

[zuilin]

OK, so lots of testing later...

Pre: I have a formattedtextcontrol in the middle of my window and it's anchored (effectively) to the edges of the window (more or less, indirectly, anyway). Check.

1. When I don't programmatically put any text in the formattedtextcontrol, the window always stays the same size when it's generated. Check. ****** EDIT: STRIKE THIS. NOW IT'S DOING IT WITH NO TEXT. ******
2. When I DO programmatically put any text in the formattedtextcontrol, it often changes size. Check. Not what I want.
3. I've run scripts on everything I can think of for the window itself and within methods of the formattedtextcontrol...

The resizing happens well-AFTER any of these fire in the formattextextcontrol:

onInit
onFirstLayout
onValueChanged -- This one surprises me, because it seems like it's the putting text into the formattedtextcontrol that causes the resize.

I've even tried, immediately following setting the text in the formattedtextcontrol, to send the window a notifyUpdate and THEN do the resize...still, to no avail.

I'm completely at a loss. Somewhere in the UI drawing, it's changing the size of the window and I don't seem to be able to have access to the moment in time that it's doing it. I guess I'm stuck with a boring, static window. Sigh.

[zuilin]

SOLVED!!!

Rather than trying to resize in the window's own code, if I do it in the window generating code (the code where I call Interface.OpenWindow) it works!

Since Interface.OpenWindow returns a pointer to the window, I can use that pointer to trip the .setSize() method and voila.

Thanks for pushing me, Moon Wizard.