This may break backwards compatibility in some cases. For example, the FreeDiskSpace measure treated only `Type=1` as true and `Type={0, 2, 3, ...}` as false. Now `Type=0` is false and everything else is true like with most other boolean options.
This change is part of making the Libray project more testable. The old g_Rainmeter global pointer has been replaced with a GetRainmeter() function to guarantee that the object exists in some state.
Also fixes bug in MeterHistogram that crashes Rainmeter when the PrimaryImage is invalid.
Note: For Histogram the option is called PrimaryImagePath, SecondaryImagePath, and BothImagePath
- Replace swprintf/wsprintf/wcscpy/wcscat to _snwprintf_s/wcsncpy_s/wcsncat_s.
- Changed printf format parameter strictly for supporting both 32bit and 64bit.
- Fixed an issue that !RainmeterWriteKeyValue doesn't accept %APPDATA%\Rainmeter path.
- Code cleanup.
For BITMAP/BUTTON:
- Greyscale
- ImageTint
- ImageAlpha
- ColorMatrixN
- ImageFlip
Note: BITMAP and BUTTON are not able to support ImageRotate.
For HISTOGRAM:
- PrimaryGreyscale
- PrimaryImageTint
- PrimaryImageAlpha
- PrimaryColorMatrixN
- PrimaryImageFlip
- PrimaryImageRotate
- Secondary***
- Both***
Rainy, given the "issues" listed at the bottom of this comment, I leave it to you whether to create a build using this revision or use r208 for the build. I would like to start testing MeterStyle, but there are a few more things it needs work on.
What is MeterStyle?
MeterStyle
This will allow users to create CSS-like "Styles" for meters. This means that all the parameters of a meter can be defined in the style, and then many meters can use the style to eliminate copy / pasting the same parameters over and over on multiple meters. (Examples: FontColor=, FontSize= etc.)
How do I use it?
You will create a new [Section] (as many as you want) in the .ini. The section(s) can have any name.
[MyStringStyle]
Then you will tell Rainmeter that this is a "MeterStyle" and not a measure or meter
Style=Meter
Note: The "value" of the key "Style" can be anything. It can be used to add a description of the style if you like. Style=This style is for the AccuWeather part of this skin
It is however required, both to tell Rainmeter it is not a meter or measure and to have the MeterStyle routines parse it.
Then you define parameters you want to use in the style
FontColor=#FontColor#
FontFace=TheSansBold-Caps
FontSize=11
StringEffect=SHADOW
StringStyle=BOLD
StringAlign=LEFT
AntiAlias=1
Then in any or all meters, you just use
[MeterName]
Meter=STRING (or any other meter type)
MeterStyle=MyStringStyle
None of the parameters in the style are then required to be actually in the meter(s). They are "inherited" from the MeterStyle.
Note: This works and has had preliminary testing with dynamic variables like FontColor=[MeasureName] and regular variables like FontColor=#FontColor#. It doesn't matter if the [Variables] section or the [MeasureName] measure is before or after the [StyleName] in the .ini file.
What if I want to override a MeterStyle parameter on a meter?
Sure. Just put in any parameter with a value different from the one defined in the MeterStyle and the one in the meter will take presidence. All non-defined parameters will still use the MeterStyle value.
[MeterName]
Meter=STRING
MeterStyle=MyStringStyle
FontColor=100,100,100,50
What are these "known issues" you are on about?
This is still a bit of a work in progress. Right now you cannot define X or Y in a style. You can define W and H, but NOT for a STRING meter. You cannot define a "Transformation Matrix" in a style. MattKing will be looking into these tomorrow. W and H in a string meter is our top priority. We will also look at X and Y and hope for an easy solution. Transformation Matrix may have to come later.
Added the revision number to the about dialog (use UpdateRevision.py to update it).
Added a check to the startup which verifies that the rainmeter.ini is writable.
The skin folder can be opened from the context menu.
