How to change size of a window

[Xarxus]

Is there a way to change window size by code?
I tried a simple setSize(x,y) but I get an error: Embedded window can not be changed

[Moon Wizard]

You can not change the size of an embedded window, only top-level windows.

For windowlists, the width of the children will match the windowlist width; and the height will be the height of all the controls in the embedded window.
For subwindows, the width and the height of the controls in the embedded window determine the width and height.

If you need to adjust width/height of embedded window dynamically, you'll probably need to define controls that you can show/hide to increase/decrease the height (i.e. spacers/footers/etc)

Regards,
JPG

[Xarxus]

So I think I should do something like
parentcontrol.window.setSize(x,y)

In this way I don't get any error, but the window doesn't resize...
What I'm doig wrong?

[Moon Wizard]

Are you trying to override an existing window? Is the window tied to a panel that already has anchors and fixed sizes?

It would help to know more about what you are trying to do, and to which windows.

Regards,
JPG

[Xarxus]

This is my code. I do not show you header code, I think it's superfluous
<windowclass name="my_class">
<frame>recordsheet</frame>
<placement>
<size width="450" height="220" />
</placement>
<minimize>minimized_reference</minimize>
<tooltip field="name" />
<script file="campaign/records/scripts/record_generic.lua" />
<sharable />
<sheetdata>
<sub_record_header name="header">
<class>my_header</class>
</sub_record_header>

<frame_record_content name="contentframe" />

<subwindow_record name="main">
<class>ref_my_main</class>
<activate />
<fastinit/>
</subwindow_record>

<scrollbar_record>
<target>main</target>
</scrollbar_record>

<resize_recordsheet />
<close_recordsheet />
</sheetdata>
</windowclass>

<windowclass name="ref_my_main">
<margins control="0,0,0,2" />
<script file="campaign/classes/scripts/class_my_main.lua" />
<sheetdata>
<genericcontrol name="controlwheel">
<anchored>
<top offset="0" />
<left offset="0" />
<right offset="-15" />
<bottom offset="-5" />
</anchored>
<script file="common/scripts/mycontrol.lua"/>
</genericcontrol>
</sheetdata>
</windowclass>


Inside onInit I use createControl to generate some control based on some information coming from the DB.
Controls created can span 3, 5, or 10 rows. I would therefore like the window to be sized adequately and I
would not want it to be resized by those who are using it.

The genericcontrol is placed on top of the others controls using bringToFront() and it's purpouse is to track
the onWheel event. This event changes some value in all controls created, not the number of them.

[Moon Wizard]

If you look at some of the existing window classes for record types in the D&D rulesets (such as "item" or "npc"); you'll see that they use a bunch of *_column controls that automatically stack on top of each other. Then, within the script code, you just call the update when the read only state changes to "update" which auto-hides the field if empty. Then, the content of the window automatically sizes to the correct size.

Remember that the subwindow control already supports scrolling automatically if the vertical size of the child window exceeds the height of the subwindow. That's why there is a scrollbar control in that window class. It will only appear if the child size is greater than the subwindow size.

You should not be placing any controls over the top, as it will interfere with all mouse interactions for any controls below it.

Regards,
JPG

[Xarxus]

Controls a placed in specific places and the user doesn't need to directly interact with them.
They show information. So *_column are not what I need. When the wheel is used, all controls
must show different information, even if the wheel is used on the window, but not on a specific
control. As far as I can see the windowclass doesn't implement onWheel event, that's why I need
a control over all the others.
But this is not my problem. My problem is that I load data, create X information on the window
and I need the window resize in the way I need (450x220; 750x440; etc.).
Using parentcontrol.window.setSize(x,y) does not give any error or warning, but the window is
not resized and I don't know why.

[Trenloe]

<windowclass name="my_class">
<frame>recordsheet</frame>
<placement>
<size width="450" height="220" />
</placement>
...
</windowclass>


The bold XML above makes your window static.

Refer to the windowclass reference here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996645644/windowclass

See the <sizelimits> section - and also <dynamic />

[Xarxus]

I tried in this way and discovered something
<windowclass name="my_ckass">
<frame>recordsheet</frame>
<sizelimits>
<dynamic />
</sizelimits>
...
</windowclass>


I tried this in Lua:

Debug.console(parentcontrol.window.getSize());
parentcontrol.window.setSize(450, 800);
Debug.console(parentcontrol.window.getSize());

The result is
#200|#200
#450|#800

The window has resized. Now if I change code in


Debug.console(parentcontrol.window.getSize());
parentcontrol.window.setSize(800, 450);
Debug.console(parentcontrol.window.getSize());

The result is
#200|#200
#800|#450

But the window remains in his previous version: 450,800
It changes only if I remove windowstate.xml

[Moon Wizard]

If you are trying to change the position of the window in an onInit call; those occur before the windowstate saved placements are called. You might be able to get around that my changing the size in onFirstLayout.

However, I still think that you are perhaps overcomplicating the need. Just have all the correct fields in the content area, and let the content area scroll. There's usually very little need to force a resize based on content, since the content already scrolls.

Regards,
JPG

[Xarxus]

The problem is that Fantasy Grounds struggles when using a very large number of controls, so I'd like to
be able to decide to show a small amount, by cycling the information within them.

In my case I have to show data tables with a number of columns ranging from 10 to 22 and an
approximate number of rows of 100 (or more). The data can vary, so I can't show a simple HTML table.
The idea I was thinking about was to show a certain number of rows based on a data present in
the DB, managing the onWheel event to scroll the data in the few fields shown.

But the problem is that the data can change after a window has already been opened and then
closed, so I need the resize to happen even when it's opened again.

If you have better ideas on how to manage a large number of data that can change during game,
please tell me, do not esitate.

[Moon Wizard]

Yeah, we actually do this with the item records. We use a subwindow to add/remove "type"-specific controls to the window. If the "type" field changes, then the subwindow is swapped out for the new one.

In your case, you could probably also "window" the data onto a fixed number of controls (i.e. create a data view, not to be confused with FG window object); and allow the user to navigate up/down/left/right. Then, you update the fields with the correct values based on the "offset" of the data view.

Regards,
JPG

[Xarxus]

Yes, this was my idea, but I was wondering if there was a way to change the data slice window to accommodate 3 ways
of seeing the data itself (each way has a specific scope determined by the data it is showing).

I'll probably have to settle for finding a middle ground that fits all three types (consider that they are dynamic and can
change as the data is displayed).

Thanks again for the support.

[Xarxus]

I was wondering if it was possible to make Fantasy Grounds not remember the
position and/or size of the windows. Is there a parameter or function somewhere?

[Moon Wizard]

Yes, add a "<nosave />" tag to the windowclass.

Regards,
JPG

[Xarxus]

Don't misunderstand what I'm about to tell you: I love you!

Ty!!!

PS that's undocumented

[damned]

Don't misunderstand what I'm about to tell you: I love you!

Ty!!!

PS that's undocumented

Nope. Your love for the Moon Wizard has been documented.

[Xarxus]

I should have known I was going to hurt myself :D