Thanks for reporting. This has been fixed, sort of.
The crash actually happens in a CRT function provided by Windows. While we can't fix the actual issue, we can prevent the CRT from crashing Rainmeter by handling the invalid parameter in this case.
We had to do this for the time measure in the past.
I also added a generic error message to the log in these cases (if Debug=1). It won't help much to identify "where" the problem is, but at least it won't crash Rainmeter. An actual debug build of Rainmeter (or using Visual Studio in debug mode) will log which function,file, line number and expression....but I'm pretty sure not too many people do this.
-Brian
PS - The Lua docs never say anything about removing leading zero's for os.date like strftime does with # (even though os.date does use a version of strftime under the hood).
The crash actually happens in a CRT function provided by Windows. While we can't fix the actual issue, we can prevent the CRT from crashing Rainmeter by handling the invalid parameter in this case.
We had to do this for the time measure in the past.
I also added a generic error message to the log in these cases (if Debug=1). It won't help much to identify "where" the problem is, but at least it won't crash Rainmeter. An actual debug build of Rainmeter (or using Visual Studio in debug mode) will log which function,file, line number and expression....but I'm pretty sure not too many people do this.
-Brian
PS - The Lua docs never say anything about removing leading zero's for os.date like strftime does with # (even though os.date does use a version of strftime under the hood).
Statistics: Posted by Brian — Today, 6:55 am