'Formula syntax error' reported for working measures.

[YGKtech]

I'm working on a skin using dozens of measures, and taking full advantage of the ability to place formulas everywhere. And as far as I can tell it's working, but the log disagrees.

every time I load the skin, the log fills up with instances of "Formula: Syntax error" followed by some equation. Here's a sample of the log:


Formula: Syntax error in key "H" in [Border]
Formula: Syntax error: ([cH]*1.5 + [cOffsetY]*6)
Formula: Syntax error: ((([cW] - [cDent])*19 + ([cOffsetX]*20)) -8)
Formula: Syntax error: ([cH]*0.5)
Formula: Syntax error: ([cW]*0.5)
Formula: Syntax error: ([cH]*1.5 + [cOffsetY]*6)
Formula: Syntax error: ((([cW] - [cDent])*19 + ([cOffsetX]*20)) -8)
Formula: Syntax error: ([cH]*0.5)
Formula: Syntax error: ([cW]*0.5)
Formula: Syntax error: ([cH] + [cOffsetY]*4)

This goes on for a while, this only happens during a refresh, the update cycle runs perfectly.

most if not all of the errors are from MeterStyle sections kept in a .inc file, variables are kept in another .inc file.

The errors seem to be reported for every formula I have that uses a measure as a variable outside of a calc measure. If I remove the parentheses the errors disappear, but the equation is not evaluated and rainmeter just grabs the first value that appears in the expression.

The punchline to all this is that the skin is functioning perfectly, but I don't want to release it while it reports errors.

[jsmorley]

What this sounds like is a "cart-horse" issue where when the skin is refreshed and those formulas are evaluated, the measures you are referencing in them have not yet been created / populated. This is due to the fact that you get one "round" of errors on refresh (and most likely on first load) and then it behaves correctly.

Not sure it it helps, but you might want to take a look at this page:

http://rainmeter.net/cms/Tips-Include

With an eye to the stuff under "Understanding @include". There may be something there that can address your issue by better "positioning" the information in the include files in the parent skin. I'm not sure, as I really only use @Include for variables, so I don't have a lot of stick time with any subtle issues related to putting stuff using dynamic calls to measures in them.

[Kaelri]

Would you mind posting your complete skin (ideally as a .rmskin, but a .zip is fine)? You can also PM it to me if you'd rather not make it public yet.

[eclectic-tech]

JSMORLEY "hit it on the nose"

I was experiencing exactly the same formula syntax errors after moving several measures to an "included" file...

You need to copy just the [movedmeasurename] for the moved measures, back into the INI file to eliminated the formula syntax errors...

SAMPLE:

Code: Select all

[Rainmeter]
 ...

[Variables]
blahblah=1
moreblahblah=100

...(Now add the moved measures NAMES ONLY!)

[FirstMovedMeasureName]

[SecondMovedMeasureName]

...etc...

[LastMovedMeasureName]

... (Here starts the rest of your measures and meters)

The Measure names must match the ones that will be loaded from the include file...
And do not enter the formulas, just the measure name in brackets[]!

When the include file is loaded the measures will appear where you added the [movedmeasurename].

The errors appear because all include files are NORMALLY added AT TO THE END (BOTTOM) OF THE INI file. This forces them to appear in "proper" order in the ini file.

This cleared all of my formula syntax errors on refresh. The errors where annoying, but did not effect the performance of the skin from what I could tell.

[MerlinTheRed]

Shouldn't Rainmeter load all included files and meters/measures/everything in them before linking them together? This behaviour seems a little wrong to me...

[smurfier]

What I believe is actually happening...

The formulas are parsed in any meters/measures in order from top to bottom. If the measure has not been created when it reaches a [Measure] in the formula, then an error is logged.

Probably the easiest way to fix this is to put all the measures in an @include, and all the meters in another. Put the @include for the measures in the file first.

[YGKtech]

Thanks for all the tips everyone, I'll be working on the skin tonight and now I have some good ideas on what to do.

Attached is a .rmskin of the project as it stands. It's rather unfinished right now, but it is functional. It's a resource monitor (eventually it may be more than that) and some of the measures use the coretemp plugin, and return 0 unless coretemp is running.

EDIT: updated the .rmskin with the newer version.

[YGKtech]

Shifting the meters into a .inc file seems to have eliminated the errors, though there is still a slight quirk around the refresh cycle.

As far as I can tell the [Border] image meter is being rendered before it's H value is properly calculated. The purpose of the meter is simply to extend the border of the skin beyond the bottom of the hexagons, I do this by making a square in the bottom right corner with H = (#offset# + [cH]) where [cH] is the height value for all the hexagon image meters and offset is the intended thickness of the border extension. During the refresh cycle the square renders with H = [cH] and moments later re-renders with H = (#offset# + [cH]), resulting in a visible 'bob' in the position of the meter on a refresh and initial load. To see the two step rendering in action just change the ImageAlpha on the [Border] meter and refresh, it's very noticeable.

There are zero errors in the log when I refresh, and I have moved the [Border] section to the top of the meters .inc file, and the variables.inc file is at the top of the @include order, so I'm really at a loss as to why this is happening.

I'll update the .rmskin file to the current version.

Thanks

[poiru]

Shouldn't Rainmeter load all included files and meters/measures/everything in them before linking them together? This behaviour seems a little wrong to me...

Yep. We've improved things for Rainmeter 2.4 beta

As far as I can tell the [Border] image meter is being rendered before it's H value is properly calculated. The purpose of the meter is simply to extend the border of the skin beyond the bottom of the hexagons, I do this by making a square in the bottom right corner with H = (#offset# + [cH]) where [cH] is the height value for all the hexagon image meters and offset is the intended thickness of the border extension. During the refresh cycle the square renders with H = [cH] and moments later re-renders with H = (#offset# + [cH]), resulting in a visible 'bob' in the position of the meter on a refresh and initial load. To see the two step rendering in action just change the ImageAlpha on the [Border] meter and refresh, it's very noticeable.

I cannot reproduce this. [Border] is always rendered with H=75 here.

[YGKtech]

Interesting... the 'bob' on refresh had persisted through several revisions to the code and system reboots, but no I simply dragged the skin off of the edge it was snapped to, and it stopped. After returning the skin to its original position it's still gone, leading me to think the problem was something to do with the rainmeter.ini and the fact that I have not dragged the skin away from that edge since I added the [Border] meter.

While the problem is of course solved, I do find it rather interesting. My instincts as a programmer are telling me it's probably a result of rainmeter trying to render the skin with the top right corner in the same position as it was when the skin was shorter, only bringing it back up when a later process checks for compliance with the 'Keep on screen' setting. This assumes that for some reason the rainmeter.ini file wasn't updated properly, and I don't know the source code well enough to know if that's possible or not.

I'll see if I can re-create the bug to see if it's a problem in rainmeter or something I did (I was cleaning out my rainmeter.ini around the same time, IDK if it was even on the sme day as the [Border] addition, but if it was I may have done something to mess it up).

EDIT: Found it, took all of 30 seconds to find the glitch.

Comment out the [Border] section. Refresh the skin, and drag it to the bottom edge of your screen. Un-comment [Border] and refresh the skin, it will lift away from the edge as expected. Hit refresh again and you should see the skin drop down the the edge and then move back again.

Watching the Rainmeter.ini entry during this process confirmed that the WindowY value did not change after un-commenting [Border] and refreshing. Not sure if such a corner case is worth patching, but I do believe this counts as a bug