It appears the conclusions here are correct - I didn't know about this particularity of hexa numbers in Rainmeter, thanks for pointing it out. So, it appears my old base converter skin will not yields the correct result when using a hexa notation as a starting point, despite the code being correct:

Code: Select all

```
[Variables]
Number=0xFFFFFFFF
Quotient=(#Number#)
Result=""
Base=10
[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
---Measures---
[MeasureConvert]
Measure=Calc
Formula=(#Quotient#%#Base#)
UpdateDivider=-1
RegExpSubstitute=1
Substitute="^10$":"A","^11$":"B","^12$":"C","^13$":"D","^14$":"E","^15$":"F","^16$":"G","^17$":"H","^18$":"I","^19$":"J","^20$":"K","^21$":"L","^22$":"M","^23$":"N","^24$":"O","^25$":"P","^26$":"Q","^27$":"R","^28$":"S","^29$":"T","^30$":"U","^31$":"V","^32$":"W","^33$":"X","^34$":"Y","^35$":"Z"
IfCondition=((#Quotient#)<>0)
IfTrueAction=[!SetVariable Result "[MeasureConvert]#Result#"][!SetVariable Quotient (Trunc(#Quotient#/#Base#))][!UpdateMeasure "MeasureConvert"]
IfConditionMode=1
DynamicVariables=1
---Meter---
[MeterConvert]
Meter=STRING
X=5
Y=5
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="Number = #Number##CRLF#Base = #Base##CRLF#Result = #Result#"
DynamicVariables=1
```

0xFFFFFFFF to Decimal.jpg

however, the reverse (i.e.

Number=4294967295 and

Base=16) will, giving the expected

FFFFFFFF:

4294967295 to Hexadecimal.jpg

Again, I come to the conclusion that strings are more reliable than numbers, especially in these cases. Not only the base conversion is a case of string manipulation, but representing the

0x... hexa number as a string could, in theory, avoid the type overflow problem.

P.S. I posted an adjustment of this in the

related thread, in case it will be needed someday.

You do not have the required permissions to view the files attached to this post.