On 13 Aug 2005 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Stefan Huelswitt wrote:
On 13 Aug 2005 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Stefan Huelswitt wrote:
Otherwise a plugins using Active() now, could compile fine with the next VDR version, but certainly wouldn't work correctly.
Is there any plugin that actually uses cThread::Active()?
Both mp3 & mplayer plugin do.
And are you sure that this is _really_ necessary? Do they _really_ want to determine whether the thread is still running, or would they just like to know whether it's time to return from the Action() function? I don't know the internals of these plugins, therefore my question.
I dunno if it's necessary, but for me it's common practice in a player plugin. The derived cControl class calls player->Active() so see if the derived cPlayer class (which in most cases is a cThread as well) is still running. Like in:
eOSState cMP3Control::ProcessKey(eKeys Key) { if(!player->Active()) return osEnd; [...]
But there are other cases where the call is usefull.
And yes, if Active() is called, I want to know if the thread is still running, as this is the only purpose of this function (up to now).
You may argue, that I'm using (the old) Active() in an incorrect way, but nevertheless I think that any API change should be made in a way that existing plugins either continue to work properly or fail to compile. Anything else will lead to massive confusion for the average user.
To make it worse, they don't access the old "active" var, so I guess your changes won't make them fail compile.
That variable was private to some derived cThread classes in VDR, so they couldn't have accessed them, anyway. I was referring to cases where plugins might have used an 'active' variable (or whatever they may have called it) in the same way VDR did.
You're right. My plugins use an own variable but in a similiar way as the internal one.
Regards.