Plugin measure value formatting on context menu?

[MetalTxus]

I see. It makes sense to sacrifice a rarely used part of the feature in order to enhance it's general performance.
I tried removing only one file from the bin and then deleting another one and the count and size recalculated properly so I will assume everything is working as expected.

As always, thanks for the support and teaching

[jsmorley]

Sure thing.

[jsmorley]

BTW

This line in your posted code:

OnUpdateAction = [!Redraw]

Accomplishes exactly nothing other than using a small amount of CPU to no end.

!Redraw on its own does nothing. It simply tells Rainmeter to redraw the skin window, using whatever values are already in place for everything. There can never be any visible or useful change from the last time the skin was redrawn by the normal update cycle.

What !Redraw is used for is to work in conjunction with !UpdateMeasure (sometimes) and !UpdateMeter (always) to force some change to happen "now" instead of waiting for the next normal update cycle.

You are really never going to want that in an OnUpdateAction either. You are simply forcing the skin to redraw exactly the same, twice. Once in the normal update cycle, and once with your !Redraw. That is where the tiny but real hit to CPU for no purpose comes about.

What you are intending in your measure can be accomplished with:

Code: Select all

IfBelowValue = 1
IfBelowAction = [!SetOption ImageTrash ImageName "#@#icons/Recycle Bin (empty).png"][!UpdateMeter ImageTrash][!Redraw]
IfAboveValue = 0
IfAboveAction = [!SetOption ImageTrash ImageName "#@#icons/Recycle Bin (full).png"][!UpdateMeter ImageTrash][!Redraw]

The goal is to have the measure get a value. Then you "test" the value. If the test changes from "false" to "true", you want to !SetOption the ImageName option on the meter. Then you want to !UpdateMeter the meter, so it actually uses that new image option right now. Then you want to !Redraw to update things visibly. The idea is to force targeted bits of the update cycle, just the bits that are "changing", right NOW, before the next normal update cycle hits.

One could argue that this isn't needed in this specific case anyway, as with just the !SetOption alone, the normal update cycle is going to visibly change things anywhere from at least 1 millisecond to at most 999 milliseconds later with Update=1000. That isn't a very significant lag from the time you make a change to the contents of the recycle bin and when it appears in the skin. Generally you are going to use [!UpdateMeter SomeMeter][!Redraw] when you need things to be really "responsive", mostly when you click on things and fire mouse actions. Still, it does no harm and I can see a perfectionist's argument for it.

[MetalTxus]

BTW

This line in your posted code:

OnUpdateAction = [!Redraw]

Accomplishes exactly nothing other than using a small amount of CPU to no end.

Thanks for telling me, I just copy-pasted that from somewhere else and as it didn't seem to work without it I left it that way.
I've now fixed all my skins with that line accordingly so, thanks again

[jsmorley]

Thanks for telling me, I just copy-pasted that from somewhere else and as it didn't seem to work without it I left it that way.
I've now fixed all my skins with that line accordingly so, thanks again

Glad to help. Didn't mean to get too far down in the weeds, but it can really help to wrap your head around how the Update cycle in Rainmeter works.

Start Update cycle
Update all measure values, for each, take any "actions" driven by action options
Update all meter options and obtain measure values to be used
Redraw the skin window
Wait for the value in Update to elapse to start over

In addition, any "event driven" actions like LeftMouseUpAction or MouseOverAction that are on the skin or on a meter are executed immediately when they happen.

At the end of the day, that is all there is to Rainmeter. While it can seem kinda daunting at first, with just boatloads of measures and meters and options and actions, if you "get" the Update cycle, you are 90% of the way there. The rest is all just icing on the cake.

So the "bangs" that can be used to "short circuit" the Update cycle, to have thing happen in a very responsive "now" way, sorta fit like this:

!Update : Start Update cycle
!UpdateMeasure : Update specific / group / all measure values, take any "actions" driven by action options
!UpdateMeter : Update specific / group / all meter options and obtain measure values to be used
!Redraw : Redraw the skin window

One other bang, not so much related to the Update cycle, but of interest in this conversation, is

!Refresh : Starts the entire skin over, re-reads the skin's .ini file, and in effect unloads and reloads the skin.