Determining the top / bottom position

[balala]

In other words, you might only need to know if (#CURRENTCONFIGY#+#CURRENTCONFIGHEIGHT#)>#SCREENAREAHEIGHT# and if so,

If the Keep on screen option is active, the above inequality can't be true.

[Yincognito]

If the Keep on screen option is active, the above inequality can't be true.

I might be wrong on this as I'm not yet on my laptop, but as far as I remember, Keep On Screen only kicks in when trying to drag or click the said skin (i.e. once there's an user / mouse click interaction on the said skin). Until then, I suppose the inequality can temporarily / briefly be true.

Also, I believe I use a similar test in my custom tooltip skins and it works. Can't remember if they're Keep On Screen, but I reckon they are, since that's the whole point of tooltips (original or customized).

[balala]

but as far as I remember, Keep On Screen only kicks in when trying to drag or click the said skin (i.e. once there's an user / mouse click interaction on the said skin).

Right.

Until then, I suppose the inequality can temporarily / briefly be true.

How? If the Keep on screen option is checked, you can't position a skin in way its bottom to be outside of the screen. But (#CURRENTCONFIGY#+#CURRENTCONFIGHEIGHT#) is representing the bottom of the skin, while #SCREENAREAHEIGHT# is the vertical size of the screen. The first one can't go above the second one. You can't drag the skin in such a position, you can't move it with a !Move or !SetWindowPosition bang. Unless I'm missing something, there is no way to get true the inequality if the Keep on screen option is checked.

[Yincognito]

you can't position a skin in way its bottom to be outside of the screen

Indeed, you cannot manually do this via user interaction. That however, doesn't mean the skin cannot expand beyond the screen (which the OP's GIF seems to illustrate) until / before that user interaction takes place - correct me if I'm wrong.

In other words, as far as I understood the request, it's about (automatically / programatically) directing the skin expansion where there is room for it, not necessarily about (manually) moving the skin in an off screen situation.

[balala]

Indeed, you cannot manually do this via user interaction. That however, doesn't mean the skin cannot expand beyond the screen (which the OP's GIF seems to illustrate) until / before that user interaction takes place - correct me if I'm wrong.

No, you are not. You are perfectly right on this. I missed this detail, my bad.
However still waiting for OP. In vain?

[Rooky_89]

Good Evening <

The first step works. So now wee need the conditions

Code: Select all

[Rainmeter]
Update=1000


[MeasurePosition]
Measure=Calc
Formula=(#SCREENAREAHEIGHT#-#CURRENTCONFIGY#-#CURRENTCONFIGHEIGHT#)
FinishAction=[!UpdateMeasure"MeasurePosition"]
DynamicVariables=1

example.gif

[Yincognito]

Good Evening <

The first step works. But I always need the data to be up to date when I move the skin. This only happens if I manually update the skin.

Code: Select all

[MeasurePositionY]
Measure=Calc
Formula=(#SCREENAREAHEIGHT#-#CURRENTCONFIGY#-#CURRENTCONFIGHEIGHT#)

Ypos.png

Besides the usual DynamicVariables=1 and potentially the [#nested] syntax for variables, just to be sure, it is true that the values of these variables will only change when the said measure is updated (typically via the Update in the skin and any existing UpdateDivider on the measure), since it's here where these values are used / requested. In other words, if you want a near real-time update of such values, the skin will have to be updated quite frequently.

That being said, maybe balala has more to add to this, a different take / view / perspective.

[Rooky_89]

Besides the usual DynamicVariables=1 and potentially the [#nested] syntax for variables, just to be sure, it is true that the values of these variables will only change when the said measure is updated (typically via the Update in the skin and any existing UpdateDivider on the measure), since it's here where these values are used / requested. In other words, if you want a near real-time update of such values, the skin will have to be updated quite frequently.

That being said, maybe balala has more to add to this, a different take / view / perspective.

^^ You are always too fast for me . I published the post and realized oops, I forgot something. Students are always slower than the teacher I have updated / adapted the source code and my contribution

[balala]

That being said, maybe balala has more to add to this, a different take / view / perspective.

No, I have not, excepting the fact that the FinishAction option is not valid on a Calc measure. It can be used on WebParser measure and on a few plugin measures (like Ping, RunCommand, FileView and so on), but not on a Calc measure. However the posted option doesn't cause any trouble, but strictly speaking it should be removed.

[Yincognito]

^^ You are always too fast for me

Nah, this time it just happened that I saw your unedited post 1 minute after you posted it, that's all. In my "usual" state, I'm not a fast person - I always think twice before saying or doing something, I prefer accuracy over speed, I edit my posts to correct typos or rephrase it more clearly, and so on.