Error message with 2.8+: "Ruleset error: No vertical anchor defined"

[cscase]

Hey all,
I've gotten stumped again, and I suspect the answer is something very simple. I'm still working with the CoC ruleset, and I notice that if I have the base.xml version set to 2.8 or higher, then clicking "New" in the NPC panel results in a series of errors:


Ruleset Error: No vertical anchor defined for 'hp'
Ruleset Error: No vertical anchor defined for (unnamed)
Ruleset Error: No vertical anchor defined for 'dbdesc'
Ruleset Error: No vertical anchor defined for (unnamed)
Ruleset Error: No vertical anchor defined for 'armor'
Ruleset Error: No vertical anchor defined for (unnamed)
Ruleset Error: No vertical anchor defined for 'spells'
Ruleset Error: No vertical anchor defined for (unnamed)
Ruleset Error: Control '' anchoring to uncalculated control 'spells'
Ruleset Error: Control '' anchoring to uncalculated control 'spells'
Ruleset Error: Control '' anchoring to uncalculated control 'spells'

I'm looking at the XML file for the NPC panel and I suspect that the problem is something to do with bits of code like this example:

<columnnumberfield name="hp">
<anchor>weapons</anchor>
<tabtarget>
<next>dbdesc</next>
<prev>combatnotes</prev>
</tabtarget>
</columnnumberfield>

I've seen material explaining how <anchored> works (as opposed to <anchor>), but I'm not sure exactly what the problem is here, or why it would be fine pre-2.8. Can anyone point me in the right direction?

Thanks once again!
cscase

[Moon Wizard]

The columnnumberfield control is actually a template, and the anchor tag is a custom tag used by the columnnumberfield template.

Every control must have it's bounds defined:
* Bounds tag (x,y,w,h) defines a specific x,y coordinate for the upper left of the control, and the width and height of the control.
* Anchored tag can be used to position relative to other controls or window edges. At least one vertical (top/bottom) and one horizontal (left/right) anchor must be defined using this method.

The best method to debug is to view the templates used until you reach a standard control (i.e. numberfield, stringfield, etc.). Then, the merger of the tags from the top template down to the standard control is what will get used. Any custom tags defined are probably used by scripts linked to the templates. In this case, that template is defined in the common_templates.xml file.

Since all those controls throwing errors appear to be anchored to the "weapons" control. My guess is that the weapons control is not being instantiated for some reason (moved or changed).

Regards,
JPG

[cscase]

Hrmmm. I feel like I'm out of my depth on this one, but I have a theory. Can I tell you what it is and see if one of you see what I can't? The facts I note are:


If I set main.xml version to 2.7 or lower, these errors don't occur.
If I remove the onListRearranged call from the onInit function in "weapons"'s script, no errors occur.
One of the notes for ver. 2.8 says: "The onListRearranged event will be called less often in windowlistcontrols."


So, my guess is that this error has something to do with the way in which onListRearranged functions differently post-2.8. But I don't know if I'm correct... and if I am correct, I don't know what to do about it!

onListRearranged event will be called less often. Hmmm, what does that mean?

The "weapons" script looks like this. I've colored red the part I think is relevant.


<script>
local allowinsert = false;

function onListRearranged(changed)
if allowinsert and #(getWindows())==0 then
local win;
allowinsert = false;
win = createWindow();
win.name.setFocus();
allowinsert = true;
end
end

function onInit()
allowinsert = true;
onListRearranged();
end

function tabFirst()
local win = getNextWindow(nil);
if win then
win.name.setFocus();
end
end

function tabNext()
if tabtarget and tabtarget[1].next then
local target = tabtarget[1].next[1];
window[target].setFocus();
end
end

function tabPrev()
if tabtarget and tabtarget[1].prev then
local target = tabtarget[1].prev[1];
window[target].setFocus();
end
end

function tabLast()
local win = getPrevWindow(nil);
if win then
win.damage.setFocus();
end
end
</script>

[Moon Wizard]

Hmm, having trouble recreating this. I just took the latest CallofCthulhu ruleset, and only made a single change to base.xml version="2.0" to "2.8". Then, I opened both a PC sheet with weapons and an NPC sheet with weapons, and did not receive any script errors.

The onListRearranged call frequency should not impact anything, as the calls removed were redundant. Otherwise, onListRearranged should work the same.

Regards,
JPG

[cscase]

Hrmm, I'm not sure if I was just mistaken before about what version # I have to go to to make it stop, or if it was different, but with a fresh copy of the CoC ruleset, I'm seeing that I have to go to version 2.9 now to reproduce the error message. I did add the <useallmodules /> tag to this windowlist instance, but I get the error message either with or without that. Hmm, thinking...

Thanks again!

[Moon Wizard]

OK, I can see it now by changing to 2.9 compatibility, and nothing else.

Looking at the FG client code, the 2009 specific compatibility changes are:

Custom menus can override built-in menus
subwindow.onSizeChanged script event is now only called when the control size actually changes (instead of every parent window layout)
Window instances can be resized by dragging bottom and/or right edges
Window lists must explicitly specify whether they want to set the "usealltrees" flag.


Using some debugging tools on my side, I see the cause of the problem. The onInit call is called in weapons before the onInit call for the column fields. The onInit call then proceeds to create a window, and the set the focus to a field in the new weapon window. Any time focus is set to a specific field in a list window, it forces a layout. Since the other column fields have not called onInit yet, they don't have a top anchor set yet. This only happens when the NPC record is first opened, and thus the weapon list is initially empty. Also, this happens in v2.8 compatibility setting or higher, as part of the client trying to make sure that any field in which focus is set is visible to the user.

To fix, just remove the onListRearranged call from onInit. The onListRearranged event is automatically called for windowlist controls immediately following the completion of all control onInit events.

Regards,
JPG

[cscase]

Fantastic! Thanks very much for your help!