Update Lag

[flyinghyrax]

In the current design, the numeric measure values will always be one update cycle behind.

It seems to go something like this:

1. On the first update cycle, call to Update() starts the background thread and immediately returns zero (since we can't block while the background thread to finishes).
2. In between updates (hopefully), the background thread finishes. If a FinishAction is set then that it is triggered (in the example skin, it updates all the FreeDiskSpaceMeasures). Rainmeter can use GetString to get the current string values at any time, even in between measure updates.
3. On the next update, cycle, call to Update() starts the background thread, and returns numeric values... which are from the last update, since the background thread hasn't finished by the time Update() returns.

...I'm not sure how to fix that. The only thing I can think of at the moment is to have plugin-specific UpdateRate like WebParser, so that the measure Update setting can be arbitrarily high without actually triggering a re-count of the disks on every update.

[Fred-Vatin]

This bug has been annoying me for years.

Here is a sample skin just to log what happens with current version:

[Rainmeter]

[MeasureDrivesList]
Measure=Plugin
Plugin=DriveList.dll
UpdateDivider=(5*60)
; Default string if the disk can't be accessed
DefaultString="disabled"
NumberType=Count
Fixed=1
Removable=0
Optical=0
Ram=0
Network=0
OnUpdateAction=[!Log "MeasureDrivesList Update = [#CURRENTSECTION#:]" Debug]
FinishAction=[!Log "MeasureDrivesList finish = [#CURRENTSECTION#:]" Debug]
DynamicVariables=1

;==========================

[MeterDriveCount]
Meter=String
SolidColor=0,0,0,200
Text=Update
Padding=20,20,20,20
StringStyle=NORMAL
FontColor=255,255,255,255
FontSize=50
StringStyle=BOLD
AntiAlias=1
ToolTipText="Clic me to update MeasureDrivesList"
DynamicVariables=1
LeftMouseDownAction=[!UpdateMeasure "MeasureDrivesList"]

[MeterDrag]
Meter=String
X=R
Y=r
W=25
H=25
SolidColor=0,50,200,150
ToolTipText="Drag me around"
DynamicVariables=1

Here is the debug (I manually update with a button for the 1st and 2nd update):

How weird is that! Especially for the 2nd update where the update and finish action differ. Advanced custom skin that rely on this plugin will properly work on the 2nd update.

Please consider to fix it.

[Fred-Vatin]

In the current design, the numeric measure values will always be one update cycle behind.

I confirm this annoying bug too.

[Fred-Vatin]

Maybe the plugin should implement a feature to be called with !CommandMeasure "ParentMeasureName" "Update" like the FileView plugin.