Placement of control objects is different in FGU versus FGC

[celestian]

This might be related to some topics already covered but tonight I noticed that one of the windows in FGU looked a lot different than in FGC. There is no difference in the 2 when it comes to placement in XML.

https://i.imgur.com/ulZSasK.png

You can see the title (white background text) is not above the text in FGU like it is in FGC.

The XML code.


<!-- stats tab subwindow -->
<windowclass name="cta_stats_host">
<sheetdata>
<contentanchor_ctabox name="contentanchor"/>

<subwindow name="cta_saves_and_abilities_host">
<anchored to="contentanchor" >
<top anchor="bottom" relation="relative" offset="10" />
<left />
<right />
</anchored>
<activate />
<fastinit />
<class>cta_saves_and_abilities_host</class>
<frame name="ct_subgroupbox" offset="0,5,0,5" />
</subwindow>
<cta_subwindow_toplabel name="cta_saves_and_abilities_host_label">
<static textres="cta_stats_and_saves_title" />
<anchored to="cta_saves_and_abilities_host">
<left offset="-50" />
</anchored>
</cta_subwindow_toplabel>

<subwindow name="cta_tokendetails_host">
<anchored to="contentanchor" >
<top anchor="bottom" relation="relative" offset="10" />
<left />
<right />
</anchored>
<activate />
<fastinit />
<class>cta_reach_size_host</class>
<frame name="ct_subgroupbox" offset="0,6,0,8" />
</subwindow>
<cta_subwindow_toplabel name="cta_tokendetails_label">
<static textres="cta_tokendetails_host_label" />
<anchored to="cta_tokendetails_host">
<left anchored="center" offset="-30" />
</anchored>
</cta_subwindow_toplabel>

</sheetdata>
</windowclass>

[Moon Wizard]

There are definitely some layout issues still to iron out. They are unfortunately a lower priority to getting the image stuff working as well as player networking.

If you have simple examples that don't involve lots of embedded windows, those will be the easiest to track down first. Stepping through CT window code when debugging layout issues is very painful and lengthy. So, any pointers to simpler scenarios to work through first is appreciated.

Regards,
JPG

[celestian]

There are definitely some layout issues still to iron out. They are unfortunately a lower priority to getting the image stuff working as well as player networking.

If you have simple examples that don't involve lots of embedded windows, those will be the easiest to track down first. Stepping through CT window code when debugging layout issues is very painful and lengthy. So, any pointers to simpler scenarios to work through first is appreciated.

Regards,
JPG

You are right I should have detailed the template in question. Here is the toplabel template.




<template name="cta_subwindow_toplabel">
<stringcontrol>
<frame name="mini_name" offset="4,0,6,0"/>
<anchored>
<top offset="-9,0" />
<left anchor="center" />
</anchored>
<font>sheetlabelmini</font>
<center />
</stringcontrol>
</template>


It'll probably be end of Mid/December before I can poke at it more. When I get the chance I'll try and break it down to a single control and reproducible .

[Moon Wizard]

The example tells the story. You have a value that is not a single number as the offset attribute for the "top" anchor (i.e. "-9,0" should be "-9"), since offsets for anchors only work in one direction.

The c++ string to integer function (atoi) is more forgiving (processes number at beginning, and ignores everything after numbers); while the C# string to integer function (int.TryParse) only accepts [+-][0-9]+. I'm looking at whether it makes sense to add a more relaxed standard for ruleset tags, but that means I can't use the default translation and have to write our own.

Regards,
JPG

[Moon Wizard]

After looking at the code for this (which was in process much earlier), it primarily only affects width/height attribute/tags; other than a few extras like anchor offsets and stringcontrol multiline spacing. So, I think I'm going to leave as is using the existing built-in, but stricter, conversion routines.

Regards,
JPG

[celestian]

After looking at the code for this (which was in process much earlier), it primarily only affects width/height attribute/tags; other than a few extras like anchor offsets and stringcontrol multiline spacing. So, I think I'm going to leave as is using the existing built-in, but stricter, conversion routines.

Regards,
JPG

Sounds good. I'll clean up the places where this is done incorrectly. I got in the habit of using offset="X,X" and FGC didn't complain ;)

Keeping it strict to force proper syntax is good idea.