Hi,
I'm trying to display an OSD message from a separate thread within a plugin to indicate when some background action has finished. The message should pop up no matter if there's currently an OSD displayed or not. So SVDRP MESG is no solution, since this will only appear when leaving the OSD.
I tried it with the new service interface. The thread calls a service of the plugin passing the message. The service itself calls
Skins.Message(serviceData->type, serviceData->message);
This works fine, but sometimes crashes VDR in cSkins::Message. I've found a way to reproduce it: When the main menu is displayed and the message pops up then pressing BACK while the message still is displayed crashes VDR. In this case the problem is that in
cSkinDisplay::Current()->SetMessage(Type, NULL);
cSkinDisplay::Current() is NULL. Don't know if this is a bug or just the result of my wrong usage ;-) Is there any other way to display a message from a thread?
BR,
Christian
Christian Wieninger wrote:
Hi,
I'm trying to display an OSD message from a separate thread within a plugin to indicate when some background action has finished. The message should pop up no matter if there's currently an OSD displayed or not. So SVDRP MESG is no solution, since this will only appear when leaving the OSD.
I tried it with the new service interface. The thread calls a service of the plugin passing the message. The service itself calls
Skins.Message(serviceData->type, serviceData->message);
This works fine, but sometimes crashes VDR in cSkins::Message. I've found a way to reproduce it: When the main menu is displayed and the message pops up then pressing BACK while the message still is displayed crashes VDR. In this case the problem is that in
cSkinDisplay::Current()->SetMessage(Type, NULL);
cSkinDisplay::Current() is NULL. Don't know if this is a bug or just the result of my wrong usage ;-) Is there any other way to display a message from a thread?
There is currently no way of doing this. I'm not sure if there will be one in version 1.4.
What's so important about your message that it can't wait?
Klaus
En/na Klaus Schmidinger ha escrit:
What's so important about your message that it can't wait?
Even if it could wait it doesn't make a difference, does it? I mean the cPlugin::PopUp method isn't implemented yet.
Bye
En/na Klaus Schmidinger ha escrit:
Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
What's so important about your message that it can't wait?
Even if it could wait it doesn't make a difference, does it? I mean the cPlugin::PopUp method isn't implemented yet.
I was just wondering...
I was just hoping I missed it ;-)
Bye
On Saturday 19 November 2005 10:45, Klaus Schmidinger wrote:
What's so important about your message that it can't wait?
nothing ;-) In the next release of epgsearch one can trigger the search timer update also manually. I would only like the give the user a feedback, when the update is done. And I think it's much more comfortable to display this info when it really has finished and not when the OSD is closed.
ok, I'll drop it and wait ;-)
BR,
Christian
Christian Wieninger wrote:
On Saturday 19 November 2005 10:45, Klaus Schmidinger wrote:
What's so important about your message that it can't wait?
nothing ;-) In the next release of epgsearch one can trigger the search timer update also manually. I would only like the give the user a feedback, when the update is done. And I think it's much more comfortable to display this info when it really has finished and not when the OSD is closed.
Is that OSD menu one from your own plugin? In that case you could easily make the thread store it's message somewhere, and have your menu display it in the next call to its ProcessKey() function.
Klaus
Is that OSD menu one from your own plugin?
not always, depends on what the user does and the runtime of the update thread (normaly some seconds). Leaving epgsearch, calling main menu or another plugin.
In that case you could easily make the thread store it's message somewhere, and have your menu display it in the next call to its ProcessKey() function.
thanks! good idea. I'll try it.
Christian
There is currently no way of doing this. I'm not sure if there will be one in version 1.4.
What's so important about your message that it can't wait?
There will be several cases where a plugin wants to access the main thread. There should be a clear and reliable mechanism to do this.
If you have a look at how this problem is solved in Qt, you see that there you send a QCustomEvent through the event to a QObject. Transferred to a more abstract level, this means: - access and possibly wake up the event loop - an addressee - possibility to store private data - every request for access will result in exactly one access, as soon as possible as soon as all other events have been processed
For VDR, this might mean: - add a mechanism to the event loop (cRemote) - the addressee and private data problem is solved when an object implementing a simple pure virtual interface is provided by the caller
Marcel
Marcel Wiesweg wrote:
There will be several cases where a plugin wants to access the main thread. There should be a clear and reliable mechanism to do this.
- access and possibly wake up the event loop
- an addressee
- possibility to store private data
- every request for access will result in exactly one access, as soon as
possible as soon as all other events have been processed
What about this approach: Secure most of the main loop with a spin lock, and release the lock before sleeping in the event loop. Before processing the next key event, lock again. By locking that spin lock, a thread can catch the main thread sleeping, and keep it sleeping until whatever non-threadsafe has been done. The user thread will not become main thread, but at least the main thread will not interfere.
However, this doesn't solve the popup problems, eg. a simple way to activate a cOsdObject without abuse of MainMenuAction.
Cheers,
Udo
Christian Wieninger wrote:
I tried it with the new service interface. The thread calls a service of the plugin passing the message.
This doesn't switch the threads, so your service will be called from inside your thread too. Calling one's own service interface has no advantage over just calling any function directly.
Is there any other way to display a message from a thread?
There is still the hard way to catch the display: Use cRemote::CallPlugin() to call your own MainMenuAction and display the message from there. Disadvantages: - Current OSD and menus will be closed in any case. - Possible race conditions inside CallPlugin may cancel your MainMenuAction call, this may be compensated by some timeout handling.
Cheers,
Udo
Am Freitag, 18. November 2005 16:32 schrieb Christian Wieninger:
'm trying to display an OSD message from a separate thread within a plugin to indicate when some background action has finished.
Some Plugin try this and failed. But it is easy to send a signal or flag to your main thread. my patch of dvd Plugin:
regards movimax
Hi,
Markus Hahn schrieb:
Some Plugin try this and failed. But it is easy to send a signal or flag to your main thread. my patch of dvd Plugin:
regards movimax
thanks! But the problem is, that the user can be anywhere when the thread has finished. In any other plugin or in one of VDR's menus. So handling the message only in my plugin won't be a solution. I do it now with SVDRP. Perhaps there will be a better solution in one the next VDR releases.
Thanks for your help!
BR,
Christian
-
Christian Wieninger -
Klaus Schmidinger -
Luca Olivetti -
Marcel Wiesweg -
Markus Hahn -
Udo Richter