QObject , more specifically is possible to get copy of a QObject-> and how?
-
because I can't initialize the object of the class as it is in a dll. I would have to use again QPluginLoader to load the QObject , which downgrades the performance in my opinion.
-
@ddze
Ok. but once the DLL is loaded. it normally stays loaded and you could just call the
function to / how you got the Qobject in first place?
Is it a Qt DLL, aka a plugin ? with interface?Yes it is dll and remains in the memory in a form of the QObject from which I QObject_cast to extract the class object. There is the problem ... because one instance of the QLoader is one instance of the QObject. Yes it is a class with an Interface.
-
Yes it is dll and remains in the memory in a form of the QObject from which I QObject_cast to extract the class object. There is the problem ... because one instance of the QLoader is one instance of the QObject. Yes it is a class with an Interface.
@ddze
As it should be. TheQObjectyou get is an entry point for the plugin and there is only one such thing. Define your interfaces, implement them in your plugin object, and use them to create whatever other objects you need. In principle it is possible to copy aQObject, but it's not simple and is troublesome. You should not want to do it in the first place.Kind regards.
-
@kshegunov Copying QObject is disabled for good reasons. See Identity vs Value
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@kshegunov Copying QObject is disabled for good reasons. See Identity vs Value
-
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 ?
-
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.
