Kolano wrote: ↑January 21st, 2024, 6:50 am
Yes, things remain in place across a Rainmeter restart, but power cycling monitors causes them to shift around wildly.
Thanks for the assistance with how to monitor the setups of each screen, hopefully that will provide some insight. Though it will be annoying if the assignments of monitors to IDs shifts due to their power on cycle once returned to their former powered state, that complicates even basic handling of multiple monitors significantly; none the less trying to account for arbitrary combinations.
___________________________________________________
Pre-Monitor Restart:
Post-Monitor Restart:
So, yeah, issue is that the work/screen areas change numeric assignment across monitor restarts, and aren't correlated with the numeric assignments Windows uses as I had presumed. There also seems to be some issues caused by the scaling settings, though I need to review Yincognito's config more closely, as it only outputs a single Scale for the last of my 5 displays (presumably my three screens and each eye of my VR headset).
This feels very irksome to deal with, a means to reference monitors consistently would be helpful.
Thanks for the feedback!
Yeah, that's what I was talking about - monitoring those values at least offers a clue on where the problem lies, and, in the best scenario, "could" provide a way to properly react to this in the skins, via some skin bangs. The worst scenario would be to need a Rainmeter restart when these things change, in order to set things back accordingly (which is why I asked if it solves things) - this seems similar to how other options depending on the Rainmeter initialization process work, like DesktopWorkArea for example. If so, although not quite desirable or user friendly, such a restart can be done automatically by running a simple batch file (I wrote one for my DesktopWorkArea case, if you need it and Rainmeter restarting is helpful in that regard).
Regarding scaling, you would need to adjust those PowerShell commands used to query the related registry keys accordingly (if they do resemble the structure that I had, obviously, something you can see by running regedit.exe). Unfortunately, like I explained in the other thread, the scaling values in such a case are system dependent and relate to what you have in the scaling settings combo box in Windows.
Keep us posted on what else you notice or any progress or difficulty in that regard - who knows, maybe there is a feasible workaround to this and we could help, if the standard solutions like simple skin settings configuration aren't enough.
EDIT: I was thinking, if your monitors are arbitrarily swapped positionally depending on the order in which they are turned on, you might want to use "absolute" coordinates to position your skins via bangs like !Move or !SetWindowPosition in the skin's OnRefreshAction from its [Rainmeter] section, on whatever monitor that contains that absolute position (assuming that monitor spaces don't overlap, of course). For example, if your actual visual space made up by your monitors is, say, 5000 × 2000 (with the top left at around -2500,-1000 as per your monitor coordinates posted values above), and you want your skin to be placed towards the bottom right on that (e.g. X=4300, Y=1200 on that space), then forget about placing it on a fixed monitor index via @N, and just compare to find out which @N monitor such X,Y would correspond and place it on that @N. In your case, it would be the monitor with the positive coordinates, since the other two are to the left and top of it in your arrangement (with partially negative coordinates). This would place the skin on the 1st monitor for your 1st values, and on your 2nd monitor for your 2nd values above - if you get the idea. So, besides potential scaling or anchor alignment influences, it would be just some "simple" math like checking between which absolute coordinates is your X,Y point in terms of monitor coordinates, if that makes sense.
