This change brings the order of monitors close to the order of "Display Properties" due to using EnumDisplayDevices and EnumDisplaySettings instead of EnumDisplayMonitors. (If EnumDisplayDevices failed, EnumDisplayMonitors is used as before.)
-----
* Added the "Display Monitor" submenu in [Skins Menu]-[Position].
These menus convert the present position to the relative position from the specified monitor.
(But the meter window doesn't move to the specified monitor area immediately. Only converts.)
- "Use default: Primary monitor" removes the @-directive from WindowX/Y.
- @0(@1, @2, ...) adds the specified monitor number to WindowX/Y. @0 means "The Virtual Screen". (http://msdn.microsoft.com/en-us/library/dd145136%28VS.85%29.aspx)
- If "Auto-select based on window position" is checked, the WindowX and WindowY "@n" settings are made automatically based on the position of the meter's window. If a monitor is selected directly using "Display Monitor" in the Rainmeter / skin context menu, this menu is unchecked. This setting can be manually made in either the [Rainmeter] (all configs) or individual config sections of Rainmeter.ini.
AutoSelectScreen
If set to 1, the WindowX and WindowY "@n" settings are made automatically based on the position of the meter's window. If a monitor is selected directly using "Display Monitor" in the Rainmeter / skin context menu, this setting is reset to 0.
-----
* Added the variables for multiple display monitors and the virtual screen.
All X/Y positions are represented in the virtual screen coordinates.
The following variables are for the virtual screen.
#VSCREENAREAX# is the X-position of the left-side of the virtual screen.
#VSCREENAREAY# is the Y-position of the top-side of the virtual screen.
#VSCREENAREAWIDTH# is the width of the virtual screen.
#VSCREENAREAHEIGHT# is the height of the virtual screen.
The following variables are for the PRESENT monitor.
Note that these variables automatically change by the WindowX and WindowY "@n" settings. If "@n" is not set, these variables return the value of the primary monitor.
#WORKAREAX# is the X-position of the left-side of the work area.
#WORKAREAY# is the Y-position of the top-side of the work area.
#WORKAREAWIDTH# is the width of the work area.
#WORKAREAHEIGHT# is the height of the work area.
#SCREENAREAX# is the X-position of the left-side of the monitor screen.
#SCREENAREAY# is the Y-position of the top-side of the monitor screen.
#SCREENAREAWIDTH# is the width of the display resolution.
#SCREENAREAHEIGHT# is the height of the display resolution.
The following variables are for the PRIMARY monitor.
#PWORKAREAX# is the X-position of the left-side of the work area.
#PWORKAREAY# is the Y-position of the top-side of the work area.
#PWORKAREAWIDTH# is the width of the work area.
#PWORKAREAHEIGHT# is the height of the work area.
#PSCREENAREAX# is the X-position of the left-side of the monitor screen. (maybe, always 0)
#PSCREENAREAY# is the Y-position of the top-side of the monitor screen. (maybe, always 0)
#PSCREENAREAWIDTH# is the width of the display resolution.
#PSCREENAREAHEIGHT# is the height of the display resolution.
The following variables are for the SPECIFIED monitor. (@n = @1, @2, ...)
#WORKAREAX@n# is the X-position of the left-side of the work area.
#WORKAREAY@n# is the Y-position of the top-side of the work area.
#WORKAREAWIDTH@n# is the width of the work area.
#WORKAREAHEIGHT@n# is the height of the work area.
#SCREENAREAX@n# is the X-position of the left-side of the monitor screen.
#SCREENAREAY@n# is the Y-position of the top-side of the monitor screen.
#SCREENAREAWIDTH@n# is the width of the display resolution.
#SCREENAREAHEIGHT@n# is the height of the display resolution.
-----
* Other related changes:
- Fixed the problem that the primary monitor isn't recognized correctly.
- Fixed the problem that the information of the multiple display monitors is refreshed excessively.
- For DynamicVariables, when display setting or workarea size has been changed, all variables are now updated to apply changed WORKAREA/SCREENAREA variables.
- Fixed the problem that the "On Desktop" window isn't dragged correctly when the top-left corner of the virtual screen has negative coordinates.
- Changed the way to stick the "On Desktop" window. ("SysListView32/FolderView" is used instead of "Progman/Program Manager".)
-----
* Other changes:
- When the meter window is draggable and isn't dragged, LeftMouseUpAction is now executed.
- Added MouseDoubleClickAction (LeftMouseDoubleClickAction, RightMouseDoubleClickAction, MiddleMouseDoubleClickAction). If MouseDoubleClickAction is empty when mouse button is double-clicked, MouseDownAction is executed instead.
- Fixed the problem that the Meter's hit-test code checks outside the area.
- Changed the way to set the #CURRENTCONFIG#. (CMeterWindow::GetSkinName() is now used instead of parsing the path.)
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.
