Droptop not compatible with the most recent update. Causes below error. Cannot send an argument when executing the launch command for an executable. Does not happen in the previous beta update.
The addon used takes a string value and converts it into an integer. The command when executed is supposed to send the value in quotes as a string, but it sends the value as an integer, which my suspicion is what causes the exception.
Placing a fixed integer in quotes works normally (eg. "42"), but as a formula (eg. "[#CURRENTSECTION#]") does not work, even if the number is exactly the same.
Green highlight = Execute addon command with argument
Cariboudjan wrote: ↑June 26th, 2021, 10:04 pm
Droptop not compatible with the most recent update. Causes below error. Cannot send an argument when executing the launch command for an executable. Does not happen in the previous beta update.
Green highlight = Execute addon command with argument
The most recent beta fixed an incorrect behavior of the [!Delay ...] bang (see here and here), and I see a [!Delay 2000] in the highlighted option. Maybe the skin was counting on the previous (yet wrong) Rainmeter behavior and this is causing the issue? Though, if I think about it, there are no "bang replacement variables" as Brian called them here...
What I'm saying is that maybe the execution order is changed in this skin due to the last beta, if the skin was exploiting that previous behavior. Just guessing and trying to help here - I might got this wrong, but it is a possibility.
Cariboudjan wrote: ↑June 27th, 2021, 1:19 am
Thought of that looking at the change notes, but removing the !Delay does not stop the error.
The !Delay cerrtainly has a purpose there (I know because I used these methods as well to make sure some actions have time to properly finish before starting others), so I wasn't talking about removing, but rather changing its position in that option, say, to the end. Unfortunately I don't know precisely what those things do and I'm not familiar with the skin, so if I'm wrong and there's another culprit entirely, hopefully you'll forgive me for proposing futile attempts.
You may also place some [!Log ...]-s in various places there while loading the skin in the previous Rainmeter beta, in order to see exactly what was the expected order of operations in the skin then, or even compare if those orders match between Rainmeter versions by using [!Log ...]-s in the same places in the last beta.
Another possibility is that of the "special treatment" of !Delay conflicting with the "special treatment" of #CURRENTSECTION# in Rainmeter.
I can suppose that "[#CURRENTSECTION#]" could be a culprit in the TopReserve. You are technically using here nested variables, and Rainmeter mostly probably turns it "[#CURRENTSECTION#]" into "TopReserve#". Try logging what your "[#CURRENTSECTION#]" returns in the last beta it worked for you and in the current one.