Request For Coding Help - Button Moves On Mouse Wheel

[dulux-oz]

Hi Guys,

I've got a funny one (which usueally means I'm doing something wrong :) ):

I've added the following buttoncontrol to the ModifierStack. The button doesn't do anything at the moment (no onclick code - yet) and there is no extra code added anywhere to anything else. I've noticed that when I roll the mouse wheel (up or down) the new button progressively moves to the right - and I can't work out why (& therefore can't work out how to stop it).

This is on a "plain-vanilla" CoreRPG v3.3.4 installation. Any ideas?



<windowclass name="modifierstack" merge="join">
<sheetdata>
<buttoncontrol name="TestButton" merge="add">
<anchored position="insidetopright" offset="-11,2" width="15" height="15" />
<state icon="tool_down_30" color="FFFFFFFF" frame="mini_name" frameoffset="2,2,2,2" tooltipres="sTestButtonDownTooltip" />
<state icon="tool_up_30" color="FFFFFFFF" frame="mini_name" frameoffset="2,2,2,2" tooltipres="sTestButtonUpTooltip" />
<default>1</default>
</buttoncontrol>
</sheetdata>
</windowclass>

[damned]

Its likely its something in the modifierstack windowclass or the TestButton buttoncontrol defined in their respective definitions...?

[dulux-oz]

Its likely its something in the modifierstack windowclass or the TestButton buttoncontrol defined in their respective definitions...?

Yes, obviously, but I can't see anything that would be causing the observed behavior - which was why I was asking if anyone else had experienced something similar or who might have a solution.

And just to be clear, the code I posted is the ENTIRE TestButton Definition.

[damned]

Why do you use merge="add" if that is the first time you are defining it?

[dulux-oz]

Why do you use merge="add" if that is the first time you are defining it?

Habit - it doesn't make a difference if its there or not for new entries (as far as I've experienced), but I've gotten into the habit for when I need to use a subsequent "insertbefore"

[damned]

I can replicate the issue.
On a 1920wide desktop it moves 22px on a 1026w desktop it moves 33px.
How very bizarre...

[dulux-oz]

I can replicate the issue.
On a 1920wide desktop it moves 22px on a 1026w desktop it moves 33px.
How very bizarre...

Yeah, that's what I said - so now I'm wondering (a) what's the cause, and (b1) how do we fix it and/or (b2) what's the work-around? :confused:

[LordEntrails]

Not that I have any idea on the coding side, but I've seen what might be similar effects in other programs interacting with the mouse wheel. i.e. that sometimes in some programs when you scroll the mouse wheel the window actually pans left/right. I've seen this behavior change when you change the settings in the mouse control panel. Usually when you change the scroll wheel from "Auto Scroll" to something like "middle mouse button" or "zoom" etc.

Don't have any idea if that change in behavior based on mouse settings could be replicated in this case, or if it does if it even helps. But, maybe it will or it will spawn some constructive thoughts in one of your minds :)

[Trenloe]

I'd recommend searching for onWheel event handlers related to the modifier stack then tracing/debugging the code/process related to that.

[dulux-oz]

I'd recommend searching for onWheel event handlers related to the modifier stack then tracing/debugging the code/process related to that.

Yeap, done that - the only onWheel relates to the value of the mod in the modstack - i can not locate any relationship between that value and the right anchor of the button.

In fact, there is no relationship to ANYTHING and the right anchor of the button - at lease not that I can find by going through the (exposed) code line by line.

It also seems to occur when the mod in the modstack gains & loses focus - but only after the mod's onWheel event has been fired.

It really is quite bizzar

[Moon Wizard]

This has to do with one of the quirks of the FG layout engine with top-level windows. The top-level windows are designed to expand to fit all the controls defined within their viewable area. Since you are defining a control that is outside the viewable area (i.e. insidetopright -11), then the window expands by 11 pixels each time the layout code is called, as the code grows the window to fit your control within the viewable region. Otherwise, your control would be chopped off at 4 pixels wide, because only what is inside a window is drawn on the screen.

The moral is:
Do not define controls which overflow outside a window definition. (i.e. anchoring such that width/height overflows viewable window space) This forces window instance expansion to fit controls. This is especially problematic in right/bottom anchors for windows with no maximum size, such as modifier stack.

The correct way would be to increase the minimum window size of the modifierstack windowclass, and place the control within the viewable region. If you must hammer square peg to round hole, you can also theoretically set the maximum window size, so that the layout code can't override.

However, all of this becomes problematic, due to the fact that "modifierstack" is modified by several derived rulesets to increase the minimum window size to add other buttons, so you don't want to override either minimum/maximum in this case.

If this is for a layered ruleset, then just expand the window class mimimum size(like the 5E ruleset). If this is for an extension, you'll need to place the button differently.

Regards,
JPG

[dulux-oz]

Thank you Moon, for that detailed explanation - yes, it does all make sense, and I'll make the necessary adjustments :)

Cheers