Methode eines Plugins aus einem anderen Plugin aufrufen

Hallo neves,

Zitat

Original von neves
ich würde gern in einem Plugin eine Methode zur Verfügung stellen, die mit Parametern von anderen Plugins aufgerufen werden kann. Wie ich z.B. die MainMenuAction() aufrufe ist klar, allerdings kann ich da keine Parameter übergeben.
Hat da jemand 'ne Idee, bzw. gibt's da überhaupt 'ne Lösung?

Du kanst aus den anderen Plugin doch auf die Methoden des ersten Plugins zugreifen. Im Pluginmanager sucht Du die Klassse für das erste Plugin und rufts die Methode auf.

Wo ist Dein Problem?

Hardy

Du musst natürlich in dem anderen Plugin auch eine .h-Datei includen die das Interface definiert, und dann die cPlugin-Klasse die Du vom PluginManager bekommst auf die Ableitung casten.

Generell ist das zugreifen auf andere Symbole anderer Plugins, ausser dem was der PluginManager zu liefern in der Lage ist, NICHT möglich.

Hallo LordJaxom,

Zitat

Original von LordJaxom
Du musst natürlich in dem anderen Plugin auch eine .h-Datei includen die das Interface definiert, und dann die cPlugin-Klasse die Du vom PluginManager bekommst auf die Ableitung casten.

Das man das auch mit dem richtigen Object macht eine kleine Frage:

Wie kann ich die Klasse für ein Object feststellen? Ich hatte mal eine Funktion gefunden, jedoch ging sie nicht mit gcc.

Hardy

Zitat

Original von HFlor
Wie kann ich die Klasse für ein Object feststellen? Ich hatte mal eine Funktion gefunden, jedoch ging sie nicht mit gcc.

Suche mal nach RTTI (runtime type information)

http://www.google.com/search?q=using+rtti&btnG=Suche&hl=de

Use RTTI for Dynamic Type Identification (cont'd)
Using RTTI
To customize the menu dynamically, the file manager has to probe each files dynamic type.


Operator typeid
Operator typeid retrieves the runtime type information associated with a certain object. typeid takes an object or a type name as its argument. Thus, to determine if the dynamic type of x is Y, check whether the expression typeid(x) == typeid(Y) is true:




#include <typeinfo> // needed for typeid
void menu::build(const File * pfile)
{
 if (typeid(*pfile)==typeid(TextFile))
 {
  add_option("edit"); 
 }
 else if (typeid(*pfile)==typeid(MediaFile))
 {
 add_option("play"); 
 }
}

Andreas

HFlor:

Normalerweise sollte man davon ausgehen können, dass man wenn man vom PluginManager das xyz Plugin beantragt, man auch cPluginXyz bekommt :). Aber schau mal ins MP3-Plugin, dort wird typeinfo (s. Hulk) imho benutzt.

Hallo Andreas & LordJaxom,

Danke für die Info, ich brauche das an einer anderen Stelle um den Type des gerade aktiven Controll-Objekts zu erkennen ...

Hardy

Ich hab über das Problem in letzter Zeit auch nachgedacht, und bin mir nicht sicher, ob das so ohne Probleme klappt. Die Plugins existieren ja in separaten Modulen, und ein direkter Zugriff auf die Exporte eines anderen Plugins sollte eigentlich nicht möglich sein...

VDR lädt die Plugins über dlopen() und ohne RTLD_GLOBAL, daher sind die exportierten Symbole der Plugins nur über dlsym() erreichbar. Umgekehrt erbt das Plugin natürlich alle Symbole von VDR.

Und auch der Zugriff über dlsym() von einem Plugin zum anderen ist verwehrt, da VDR das Modul-Handle nicht ohne weiteres heraus rückt. Man könnte natürlich das andere Plugin nochmal in den Kontext des ersten Plugins einbinden, müsste dazu aber den Pfad zur Datei kennen. Leider ist auch cPluginManager::directory privat.

Es wäre auch möglich, den kompletten Code für die gemeinsamen Funktionen in beiden Plugins einzubinden, nicht nur die Header. Dann wäre der Programmcode aber doppelt vorhanden, und ich bin mir nicht sicher, ob die entstehenden Objekte dann auch noch wirklich den gleichen Typ haben.

Ganz katastrophal wird es natürlich, wenn die Plugins nicht exakt die gleiche Quelltextversion verwenden. Wenn sich der Speicheraufbau geändert hat, ist das Chaos vorprogrammiert.

Einen Trick hab ich aber noch ausgemacht: cPlugin::SetupParse() ist Public, kann also auch von anderen Plugins aufgerufen werden. Da liesse sich ein Interface durchtunneln. Und da unbekannte Setup-Variablennamen normalerweise ignoriert werden, kann noch nicht mal etwas schief gehen, wenn das angesprochene Plugin das Interface nicht unterstützt.

Klasse wäre es natürlich, wenn VDR so ein Interface von sich aus anbieten würde, in etwa virtual bool cPlugin::CustomInterface(char *InterfaceName, void *Data).

Gruß,

Udo