It is currently February 16th, 2019, 2:11 am

[SOLVED] Strange @include Meter Behavior

Report bugs with the Rainmeter application and suggest features.
User avatar
raiguard
Posts: 544
Joined: June 25th, 2015, 7:02 pm
Location: The Sky, USA

[SOLVED] Strange @include Meter Behavior

raiguard » January 20th, 2019, 11:25 pm

Hello. I was making some changes to my CPU skin in order to improve performance on low-end PCs when I came across a strange issue with @include files. I created a sample skin to demonstrate the issue.

The sample skin displays up to 64 rows of numbers, and has 64 dummy measures to go along with them. These meters and measures are separated out into several @include files, and the skin has logic to select the appropriate files depending on what the #num# variable is set to:
2019-01-20 15_57_38-Output.inc - Rainmeter (Workspace) - Visual Studio Code.png
Each file only includes the meters/measures that are unique to it, then also has an @include for the previous file. This way, when the logic selects Include24.inc, it will also have the code from the previous two files:

Include24.inc (Measures):

Code: Select all

[IncludeSection]
@includeMeasures16=Include16.inc

[MeasureText17]
Measure=Calc
Formula=17

[MeasureText18]
Measure=Calc
Formula=18

[MeasureText19]
Measure=Calc
Formula=19

[MeasureText20]
Measure=Calc
Formula=20

[MeasureText21]
Measure=Calc
Formula=21

[MeasureText22]
Measure=Calc
Formula=22

[MeasureText23]
Measure=Calc
Formula=23

[MeasureText24]
Measure=Calc
Formula=24
All of this is done in order to make the skin leaner for those who don't need 64 rows of measures and meters. In CPU Meter, this can drastically increase performance, decreasing the file size from 5,334 lines to 1,658 lines for those who have 8 threads or less.

Now, on to the actual issue!

Normally, the skin looks like this, if you have #num# set to 6:
2019-01-20 16_04_39-.png
But if you increase #num# to anything greater than 8 (in this case, 20), this happens:
2019-01-20 16_06_42-.png
For some strange reason, all of the meters from any previous files start at Y=0, and are placed behind all of the other meters in the skin!

I spent a good while debugging this, trying to figure out what was going on. Then, I discovered that if I comment out the measures @include in the base skin's code, it fixes itself!
2019-01-20 16_09_54-.png
After more testing, this is what I discovered:

- If you comment out the measures @include in the base skin, the problem disappears
- If you set the measures @include to always include Include8.inc, then the problem never occurs
- Changing the number of measures in each @include doesn't help
- If I go ahead and copy the code from each previous @include into the one that is being used, the problem disappears

I suspect that this is a bug with @includes, because honestly, I can't come up with any other explanation...

The .RMSKIN contains the example skin and all of its include files. I also added an extremely watered-down version of my CPU Meter to aid with testing.

I'd appreciate any help!

Here's the code for the base sample skin, for those who are away from their PCs:

Code: Select all

[Rainmeter]
MiddleMouseUpAction=[!Refresh]
AccurateText=1

[StyleString]
FontFace=Calibri
FontSize=9
FontColor=230,230,230
X=5
Y=#rowSpacing#R
Antialias=1

[StyleStringCenterAlign]
X=(#bgWidth# / 2)
Y=r
StringAlign=Center

[StyleStringRightAlign]
X=(#bgWidth# - 5)
Y=r
StringAlign=Right

[Variables]
num=32

; DO NOT CHANGE
rowSpacing=0
bgWidth=100
includeNum=32

; ----- Measures -----

[MeasureSetFile]
Measure=Calc
Formula=(#num# > 8) ? ((#num# > 16) ? ((#num# > 24) ? ((#num# > 32) ? ((#num# > 48) ? 64 : 48) : 32) : 24) : 16) : 8
IfCondition=MeasureSetFile <> #includeNum#
IfTrueAction=[!WriteKeyValue Variables includeNum "[MeasureSetFile]"][!Refresh]
DynamicVariables=1

; If you comment out this @include, the problem disappears...
@includeMeasures=Includes\Measures\Include#includeNum#.inc

; ----- Meters -----

[MeterBackground]
Meter=Image
SolidColor=15,15,15
W=#bgWidth#
H=[MeterBackgroundHeight:Y]
DynamicVariables=1

[MeterBeforeTest]
Meter=String
MeterStyle=StyleString
Y=3
Text=Before

@includeMeters=Includes\Meters\Include#includeNum#.inc

[MeterAfterTest]
Meter=String
MeterStyle=StyleString
Text=After

[MeterBackgroundHeight]
Meter=Image
SolidColor=255,255,255,0
Y=2R
W=100
H=1
Rainmeter 4.3.0.3277 beta (64-bit)
Language: English (1033)
Build time: 2019-01-19 7:23:01
Commit Hash: c224b70b
Windows 10 Pro 1803 64-bit (build 17134) - English (1033)
Path: C:\Program Files\Rainmeter\
SkinPath: D:\Settings\Caleb\Rainmeter\Skins\
SettingsPath: C:\Users\Caleb\AppData\Roaming\Rainmeter\
IniFile: C:\Users\Caleb\AppData\Roaming\Rainmeter\Rainmeter.ini
You do not have the required permissions to view the files attached to this post.
Last edited by raiguard on January 21st, 2019, 5:41 am, edited 1 time in total.
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017
User avatar
Brian
Developer
Posts: 1844
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: [Bug?] Strange @include Meter Behavior

Brian » January 21st, 2019, 5:28 am

The problem is you have multiple [IncludeSection] sections used in both your measure and meter includes. Try renaming each one to something unique.

https://docs.rainmeter.net/manual/skins/include-option/
Rainmeter Docs wrote:If there is a conflict - that is, if the same section exists in more than one file - Rainmeter will treat whichever one comes first in the ordering as the "real" section. Any options on the later instances will be added to the first one, and otherwise the later instances are simply ignored. If there are different values given for the same key, the last value is taken. Unlike new sections, options on pre-existing sections are added in their original order, so the calling section may overwrite values from the included file if they are placed below the @include statement.
-Brian
User avatar
raiguard
Posts: 544
Joined: June 25th, 2015, 7:02 pm
Location: The Sky, USA

Re: [Bug?] Strange @include Meter Behavior

raiguard » January 21st, 2019, 5:41 am

Well I'll be, that solved it. I can't believe I didn't realize that... I knew deep down that that's how the functionality worked, but I didn't make the connection. :headbang:

Anyway, thanks!
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017