[geloest] Signals von Plugins disconnecten

[stonecold]

Hallo,

ich habe eine Anwendung geschreiben, welche Plugins laed. Zur Zeit soll immer nur ein Plugin aktiv sein. Gibt es eine Moeglichkeit die vom Plugin emittierten Signale zu disconnecten, wenn das Plugin nicht mehr aktiv sein soll?

Danke schonmal fuer eure Antworten und Gruss,
Mario

[Christian81]

http://doc.trolltech.com/4.6/qobject.html#disconnect-3 würde ich sagen.

[stonecold]

Moin Christian,

danke fuer den Tipp. Habe die ganze Zeit danach geschaut das Signel des Senders zu disconnecten so gehts natuerlich auch.

Allerdings habe ich jetzt festgestellt, dass ich das Signal des Plugin nicht connecten kann. Ich ein Plugin ein QObject?

Hier mal kurz etwas Beispielcode vom Plugininterface. Funktiert das mit dem Signal eigentlich?

Code: Alles auswählen

class cPluginInterface
{

public:	
	virtual ~cPluginInterface() {};

	virtual STM_PLUGIN_IF::tError				connect(const char* port)						= 0;
	virtual STM_PLUGIN_IF::tError				disconnect()									= 0;

	virtual QString								getPluginName()									= 0;
	virtual STM_PLUGIN_IF::tPluginWidgetList*	getPluginWidgetList()							= 0;

	virtual STM_PLUGIN_IF::tError				refreshData()									= 0;
	virtual STM_PLUGIN_IF::tError               setEnabled(bool enabled)						= 0;

signals:
	void fetchingSpeedSignal(unsigned int speed);

protected:
	STM_PLUGIN_IF::tPluginWidgetList mPluginWidgetList;
};

Q_DECLARE_INTERFACE(cPluginInterface, "com.blafasel.www.cPluginInterface")

Wobei ich gerade feststelle, dass connect und disconnect vom Namen her vielleicht nicht so gut gewaehlt sind.

Gruss,
Mario

[Christian81]

cPluginInterface muss in diesem Fall natürlich von QObject ableiten - sonst keine Signals und Slots.

[stonecold]

Okay das mit dem QObject ist gemacht. Was ist jetzt mit dem Q_OBJECT Macro? Muss es mit in das PluginInterface oder in die Klasse, welche von Interface ableitet?

Funktionieren tut beides irgendwie nicht.
Packe ich das Macro in die Interfacedatei, die einmalig im Projekt der Mainapplikation liegt, bekommen ich bei den Plugings folgende Fehlermeldungenen beim Linken unabhaenig davon ob sie das Signal emittieren oder nicht.

Code: Alles auswählen

1>mpk2000_plugin.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual struct QMetaObject const * __thiscall cPluginInterface::metaObject(void)const " (?metaObject@cPluginInterface@@UBEPBUQMetaObject@@XZ)".
1>mpk2000_plugin.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual void * __thiscall cPluginInterface::qt_metacast(char const *)" (?qt_metacast@cPluginInterface@@UAEPAXPBD@Z)".
1>mpk2000_plugin.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual int __thiscall cPluginInterface::qt_metacall(enum QMetaObject::Call,int,void * *)" (?qt_metacall@cPluginInterface@@UAEHW4Call@QMetaObject@@HPAPAX@Z)".

Mache ich das Macro in die erbende Klasse bekomme ich beim Linken des Plugins, welches das Signal emittieren will folgende Meldung.

Code: Alles auswählen

error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""protected: void __thiscall cPluginInterface::fetchingSpeedSignal(unsigned int)" (?fetchingSpeedSignal@cPluginInterface@@IAEXI@Z)" in Funktion ""protected: void __thiscall ST2810D_Plugin::speedSlot(enum ST2810D::tSpeed)" (?speedSlot@ST2810D_Plugin@@IAEXW4tSpeed@ST2810D@@@Z)".

Das Makro in das Interface und in die erbende Klasse zu schreiben fuehrt ebenfalls zu Fehlern.

Was mache ich falsch?

Gruss,
Mario

[Christian81]

Foren-Suche würde ich sagen...

Q_OBJECT muss rein, und der HEADER muss in der pro-Datei eingetragen sein.

[stonecold]

Okay, jetzt gehts. Zumindest laesst es sich kompilieren. Das Q_OBJECT Macro muss mit in die Klasse und der Header mit in das Projekt.

Danke und Gruss,
Mario