When FontSize is dynamic size, and a skin is read, the error of "Unable to create font: ..." appears. This is a simple example.

[MeasureFontSize] Measure=Calc Formula=((Counter % 5) + 1) * 10

[MeterFont] Meter=String W=300 H=100 FontSize=[MeasureFontSize] DynamicVariables=1

Text=Text

• Rainmeter1.1 r306 32bit
• Windows XP, 7

The combination of using the word "dynamic" and including "DynamicVariables" in you example may unintentionally misdirect readers.

The problem exhibts when the variable "FontSize" is not a number.

I can't find a relationship between the problem and the "DynamicVariables" parameter.

Yes, you are right. Actually, the direct cause that shows the error is not "DynamicVariables". The reason for the direct cause is that FontSize is 0. When using Calc, even if it defines the value fixed like "Formula=20", Calc certainly returns 0 once at the time of loading of a skin.

In order to try dynamic font size, there is no method except using "DynamicVariables", and it is a formula to use Calc for this approach. That is, the occurrence of the error doesn't escape if it tries to change the font size dynamically. The problem which I point out is not about the defect of one function, and it is about the practical trouble by the collision of some functions.

I am not sure but I think that it should check off of an error message about FontSize. Because this error doesn't have the meaning so much. Is there on earth a user who defines it by mistake as "FontSize=0"?

I believe this is the error I get upon satart after install. dried the zip and the download .exe both with same unusable install, app just shows fine lines on screen, any ideas. did not find help in forums through search. Using Win7Pro

I'd change it so as not to indicate the error when DynamicVariables=1 and FontSize=0.

Changed in r328.

Thank you for taking care of this issue. Although I reported the problem which mentioned DynamicVariables as the example here, it is not actually the problem limited to DynamicVariables.

A definition like "FontSize=", "FontSize=0", "FontSize=ABC" should be ignored as an invalid definition. However, it is substance of the problem that such an invalid definition is not ignored.

Now, as for DynamicVariables, it seems that the problem was solved by r328. However, on DynamicVariables=0, an error message still appears by invalid definition. To prevent the user's confusion, I think that it should not display an error message by an invalid definition and should set a default value.

A result of "FontSize=", "FontSize=0", "FontSize=ABC" will be 0 because these are converted loose by ConfigParser. It's possible to change it in FontSize so that the default value (=10) is used instead of 0. (However, even if you'd like to use "FontSize=0" dynamically by DynamicVariables=1, 10 is used instead.)

Yes, I was also concerned about the point. It is inconvenient that the default value (FontSize=10) is set on DynamicVariables=1 as you say. So, does the following behavior become possible?

• "FontSize=" or "FontSize=ABC" is evaluated as invalid definition so the default value is set.
• "FontSize=0" is evaluated as valid definition, but it is invisible. (error message is not needed)

These are irrespective of setting of DynamicVariables and are common behavior. I think that this behavior is natural and is proper solution for now. How do you think about this?

I agree. I'd try to change the loose parsing to the strict.

Try this.

• CHANGED: ConfigParser now reads value strictly. Note that this change affects the reading of various skin setting values.

For instance: - OK FontSize=10 FontSize=0 - NG (uses default value instead) FontSize= FontSize=ABC FontSize=20ABC (has been parsed as "FontSize=20" until now.)

I have confirmed accurate behavior now. Thanks. I appreciate it.

Changed in r330.