Unexpected behavior with on-demand SetAnchor right vs left align switching. Any workarounds?

[Yincognito]

For the curious found this can be solved by keeping in sync the full `!SetWindowPosition` at each resize change, with the WindowX and WindowY set as `#CURRENTCONFIGX#` and `#CURRENTCONFIGY#`, respectively (since apparently the WindowX/Y actually does need to be moved simultaneously to behave as desired). Note: for the test case skin this would require some additional changes but for my actual skin purposes it works well.

That's another way to do it, yes - hence the multiple solution mentioning above. Up to you to choose how to do it, so that it's the most convenient for your actual scenario.

[Crest]

All good. Anyone coming across this will have to experiment with the techniques suggested. For example as-is if applied the test case skin both techniques have quirks remaining (with mine there's still some unintentional offset after clicking the button again, while with yours both resizing and/or repositioning randomly resets back to a prior coordinate).

In my actual scenario though, which doesn't use the scroll wheel and updates the `SetWindowPosition` at the rate of the mouse plugin, it had the desired effect so just FYI to anyone reading.

[Yincognito]

while with yours both resizing and/or repositioning randomly resets back to a prior coordinate

Really?

I don't get the prior coordinate reset at all. Maybe it has to do with the fact that the test skin has by default a width of 300, so, after modifying that width while having a fixed right side position, on skin refresh the left side position would appear to be different because the width itself changed back to 300 ar per the test skin code (but towards the left, given the fixed right side position). If by any chance you're referring to that, this is normal, expected and desired. For it to not happen, you'd have to !WriteKeyValue the last width (W) of the text / skin, so that on reload / refresh everything is as it was before.

[Crest]

Really?

I don't get the prior coordinate reset at all.

Couldn't reproduce the position-only coordinate reset on click but could the anchor funny business. No refresh is used fwiw.

Mine if applied as-is to the test case skin:

Demo-3-Crest-behavior.gif

Alternatively the two lines provided in your post:

Demo-3-Yingcognito-behavior.gif

Both quite similar behavior. Wrangling Rainmeter to get the desired result without this issue is possible though but I cba paring down my skin to show an alternative example INI :p But I do think the update rate must be important since I'm using the `SetWindowPosition` to sync as described.