Controlling ZPos and Disabling Focus on Click

[StickStack]

Hello.

I am trying to understand AlwaysOnTop properly and its applications. If I want to write a skin where if the skin is partially obstructed by another skin or windows application and I want to activate it without bringing it up to the top and obstructing the window, the only positions that will work are -1 & -2. To extend that, I still want my skins to be visible when the desktop is focused, so that only leaves -2 (On Desktop). To confirm my conclusion, I did a mini-test with various ZPos shown in the gif below.

z_demo.gif

In the above .gif, I want the behavior of Skin B: A clickable element that never gets brought to the foreground. However, the position to achieve that is the bottom most one, -2, thus confirming my conclusion. Skin A is 0 and gets brought up when clicked, and Skin C with 1 just outright hogs the screen no matter what. I assume a value of 2 achieves a just as undesirable result as Skin C.

However, this "solution" is not without its own problems. As seen in the .gif, I later activate Skin D, and I want it to render BELOW Skin A & B and atop the Skin Stand. It successfully renders under Skin A as Skin A is set to be Normal (0) and Skin D is set to be On Desktop (-2), but renders above Skin B as they share the same ZPos and Skin D was loaded later. This is despite the LoadOrder, though if I understand the documentation correctly, this is correct behavior as LoadOrder only has impact when a collection of Skins are loaded at once. I had to deactivate and re-activate Skin B again, which I would rather not have to do, manually or automatically.

Is there a way I can sternly tell multiple skins to stay in their appropriate Z depths even within the same AlwaysOnTop layer (e.g. Skin A will always stay atop Skins B and C, Skin B below C, etc.) without ever getting shuffled in between !(De)activateConfig operations and never have them take focus of all windows applications?

If possible, I would like a solution that doesn't use perpetually active skins that use !Show and !Hide bangs because as I understand it, hidden skins are still running in the background and I would like to take every opportunity to reduce CPU usage (e.g. a button to switch on/off a visualizer that is rendered behind an always active graphic element).

[SilverAzide]

Is there a way I can sternly tell multiple skins to stay in their appropriate Z depths even within the same AlwaysOnTop layer (e.g. Skin A will always stay atop Skins B and C, Skin B below C, etc.) without ever getting shuffled in between !(De)activateConfig operations and never have them take focus of all windows applications?

The simple answer to your question is "No". This is not a Rainmeter issue, this is how the Windows OS works. Each Rainmeter skin is a "window", and while you can control some aspects of the Z-order, some aspects are handled/constrained by Windows itself.

[StickStack]

Thank you for explaining; I didn't realize each skin was a Windows "window", and that makes it vividly clear the constraints of the Z Position. I will have to reconsider my skin architecture to work within these system constraints.

I do have a follow-up question; I started tinkering with the idea of dynamically changing the ZPos on hovering over skins as jsmorley suggested in this rather old thread, and noticed an undocumented behavior: it appears that for positive AlwaysOnTop values (0, 1 & 2), sending/loading a skin to that layer will put it at the top of all the other skins within the layer group, but sending/loading a skin to -1 or -2 actually puts it UNDERNEATH all the skins already there. I just want to confirm if this is intended (and perhaps controllable) behavior, because before noticing this I had assumed no matter the layer, the newest skin to be put there would be topmost akin to Windows' behavior.