Quantcast
Channel: Rainmeter Forums
Viewing all articles
Browse latest Browse all 698

Bugs & Feature Suggestions • [BUG/SUGGESTION] Inverted and negative low and high values in Clamp function

$
0
0
This has been bugging me for a long time, and I'm not sure if it's a classic bug, a weird feature or just something that would better classify as a suggestion for the future, so I'll just mention it here:

Code:

[Rainmeter]Update=1000AccurateText=1DynamicWindowSize=1---Measures---[GoodClamping]Measure=CalcFormula=Clamp(125,100,10)[BadClamping]Measure=CalcFormula=Clamp(-125,100,10)---Meters---[Result]Meter=StringSolidColor=0,0,0,255FontColor=255,255,255,255MeasureName=GoodClampingMeasureName2=BadClampingText=Good clamping = %1#CRLF#Bad clamping = %2DynamicVariables=1
Notice the value of the "bad clamping" and compare it with the "good clamping". I know the low and high values in the clamp function are reversed and neither is an actual "good" clamping since the order is invalid, but this is intentional, first to showcase the issue and second because it can be a "real world" scenario. For example, scrolling:

Code:

[Variables]TxtG=1#CRLF#2#CRLF#3#CRLF#4#CRLF#5#CRLF#6#CRLF#7#CRLF#8#CRLF#9#CRLF#10#CRLF#11#CRLF#12#CRLF#13#CRLF#14#CRLF#15#CRLF#16#CRLF#17#CRLF#18#CRLF#19#CRLF#20#CRLF#21#CRLF#22#CRLF#23#CRLF#24#CRLF#25#CRLF#26#CRLF#27#CRLF#28#CRLF#29#CRLF#30TxtB=1#CRLF#2#CRLF#3#CRLF#4#CRLF#5#CRLF#6#CRLF#7#CRLF#8#CRLF#9#CRLF#10OffsetY=0[Rainmeter]Update=1000AccurateText=1DynamicWindowSize=1---Meters---[ContainerVisible]Meter=ImageW=100H=242SolidColor=0,0,0,255MouseScrollUpAction=[!SetVariable OffsetY (Clamp(#OffsetY#+16.1,[Container:H]-[Text:H],0))][!UpdateMeter *][!Redraw]MouseScrollDownAction=[!SetVariable OffsetY (Clamp(#OffsetY#-16.1,[Container:H]-[Text:H],0))][!UpdateMeter *][!Redraw]DynamicVariables=1[Container]Meter=ImageW=100H=242SolidColor=0,0,0,255[Text]Container=ContainerMeter=StringFontFace=TahomaFontSize=10Y=#OffsetY#FontColor=255,255,255,255Text=#TxtG#DynamicVariables=1
Replace the value of the Text option in [Text] with #TxtB# and you'll realize what I mean. I know I can further clamp stuff or use conditionals to make it behave properly, but there is also the possibility of making it behave "correctly" by fixing the "bug" in the first place, and avoid making the formula unnecessarily longer. Unless, of course, the "bug" is some kind of feature to "toggle" between the invalid ordered low and high values... :confused:

P.S. Not sure about backward compatibility on this one, but I find it hard to believe someone would use the strange results of this case in a skin. I'm also not 100% sure of how a fix should be implemented, e.g. which value to choose between the invalid low and the invalid high ones. Hopefully you'll see this a bit clearer than I do at this time.

Statistics: Posted by Yincognito — Yesterday, 3:00 pm — Replies 1 — Views 454



Viewing all articles
Browse latest Browse all 698

Trending Articles