Extension Development - onClickDown Return Value

[MeAndUnique]

The documentation for the return value of a windowcontrol's onClickDown() handler found at https://www.fantasygrounds.com/refdoc/windowcontrol.xcp#onClickDown, specifically "A value of false indicates that the default framework functionality for the this particular control should not be executed, but the processing should continue for the element below this control, if any." appears to indicate that if one control is drawn over top another, the bottom control will receive the onClickDown event when the top control returns false. However, this does not appear to be the case. The following has been used to show that only the topmost control's handler will receive the event when testing in the 5E ruleset, though it is assumed that the ruleset has no bearing on this particular functionality.

<?xml version="1.0" encoding="UTF-8"?>
<root release="3.0" version="3">
<properties>
<name>OnClickDownExample</name>

<ruleset>
<name>5E</name>
</ruleset>
</properties>

<base>

<script name="opener">
function onInit()
Interface.openWindow("tester", "");
end
</script>

<windowclass name="tester">
<frame>utilitybox</frame>
<script>
function onClickDown(button, x, y)
Debug.chat("window");
return false;
end
</script>
<sheetdata>
<genericcontrol name="bottom">
<anchored position="over" />
<script>
function onClickDown(button, x, y)
Debug.chat("bottom");
return false;
end
</script>
</genericcontrol>
<genericcontrol name="top">
<anchored position="over" />
<script>
function onClickDown(button, x, y)
Debug.chat("top");
return false;
end
</script>
</genericcontrol>
</sheetdata>
</windowclass>

</base>
</root>

[LordEntrails]

MOD: moved to Workshop, as that's the best place to discuss extensions and development.

[SilentRuin]

MOD: moved to Workshop, as that's the best place to discuss extensions and development.

This is discussing a bug in the code - so is that still Workshop where we would put those? Typically, in the past, any bugs in the code (engine or ruleset) was always put elsewhere. Is this something new?

[Moon Wizard]

This is by design; though the documentation may need to be clarified. When it states that "the processing should continue for the element below this control", it refers to the window and other parent elements, not any other controls in the same window.

In these scenarios, I usually use the "disabled" tag to block mouse interactions completely for one of the controls. Or intercept events at the higher-level control and pass to the lower-level control.

Regards,
JPG

[MeAndUnique]

This is by design; though the documentation may need to be clarified. When it states that "the processing should continue for the element below this control", it refers to the window and other parent elements, not any other controls in the same window.

In these scenarios, I usually use the "disabled" tag to block mouse interactions completely for one of the controls. Or intercept events at the higher-level control and pass to the lower-level control.

Regards,
JPG

Thanks for the reply, that helps clarify expectation for sibling control interactions. The above example still does not cause the window to receive the event from the "bottom" control if the "top" control is removed, which sounds like it is a bug if I am interpreting intent correctly.

[Moon Wizard]

Well, technically, window instances do not support click events (only window controls do); so they would continue to be passed up the hierarchy to any window containers (subwindow/windowlist).

Regards,
JPG

[MeAndUnique]

Ok, cool, thanks for clearing that up for me.