[BUG]CURRENTCONFIGX/Y Issue

[Brian]

This has been fixed. Thanks for reporting.

Nice catch. Apparently this bug has been around for years (since before my time).

What happens is that when the skin is first read, it temporarily sets the position variables #CURRENTCONFIGX# and #CURRENTCONFIGY# based solely on the WindowX/Y values from Rainmeter.ini. This is done in case those variables are used in some option - there needs be "something" to use1. After everything is initialized, the exact position values are now known, and the skin positions itself correctly. The problem was, those position variables were not updated correctly at this time and were left as the "initial" incorrect values - and not calcuated again until the skin moved or was refreshed.

When refreshed, the skin retains its position variables and when it reads its Rainmeter.ini options again, that temporary setting of the position variables (see first sentence of the last paragraph) turns out to be the correct value.


I suspect this was missed since the use of AnchorX/Y is rarely used and not respected after the skin is moved around.

-Brian

1 Extra credit - The reason the position values are calculated after initializing the measures and meters is because options like KeepOnScreen can move the skin and change its position. The size of the skin needs to be known before any movement can happen. Once moved, the exact position on the screen is now known.

[Yincognito]

After everything is initialized, the exact position values are now known, and the skin positions itself correctly. The problem was, those position variables were not updated correctly at this time and were left as the "initial" incorrect values - and not calcuated again until the skin moved or was refreshed.

Precisely. It was just a matter of forgetting to reevaluate the variables once everything needed to calculate their correct values was available.

This has been fixed. Thanks for reporting. [...] Nice catch. Apparently this bug has been around for years (since before my time).

Yep, figured out that it was hard to spot the issue due to the relatively rare use of (centered) percentage positioning. The fact that the bug existed, or the amount of time since it existed was not a problem - the problem was that it was logical for this thing to not happen, since, as already explained there was no practical inability to get these variables right, especially since the bug happened (and persisted) even after the skin was first drawn, despite having all the values needed to update the variables by then.

Many thanks for correcting this, Brian - excellent job. And to Jeff as well, for probably bringing this to your attention. Will test the new version later on, but I'm sure everything works as expected now.