Simple countdown timer

[Yincognito]

The hide/show patterns are irregular which makes things inaccessible. I don't know how to turn on or off the timer. Settings button just shows the action chooser buttons. When the timer starts, it shows 00:00 00 and then starts the count.

It happens for me too, and I agree - from a functional POV.

LMAO. True tho. It shortens the code. And sometimes they are the only option. If not, that's where I come in...

...making a big ass script for simple things, which you claim can be done in native Rainmeter.

Indeed. Where long formulas whose math the user can't understand won't do, even longer scripts in an language the user can't understand will definitely do - for good. Like he won't dare to ask a question anymore, he'll pretend everything's solved and thank everybody for the effort, then run away like hell.

Not sure what the issue is?
Edit: I see the problem. I'll work on it. But I think it's the sort of thing that needs a formula!

Welllll, since you mentioned this so nice and all... ... the [mUptime] is 0 when you refresh to reset the timer (not sure why you've done that, as the original reset method worked fine, but then I'm not that familiar with the code particularities afterwards). Not sure exactly why, since the process seems ok to me, pausing is done, and the value of Seconds variable also seems ok.

EDIT: Found it: the [mUptime] is not executed on refresh, unlike the original code. Just add:

Code: Select all

OnUpdateAction=[!Log "Seconds = #Seconds#, mUptime = [mUptime]"]

to it and you'll see.

[death.crafter]

Like he won't dare to ask a question anymore, he'll pretend everything's solved and thank everybody for the effort, then run away like hell.

Don't spill the beans

[Yincognito]

Don't spill the beans

Don't worry, godfather balala will save us all: he'll just make a nicely list formatted set of modifications the user has to make, then the user will respectfully say he read it all, will copy paste the code and voila - problem solved.

[balala]

Don't worry, godfather balala will save us all: he'll just make a nicely list formatted set of modifications the user has to make, then the user will respectfully say he read it all, will copy paste the code and voila - problem solved.

I'm entirely glad you think so, but this topic has became extremely long, so what should I exactly do? Sorry I don't know, but...

[death.crafter]

I'm entirely glad you think so, but this topic has became extremely long, so what should I exactly do? Sorry I don't know, but...

We were just kidding around lol. Nothing of concern.

[Yincognito]

I'm entirely glad you think so, but this topic has became extremely long, so what should I exactly do? Sorry I don't know, but...

Oh, no, I didn't mean you should do something, I was just joking around about the habits of various folks trying to help on the forums: I'm with the complicated code/formulas, death.crafter is with lots of scripts, you are with nicely detailed info about what the user should do. So, just a bit of fun, nothing serious, when it comes to that specific post.

[balala]

Oh, no, I didn't mean you should do something, I was just joking around about the habits of various folks trying to help on the forums: I'm with the complicated code/formulas, death.crafter is with lots of scripts, you are with nicely detailed info about what the user should do. So, just a bit of fun, nothing serious, when it comes to that specific post.

[Yincognito]

Not sure what the issue is? [...] I'll work on it. But I think it's the sort of thing that needs a formula!

Well, I identified the culprit on the timer being set to 0 on refresh or timer reset issue, and found the solution as well. Hint: it's about the order of sections in the skin. See, I was trying to convey some points in other threads regarding this: try to replicate as much as possible the order in which Rainmeter itself does things in a skin, or otherwise you'll encounter some more or less strange effects. It's not necessarily about whether the order matters or not, but about the skin designer having a clear picture of the workflow in front of his eyes.

This is more or less what I referred to when saying earlier in the thread that I have a feeling that you leaned back towards the "skin shuffling mode"...

P.S. This can be solved in other ways besides changing the order of sections, it's just that doing the latter is simpler.

[sl23]

the [mUptime] is 0 when you refresh to reset the timer (not sure why you've done that, as the original reset method worked fine, but then I'm not that familiar with the code particularities afterwards). Not sure exactly why, since the process seems ok to me, pausing is done, and the value of Seconds variable also seems ok.

That's not something I would touch really. Maybe I accidentally changed something?

[Yincognito]

That's not something I would touch really. Maybe I accidentally changed something?

In your code, the OnRefreshAction correctly pauses the TimerGroup measures, so that the timer starts stopped on skin load (that action happens after one skin update, by the way, check the link to the manual). However, since the TimerGroup measures are further down the code and [mProcessTimerStart] ALSO pauses the group when none of your triggering APPs are running, what happens is that at skin load/refresh [mProcessTimerStart] stops the group before they have the chance to run once, like they should according to the OnRefreshAction (thus, [mUptime] is temporarily 0 at skin load/refresh or timer reset).

Not sure about what your process is, but you can either:
- move the TimerGroup before all the measures, so it runs once before the [mProcessTimerStart] pauses it
OR
- find a way to not "double pause" the group at skin load/refresh (specifically, the extra pause in [mProcessTimerStart])

I have no idea if this changes the expected behavior of your restrictive timer approach, I just mentioned the culprit and some of the possible solutions. The rest is up to you.