Weird "Include" behavior.

[jsmorley]

What your .gif demonstrates to me is that you have two sections called [Header], one in the skin, and one in the .inc file. Don't do that.

Sorry, but I'm not going to wade through this boatload of code, trying to figure this out.

[kyriakos876]

But it IS referencing itself.

You have
[Header]
Meter=String
;MeterStyle=Header

So ok, that isn't referencing itself yet, but it also isn't using any MeterStyle.

If you remove the comment, you break it. A MeterStyle can't reference itself. If you have another section called [Header] in your .inc file, that is a MeterStyle, that's fine, but depending on the order things are loaded in the skin, only one section called [Header] will ever be acted upon. One will win, and one will be ignored.

This is the normal code:

Code: Select all

[Header]
Meter=String
X=(#MaxWidth#/2)
Y=10
Text="Material Updates"
DynamicVariables=1

and in the variables I have this:

Code: Select all

[Header]
StringAlign=Center
FontColor=#AccentColor#
FontFace=Roboto
FontSize=(18*#WVar#)
AntiAlias=1

In the skin where all the code is in the .ini it works fine, but as as soon as I move it in another .txt file and call include it last, which is the same order as before, it doesn't work.

[kyriakos876]

What your .gif demonstrates to me is that you have two sections called [Header], one in the skin, and one in the .inc file. Don't do that.

Sorry, but I'm not going to wade through this boatload of code, trying to figure this out.

I thought this was a feature... you name a style the same with the meter and then you don't have to do MeterStyle=...

Fair enough. I will create a simpler example.

[jsmorley]

This is the normal code:

Code: Select all

[Header]
Meter=String
X=(#MaxWidth#/2)
Y=10
Text="Material Updates"
DynamicVariables=1

and in the variables I have this:

Code: Select all

[Header]
StringAlign=Center
FontColor=#AccentColor#
FontFace=Roboto
FontSize=(18*#WVar#)
AntiAlias=1

In the skin where all the code is in the .ini it works fine, but as as soon as I move it in another .txt file and call include it last, which is the same order as before, it doesn't work.

Do NOT have two sections with the same name. At best that is confusing. It may be working in one skin because it is loading in an order that has one of the [Header] sections being invoked, and in the other skin it's the other [Header] section that is being loaded first.

[jsmorley]

I thought this was a feature... you name a style the same with the meter and then you don't have to do MeterStyle=...

Fair enough. I will create a simpler example.

You can have a meter be a regular meter and a MeterStyle at the same time, sure. That is a "feature". It just can't use itself as a MeterStyle. Other meters can.

[kyriakos876]

You can have a meter be a regular meter and a MeterStyle at the same time, sure. That is a "feature". It just can't use itself as a MeterStyle. Other meters can.

It's not using itself as a MeterStyle tho... Anyway... I'm having a hard time simplifying the code to one meter and one style. I might have gone into some weird include loop and the style called [Header] for some reason can't be read by the meter called [Header] if it's in a .txt file or something like that...

[kyriakos876]

I changed the value of the X so that the meter will be out of the background and I realized that it's actually behind it...
It's like it loaded the variables.inc and then loaded first the meter [Header] and then the other meters of the skin... Which doesn't make sense... It should either load all the meters first and then the variables, or all the variables and then the meters... Loading one meter out of order is alien to me.

Annotation 2018-12-11 214846.jpg

There's even an image below this that has a Y=10R... why didn't it go below this or the next meter which would be the background? It's like it randomly moved 3 pixels down from 0.

[jsmorley]

Let's look at this:

Skin:

Code: Select all

[Rainmeter]
Update=100
AccurateText=1
DynamicWindowSize=1
MouseActionCursor=0

[Variables]
@Include=MyInclude.inc

[Header]
Meter=String
FontSize=15
FontWeight=#Weight#
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=Hello World

MyInclude.inc:

Code: Select all

[Variables]
Weight=700

[Header]
FontColor=255,0,0,255

Now with this setup, what happens is:

The MyInclude.inc file is read and inserted into the skin at the point it is invoked.
The [Variables] section is evaluated.
That sets the variable #Weight# to "700"
The [Header] section is evaluated.
That defines an option FontColor=255,0,0,255 (red)

Now the actual [Header] section is read.
The FontWeight option will use the variable #Weight# and be bold.
FontColor is read from the actual [Header] section and set to 255,255,255,255 (white)
Now... Rainmeter will attempt to deal the conflict with FontColor.
It will do that by placing the FontColor=255,0,0,255 (red) at the END of the meter.
This means that the original FontColor=255,255,255,255 (white) will be read "first".
The included FontColor=255,0,0,255 (red) that is in conflict will be read "last", and IGNORED.


Now if we change the skin:

Code: Select all

[Rainmeter]
Update=100
AccurateText=1
DynamicWindowSize=1
MouseActionCursor=0

[Variables]

[Header]
Meter=String
FontSize=15
FontWeight=#Weight#
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=Hello World

@Include=MyInclude.inc

Placing the @Include "after" the meter, then things change. The option FontColor=255,255,255,255 (white) is read, but then replaced by the FontColor=255,0,0,255 (red) from the @Include file. The color will be red.

It can all be a bit befuddling, I know.

[kyriakos876]

I understand, that's why I'm confused... I'm including all everything, and lastly the code.

Simplified, this is the .ini

Code: Select all

[Variables]
@Include=#@#Variables.inc
@Include2=#@#UpdateOutput\Updater.txt

This is the .txt

Code: Select all

[Header]
Meter=String
X=300
Y=10
Text="Material Updates"
DynamicVariables=1

Variables are called first as you can see, and then the meter is introduced. Shouldn't it work fine?

[jsmorley]

I am just NOT in favor of "merging" [SectionNames] by using @Include files. Use it to define shared [Variables], that's fine and really the original purpose. Having entire [Sections], be it measures or meters, in the @Include file is fine, although to be honest I think it is just an affectation if you are not "sharing" those measures or meters AS THEY ARE , between multiple skins in the suite.

"Merging" [SectionNames], trying to have measures or meters be "shared" between skins, but "modified" to be specific to each skin they are used in, is possible, but can be very difficult to get right. I recommend against it.

The point of @Include is primarily so you have a single place you can change something, and have that change reflected in multiple skins in the same suite. This is going to be most valuable with [Variables]. @Include is not intended to be some poor-man's MeterStyle. By all means, feel free to put MeterStyle sections in a .inc and call that from multiple skins, in that sense it is much like an external Style file in CSS, but I really don't like the idea of "merging" two same-named [Sections] using .inc files.