I see - well, Ping is a strange plugin / measure indeed.
Firing the FinishAction at the right time is great news, the other part, well, not so much. The reasons are simple:
- if the user wants to do other things in the OnUpdateAction than in the FinishAction, then having to update the measure in the FinishAction could mess things up in terms of skin functionality, since both sets of bangs would be executed
- as far as I can tell, since the plugin doesn't have a [!CommandMeasure "Update"] thingy, updating the measure in the FinishAction (whether it's done internally or not, unless there is a way to only get the value without actually pinging again) would basically mean the measure will issue another Ping request, so that would be logically inconsistent as well (e.g. which ping would we measure, the one corresponding to this FinishAction or the one we just sent by updating the measure?)
- updating the measure in the FinishAction would, as mentioned above, ping the address again, in turn creating another future FinishAction, which would have to update the measure again, creating a potential endless loop with questionable effects on the skin functionality (again, unless there is a way internally to just get the value via updating the measure, without triggering its actual execution again)
My code isn't that important in this case, as I don't have anything using a Ping measure's FinishAction in my skins and I only noticed this when trying to help another user, so I'm just trying to put myself in the shoes of the regular user for this one. I think the choice you'll make regarding this should consider going for the variant that messes things up the least, so as to be as clear as possible for others.
I was thinking that FinishAction could somehow "steal" the value from the correctly behaving OnChangeAction, but if the approach for the latter is also located in the plugin code, then that's a dead end as well (plus, not sure you could steal the value if it didn't change in the first place, besides the fact that this would be dependend on which event fires first, the OnChange or the Finish one).
Another possibility would be, now that the FinishAction fires at the right time, to have a note in the manual instructing user that if they need bangs to react to the measure
value they should use OnChangeAction (assuming they wouldn't want the bangs to be executed if the value stays the same, that is), and if they need bangs to react to the
moment when the ping response is received they should use the FinishAction. This wouldn't be the perfect solution either, as there might be some cases that would need to react to both at the same time, but at least wouldn't force anything anywhere.
Of course, there is also the "silent approach" in which we pretend this bug hasn't been discovered yet and that everything is just fine - after all, it's been at least 8 years without anyone but me noticing it, from what I'm aware of. A bit of an "imoral" choice, but it would leave fixing this properly for a time when it would be possible, e.g. a hypothetical update of the Ping plugin or such.
As far as I can tell, it's a difficult choice to make here. The irony is that almost all the other ways of getting or reacting to the value work, just not this one. The OnChangeAction would be the perfect way to provide either the value or the actions that would normally go in the FinishAction, except that it doesn't react when the value stays the same. Getting the right value in the FinishAction via cheating and stealing it from the almost concurrent OnChange action is tricky as well because of that and the possibility that the OnChange event happens after the Finish one, which would make getting the value for the latter by using the former impossible.
