#include <LanguageHook.h>
◆ LanguageHook()
XBMCAddon::LanguageHook::LanguageHook |
( |
| ) |
|
|
inlineprotecteddefault |
◆ ~LanguageHook()
XBMCAddon::LanguageHook::~LanguageHook |
( |
| ) |
|
|
overridedefault |
◆ ClearLanguageHook()
void XBMCAddon::LanguageHook::ClearLanguageHook |
( |
| ) |
|
|
static |
◆ Constructing()
virtual void XBMCAddon::LanguageHook::Constructing |
( |
AddonClass * | beingConstructed | ) |
|
|
inlinevirtual |
This is a callback method that can be overridden to receive a callback when an AddonClass that has this language hook is on is being constructed. It is called from the constructor of AddonClass so the implementor cannot assume the subclasses have been built or that calling a virtual function on the AddonClass will work as expected.
◆ DelayedCallClose()
virtual void XBMCAddon::LanguageHook::DelayedCallClose |
( |
| ) |
|
|
inlinevirtual |
If the scripting language needs special handling for calls that block or are delayed in any other means, this should be overloaded.
In Python when control is passed to a native method that blocks, you need to allow other threads in Python to run by using Py_BEGIN_ALLOW_THREADS. When that delayed method ends you need to restore the Python thread state using Py_END_ALLOW_THREADS. This is the place to put that functionality
Reimplemented in XBMCAddon::Python::PythonLanguageHook.
◆ DelayedCallOpen()
virtual void XBMCAddon::LanguageHook::DelayedCallOpen |
( |
| ) |
|
|
inlinevirtual |
If the scripting language needs special handling for calls that block or are delayed in any other means, this should be overloaded.
In Python when control is passed to a native method that blocks, you need to allow other threads in Python to run by using Py_BEGIN_ALLOW_THREADS. This is the place to put that functionality
Reimplemented in XBMCAddon::Python::PythonLanguageHook.
◆ Destructing()
virtual void XBMCAddon::LanguageHook::Destructing |
( |
AddonClass * | beingDestructed | ) |
|
|
inlinevirtual |
This is a callback method that can be overridden to receive a callback when an AddonClass that has this language hook is on is being destructed. It is called from the destructor of AddonClass so the implementor should assume the subclasses have been torn down and that calling a virtual function on the AddonClass will not work as expected.
◆ GetAddonId()
virtual String XBMCAddon::LanguageHook::GetAddonId |
( |
| ) |
|
|
inlinevirtual |
This method should be done a different way but since the only other way I can think to do it requires an InheritableThreadLocal C++ equivalent, I'm going to defer to this technique for now.
Currently (for python) the scripting language has the Addon id injected into it as a global variable. Therefore the only way to retrieve it is to use scripting language specific calls. So until I figure out a better way to do this, this is how I need to retrieve it.
Reimplemented in XBMCAddon::Python::PythonLanguageHook.
◆ GetAddonVersion()
virtual String XBMCAddon::LanguageHook::GetAddonVersion |
( |
| ) |
|
|
inlinevirtual |
◆ GetCallbackHandler()
◆ GetInvokerId()
virtual long XBMCAddon::LanguageHook::GetInvokerId |
( |
| ) |
|
|
inlinevirtual |
◆ GetLanguageHook()
◆ MakePendingCalls()
virtual void XBMCAddon::LanguageHook::MakePendingCalls |
( |
| ) |
|
|
inlinevirtual |
◆ RegisterMonitorCallback()
◆ RegisterPlayerCallback()
◆ SetLanguageHook()
◆ UnregisterMonitorCallback()
◆ UnregisterPlayerCallback()
◆ WaitForEvent()
virtual bool XBMCAddon::LanguageHook::WaitForEvent |
( |
CEvent & | hEvent, |
|
|
unsigned int | milliseconds ) |
|
pure virtual |
The documentation for this class was generated from the following files: