QObject , more specifically is possible to get copy of a QObject-> and how?
-
Hi
I assume you have something like
QString myplug = qApp->applicationDirPath() + "/plugins/myplugin.dll";
QPluginLoader loader (myplug);
QObject* plugin = loader.instance();
MyPluginInterface* myplugin_interface = qobject_cast<MyPluginInterface*>(plugin);
// call function
myplugin_interface->SomethingXXX();If u need more object from inside DLL, make a interface function that gives you what you need.
If we still completely miss the point ;), could you please provide some code and more info about this plugin ?
I know that part as you showed I have already one instance of the plugin. The problem is that instance is sort of a template to drag and drop on a QGraphicsScene surface. The QMimeData has its own limits and I could not convert with best of my effort (including implementing<< >> operators to extract features on the scene , did not work.
So the idea was to use the ordinary QMimeData as the media info about the data type in the QDropEvent than select an already initiataed MyInterface object as a template to copy it to different part of the free space. Since the copy of the QObject does not work ... very few options are left. I have already done << >> operators overloading but even that not completely since I can't use the << operator to stream a QGraphicsItem member.
Perhaps to give up on QPluginLoader and load dll's differently, and into different containers not to QObject ...
-
Why not stream the data you need to create a new QGraphicsItem based on the "old one" ?
By the way, QGraphicsItem is not a QObject.
-
Why not stream the data you need to create a new QGraphicsItem based on the "old one" ?
By the way, QGraphicsItem is not a QObject.
I could do that , but the QGraphicsItem part has no any info about the internals of MyInterfaceClass , for example , I would not be able to call a particle function from my class ... only the parts inherited from QGraphicsItem. So basically I need the access to the interface
-
I could do that , but the QGraphicsItem part has no any info about the internals of MyInterfaceClass , for example , I would not be able to call a particle function from my class ... only the parts inherited from QGraphicsItem. So basically I need the access to the interface
@ddze
I'm not quite sure I understand what exactly you're trying to achieve, but you could create your graphics items in the plugin (on demand from the main application) and then pass them to the scene, or even return them as objects. Then your factory (incidentally being the plugin) has access to whatever internal data it needs to populate the graphics items. -
Why not stream the data you need to create a new QGraphicsItem based on the "old one" ?
By the way, QGraphicsItem is not a QObject.
-
@ddze
I'm not quite sure I understand what exactly you're trying to achieve, but you could create your graphics items in the plugin (on demand from the main application) and then pass them to the scene, or even return them as objects. Then your factory (incidentally being the plugin) has access to whatever internal data it needs to populate the graphics items.yes but you are talking only on one instance, I would ....but I need either to copy and later modify its content (which is near impossible as i see) or a cloning of MyClassInterface object to multiple ones 1 ...* from single plugin dll QObject. The graphical part is just graphical ....(by the way the class inherits the QGraphicsItem object and implements the Paint ... so it draws itself no problem.
-
yes but you are talking only on one instance, I would ....but I need either to copy and later modify its content (which is near impossible as i see) or a cloning of MyClassInterface object to multiple ones 1 ...* from single plugin dll QObject. The graphical part is just graphical ....(by the way the class inherits the QGraphicsItem object and implements the Paint ... so it draws itself no problem.
@ddze
If you need many instances of yourMyClassInterfacethen you shouldn't implement that interface in the plugin class. Instead add another interface to the plugin class that allows for you to create as manyMyClassInterfaceinstances as you wish. -
@ddze
If you need many instances of yourMyClassInterfacethen you shouldn't implement that interface in the plugin class. Instead add another interface to the plugin class that allows for you to create as manyMyClassInterfaceinstances as you wish. -
@ddze
No problem. As I mentioned the plugin acts (mostly) as a factory for objects, not as a data class, or GUI element. You simply request some feature (some object representing the feature) from the plugin, it creates it and returns an instance. Usually you don't expect the plugin object itself to provide the actual implementation of the feature, but to provide you with the means to obtain it. I hope I'm making sense.Kind regards.
-
@ddze
No problem. As I mentioned the plugin acts (mostly) as a factory for objects, not as a data class, or GUI element. You simply request some feature (some object representing the feature) from the plugin, it creates it and returns an instance. Usually you don't expect the plugin object itself to provide the actual implementation of the feature, but to provide you with the means to obtain it. I hope I'm making sense.Kind regards.
I see, acts as 1 ..1 association.
