|
|
On 29.03.06 10:32:30, Thiago Santos wrote:
> Hi, I'm developing an app that uses plugin and one of this plugins must emit
> a signal and when app receives that signal, than it does something.
>
> I have an interface like this:
>
> class MyPluginInterface : public QObject {
That is not a real interface anymore. Strictly speaking an interface
doesn't have any implemented methods, but yours does have those (the
signal is after all a method and subclassing QObject gives you a whole
lot of other methods).
> than I create the plugin itself like this:
>
> class MyPlugin : public QThread, public MyPluginInterface {
This doesn't work, because you try to inehrit from QObject twice. This
diamond shaped inheritance hierarchy often tells you that your design is
not appropriate.
If your plugin needs to emit this signal, than define the signal for the
plugin, not the interface. The interface only tells which functions are
available from any implementation of this interface.
You can still assume that every plugin implementing the interface emits
the signal and just connect it to a slot in your application. If the
plugin object that is created during runtime doesn't have such a signal
you'll get a warning duringt runtime from the connect-invocation telling
you so.
I'm not really sure if specifying a method with the signal-signature in
the interface would work as an enforcement of defining the signal in any
class implementing the plugin.
> 1. If I try to connect anything to my plugin on its constructor (for exemple
> the QTextEdit), compiler gives me an error of ambiguous base of QObject. If
> QThread was virtualy exteded QObject it was fine but this is not the case.
Not sure what you mean with "virtually extended QObject", but QThread
needs to be a QObject because it emits signals itself.
> 2. If I only connect to my plugin externaly, app compiles BUT, no signal is
> emited from plugin and I receive a message on console like: "There is no a
> 'foundACharacter(QChar)' signal on MyPlugin"
What do you mean by "connect to the plugin externally"? The message
tells you that yours MyPlugin doesn't have a signal called
"foundACharacter".
> I read a lot of comments about multiple inheritances and the most commented
> solution is change the app designer :D, well, I could do this but I'm out of
> ideas, if anyone wants to try out, please be my gest!
See my explanation above, make the interface purely abstract (no
implemented methods) and define the signal in the plugin (which is a
QObject through QThread).
> Now, about emitting signals from a plugin, I do not found any
> discution about it, anyone here knows anything?
The only difference between a plugin and a compiled-in class is that the
plugin gets loaded during runtime, whereas the compiled-in class gets
loaded on app startup. As long as the connect happens after "getting"
the plugin instance everything should be fine.
Andreas
--
Good night to spend with family, but avoid arguments with your mate's
new lover.
--
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/
|
|