QObject , more specifically is possible to get copy of a QObject-> and how?

ddze

QObject class has no a copy constructor therefore it is sort of harder to create another copy of it at different location in the memory. I have tried to swap the QObject pointers but did not work.

mrjj

Hi,
you are not allowed/cannot to copy QObjects due to identity and signal & slots.
So only option is to construct a new object and move/copy whatever data you wish replicated.
Can I ask why you need this?

ddze

@mrjj

QObject is a container of a class defined outside of the app.

mrjj

@ddze
Ok but why do you need to clone/copy it?

ddze

@mrjj

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.

mrjj

@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?

ddze

@mrjj

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.

kshegunov

@ddze
As it should be. The QObject you 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 a QObject, but it's not simple and is troublesome. You should not want to do it in the first place.

Kind regards.

SGaist

@kshegunov Copying QObject is disabled for good reasons. See Identity vs Value

kshegunov

@SGaist
I know it is, I also understand the reasons very well. Note the bold-faced comment.

mrjj

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 ?

ddze

@mrjj

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 ...

SGaist

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

@SGaist

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

kshegunov

@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.

ddze

@SGaist ,

the article about why the copy of the QObject is disabled has mentioned the cloning. But there is no any clone functionality available either. Is it possible to do the cloning of the QObject somehow?

ddze

@kshegunov

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.

kshegunov

@ddze
If you need many instances of your MyClassInterface then 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 many MyClassInterface instances as you wish.

ddze

@kshegunov

reasonable suggestion, most likely the way to do this.

Thanks @kshegunov

kshegunov

@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.