How refresh automatically skin after loaded?

[balala]

No refresh is needed in this case.

In fact there are extremely few cases when a refresh is relly required. Usually all users should look extremely sceptically to refresh. Paraphrasing jsmorley, it is a "big gun".
Recommend to always avoid it if possible. Me personally for sure tend to do so.

[CodeCode]

No need to use a substitution. The Time measures have formats for abreviated month names as well, so why susbtitute? For instance the Format = %B option of the [MeasureMonth] measure should be replaced the Format = %b to get the names abreviated from the beginning, without a substitution.

For personal preference - so intrinsically abbreviating July to Jul is sort of illogical since it would fit (presumably) in the base text area of the skin.

[Yincognito]

In fact there are extremely few cases when a refresh is relly required. Usually all users should look extremely sceptically to refresh. Paraphrasing jsmorley, it is a "big gun".
Recommend to always avoid it if possible. Me personally for sure tend to do so.

Yes, that's true. I don't think it's about being skeptical to refresh, as it's a valid bang and useful in a few situations (basically, when looking to "update" a modified @Include file), it's just that in most cases it's pointless to resort to a full skin reload when you can quite easily do the job without. I also avoid using it, mostly in order to not have to "reset" all the variables or measures to their initial values (which can be undesirable in most situations, depending on the skin complexity).

[Yincognito]

For personal preference - so intrinsically abbreviating July to Jul is sort of illogical since it would fit (presumably) in the base text area of the skin.

Yeah, it generally looks a bit strange to abbreviate a 4 character string to a 3 character one, but I've seen strager than that. In the end, those abbreviations are sort of standard way of expressing months in a limited space, even though in some cases the whole 4 character string would fit. To follow your logic, letting a string to have its full 4 characters when the others are abbreviated to just 3 characters would probably seem equally illogical...

Just joking a bit, but isn't it interesting how a logical thing (like what you said) can also lead to an illogical outcome?

[balala]

I don't think it's about being skeptical to refresh, as it's a valid bang and useful in a few situations (basically, when looking to "update" a modified @Include file),

Yeah, for sure it is valid and the manual refresh also can be done, it's not about this. The above case, along with the case when you do want to reload the updated skin, are probably the only cases when a refresh is indeed needed.

[WirlyWirly]

Thanks @balala, that seems to work much better!

For testing purposes (because I didn't want to wait until tomorrow to see the change), I made a measure for seconds and used that in-place of the date number. When the number changes, the month doesn't re-align itself with the new value. Therefore overlap occurs.



Any ideas on how to get around this? Since the month is aligned relative the right-side of the date number (Which is in a fixed position), I don't see how I would get it to align relative to the left-most part of the date number.

skin.ini

Code: Select all

[RainMeter]
Update = 1000
AccurateText = 1
BackgroundMode = 2
SolidColor = 0,0,0,1
DynamicWindowSize = 1
LeftMouseDoubleClickAction = ["https://www.windy.com"]


[Variables]
@Include = #@#Variables.inc

;=============================
;	MEASURES
;=============================

[MeasureMonth]
Measure = Time
Format = %B

[MeasureDay]
Measure = Time
Format = %A

[MeasureDateNumber]
Measure = Time
Format = %d

[MeasureMinutes]
Measure = Time
Format = %M
IfCondition1 = (MeasureMinutes = 00)
IfTrueAction = [!Refresh]

[MeasureSeconds]
Measure = Time
Format = %S
MinValue = 0
maxValue = 60

;=============================
;	METERS
;=============================

[MeterDateNumber]
Meter=String
Group=SlashFont
MeasureName=MeasureSeconds
X=330
Y=0
StringAlign=Right
FontFace=#boldFont#
FontColor=#SlashUnfocused#
FontSize=62
Antialias=1

[MeterMonth]
Measurename=MeasureMonth
Meter=String
X=-95r
Y=15r
StringAlign=Right
FontFace=#mediumFont#
FontColor=#Grey#
FontSize=30
Antialias=1

[MeterDay]
Meter=String
Group=SlashFont
Measurename=MeasureDay
X=0r
Y=-10R
StringAlign=Right
FontFace=#mediumFont#
FontColor=#SlashUnfocused#
FontSize=18
StringAlign=Right
Antialias=1

[Yincognito]

When the number changes, the month doesn't re-align itself with the new value. Therefore overlap occurs.



Any ideas on how to get around this? Since the month is aligned relative the right-side of the date number (Which is in a fixed position), I don't see how I would get it to align relative to the left-most part of the date number.

Even if you do (which I guess could be done using R instead of r in relative positioning, or using [MeterDay:W] in the formula for the month's X value), the month will "wobble" to different positions when the day meter gets wider or narrower. This is why I recommended setting a certain W (i.e. width) for meters like the day one - for example the maximum width the day can take, in order to keep things "stable" and not "wobbling around", which may for some look disturbing.

EDIT: Disregard the above, it's not really needed, as a simple decrease of X=-95r to something like X=-115r in [MeterMonth] would suffice. In theory, it's more or less the same thing as setting a fixed width for [MeterDay], since we talk about similar hardcoded / constant values.

[balala]

When the number changes, the month doesn't re-align itself with the new value. Therefore overlap occurs.



Any ideas on how to get around this? Since the month is aligned relative the right-side of the date number (Which is in a fixed position), I don't see how I would get it to align relative to the left-most part of the date number.

Use the already proposed [MeterDateNumber:W] section variable in the X option of the [MeterMonth] meter, which is returning the width of the [MeterDateNumber] meter. For instance use the following X option: X=-[MeterDateNumber:W]r. Since this option uses a section variable ([MeterDateNumber:W]), it requires to add a DynamicVariables=1 option to the [MeterMonth] meter as well, so don't forget it.
If you want to move the month even more to left, add (extract) a constant value to the above X option, for example: X=(-[MeterDateNumber:W]-15)r.

[WirlyWirly]

Gotcha, I was missing that DynamicVariable part. The month does move based on the date, which is what I want, so everything's working great now.

I learned a good amount about relative positioning and aligning, which I used to clean up the skin a bit. Thanks a bunch for everyone's help!

[CodeCode]

I learned a good amount about relative positioning and aligning, which I used to clean up the skin a bit. Thanks a bunch for everyone's help!

Relative positioning is my favourite tricksey code for rainmeter. It can be used in so many creative ways. Along with Inline options, or container shapes, relative positioning comes in really handy.