My First Skin Help

[Yincognito]

you do.

Alright, the .ini itself isn't enough for a clear picture of the code, the Variables.inc should have been included as well, but luckily I still had one of my earlier versions of the skin in my "skin database", and reading a bit through the RainRGB4Readme hopefully made the issue quite obvious. The thing is, my previous advice about removing the FileName parameter from the context menu bang above was wrong, because apparently RainRGB4 requires both the VarName and the FileName parameters, as it changes the said variable in the specified file (hence why I said earlier that I wasn't 100% sure of what RainRGB expected). That means you can't achieve what you want by manipulating those parameters, because RainRGB will always write the last changed value of the variable in the Variables.inc file. However, a simpler alternative of "overriding" (but not "overwriting") that value right after Rainmeter reads the .inc should work. Something like:

Code: Select all

[Variables]
; Include weather settings and language variables 
@Include1=#@#WeatherComJSONVariables.inc
@Include2=#@#WeatherComJSONMeasures.inc
@Include3=#@#Variables.inc
FontColor=5,150,255

in the .ini file you posted would normally override whatever font color is read from Variables.inc when parsing the following line (aka last line in the code snippet above). This should set the color to the above at skin load, regardless of what other value for the color was written by RainRGB in the Variables.inc file when you change colors. No change is needed to the context menu action from the .ini file, so keep it as it is.

Let us know if this works!

P.S. If by any chance you want to also overwrite the value written by RainRGB in Variables.inc with the one above, you can add something like [!WriteKeyValue Variables FontColor "#FontColor#" "#@#Variables.inc"] as the first bang in the OnRefreshAction option from the [Rainmeter] section in the .ini file. This will work because the OnRefreshAction is executed after the first skin update, and by that time the variable is already initialized with the desired value.

[MourningStar]

...However, a simpler alternative of "overriding" (but not "overwriting") that value right after Rainmeter reads the .inc should work. Something like:

Code: Select all

[Variables]
; Include weather settings and language variables 
@Include1=#@#WeatherComJSONVariables.inc
@Include2=#@#WeatherComJSONMeasures.inc
@Include3=#@#Variables.inc
FontColor=5,150,255

...Let us know if this works!

thank you Yincognito. This works for the first part ("'force' the skin to display a specific color at pc power on") of the request but not the second part ("retain the flexibility of the 'Change Text Color' function" or in your own words "retain the ability to change the font color by using RainRGB"). When I clik to 'Change Text Color' and input a new value then clik ok the skin refreshes and displays with the 'forced' text color, i.e. the color specified in the code above.

[Yincognito]

thank you Yincognito. This works for the first part ("'force' the skin to display a specific color at pc power on") of the request but not the second part ("retain the flexibility of the 'Change Text Color' function" or in your own words "retain the ability to change the font color by using RainRGB"). When I clik to 'Change Text Color' and input a new value then clik ok the skin refreshes and displays with the 'forced' text color, i.e. the color specified in the code above.

Ah, I see what you mean. Indeed, a refresh will end up with the same forced color eventually. The solution would be to differentiate the "first load" of the skin from the subsequent RainRGB triggered refreshes. This can be done in various ways, for example by setting a variable to an initial value and then making sure it is set to a different value before or after RainRGB is executed in the context menu (some sort of "status" variable holding whether RainRGB has been ran or not yet), but I suppose the simplest method is to use a Calc measure's Counter function. That function will be either 0 or a number very close to 0 when the skin is initially loaded (after its "status" was previously unloaded / inactive), but will be something else than 0 or near 0 on the following refreshes. Take a look at this example and you'll see what I mean:

Code: Select all

[Variables]
FontColor=255,0,0

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[SkinUpdates]
Measure=Calc
Formula=Counter
IfCondition=(SkinUpdates<=1)
IfTrueAction=[!SetVariable FontColor "5,150,255"]
DynamicVariables=1

---Meters---

[Result]
Meter=String
FontFace=Consolas
FontColor=#FontColor#
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=SkinUpdates
Text="Skin updates since last inactive = %1"
LeftMouseUpAction=[!Refresh]
DynamicVariables=1

The skin will start with the 5,150,255 font color when "truly" or "first" loaded (or after an unload + reload combo), but will use the stored 255,0,0 aka red font color on either a manual refresh or a click on the skin (for convenience). The only thing you'd need to do is simply copy paste the [SkinUpdates] measure in your skin as the first measure - no context menu changes or overriding the variable like in the earlier attempts are needed. This should achieve both things in your request - sorry that I didn't come up with it earlier.

An alternative to this would be to add an OnCloseAction=[!WriteKeyValue Variables FontColor "5,150,255" "#@#Variables.inc"] option in the [Rainmeter] section in the skin, which will "reset" the color to the desired one when you unload the skin or close Rainmeter. However, while perfectly valid, this one has the potential to not work in the rare cases when Rainmeter could crash or hang, since the action won't get the chance to be executed then - not to mention it would need at least one "close" / unload of the skin to do its thing.

Note: Bear in mind that the above will reset the color to the desired one each time the skin is unloaded and then loaded again (i.e. when no refresh is involved), so it won't set the color strictly at "computer power on" or "user logon". If you absolutely need that, you'd need to use the USER_LOGONTIME option of a SysInfo measure and compare it somehow with the timestamp of a "now" Time measure to see if the logon time is close to the current time and if so, set the color accordingly. That would be trickier and a bit unreliable because that time difference varies from logon to logon based on various factors that can't really be controlled.

[MourningStar]

... but I suppose the simplest method is to use a Calc measure's Counter function.

Yes! Thank you sir.

[Yincognito]

Yes! Thank you sir.

Oh well ... piece of cake