Item in a DLL not getting events

[Benne Gesserit]

I am having a little trouble with dll´s and items .
I had some custom items that worked fine.I had an abstract item that inherited QGraphicsItem , an item (it was a node in a diagram ,so I will cal it node) that inherited that abstract custom item ,a text item that was part of the abstract one and inherited QGraphicsTextItem (hopefully you understand this because I didnt explain it very well) and an arrow that inherited from QGraphicsItem.
My first attempt ,to make it simpler ,was to make a dll that just exported a function that returned a pointer to a node .In the dll ,of course ,there was more code ,but not exported .I could create it ,put it on a scene and view it with a view,call some functions to inicialice it....but the events were not delivered to them .The funny (and annoying) thing is that the other items that I ve created (except for the abstract one,of course) are getting the events just as usual .For example , the node had a filter event for his text item : the text item is getting events ,but they dont go through the filter .
I tried to also export the item clases I had created ,and link my aplication against the dll (with dynamic link ,because it doesnt run without the dll) :nothing changed .
The only difference between the clases that dont work and the ones that works (the only one I ve noticed)....well I dont know how to explain it (I m new to dll s) ,so ...lets see:
http://img228.imageshack.us/img228/2193/dllxc8.jpg
This is some kind of view of the dll on eclipse .For example ,the arrow class (in arrow.h and arrow.cpp) is working , but the nodofuente class (nodofuente.cpp ,the node) is not working .As you can see (well ,believe me because you dont see the whole dll) the dll doesnt "include" (or whatever) the .h file of the class that is not working .I dont know what this means or even if it means something at all and has something to do with my problem .
Any help will be really ,really,really apreciated .
Thanks in advance .

[luf]

Hi

Sorry to say, but I cannot get your problem.

But for using a dll, move all the dll source files to 1 project, create a pro file that creates a lib.

include the .h file in the application that you want to use the dll in.
use QLibrary to load the dll. (dynamic linking).

make sure to put Q_DECL_EXPORT when you compile as library on your class and Q_DECL_IMPORT when you include the header file in your application.

something like this:
mylibrary.pro

CONFIG += dll
DEFINES += COMPILING_LIBRARY
 
#then comes your sources and headers... remember to add LIBS += mylibrary.lib in your application pro file

CONFIG += dll
DEFINES += COMPILING_LIBRARY

#then comes your sources and headers... remember to add LIBS += mylibrary.lib in your application pro file

To copy to clipboard, switch view to plain text mode 

mylibrary.h

#ifdef COMPILING_LIBRARY 
	#define MYLIBRARYEXPORT Q_DECL_EXPORT
#else
	#define MYLIBRARYEXPORT  Q_DECL_IMPORT
#endif
 
class QFD_USB_LIB_EXPORT MyLibraryInDLL: public QWidget
{
    Q_OBJECT
 
public:
	MyLibraryInDLL(QWidget *parent);
}

#ifdef COMPILING_LIBRARY 
	#define MYLIBRARYEXPORT Q_DECL_EXPORT
#else
	#define MYLIBRARYEXPORT  Q_DECL_IMPORT
#endif

class QFD_USB_LIB_EXPORT MyLibraryInDLL: public QWidget
{
    Q_OBJECT

public:
	MyLibraryInDLL(QWidget *parent);
}

To copy to clipboard, switch view to plain text mode 

myapplication.cpp

#include "mylibrary.h"
QLibrary *loadmylibrary = new QLibrary("mylibrary", this);
loadmylibrary->setLoadHints(QLibrary::ResolveAllSymbolsHint);
loadmylibrary->load();
if (loadmylibrary->isLoaded() == false)
{
     // error didn't load... do something!
}

#include "mylibrary.h"
QLibrary *loadmylibrary = new QLibrary("mylibrary", this);
loadmylibrary->setLoadHints(QLibrary::ResolveAllSymbolsHint);
loadmylibrary->load();
if (loadmylibrary->isLoaded() == false)
{
     // error didn't load... do something!
}

To copy to clipboard, switch view to plain text mode 

cheers,
Leif

[Benne Gesserit]

Ok .... ok,very interesting .
I was building the dll in a normal c++ shared library project on eclipse .I did not copy the sources , but told the project to look for them in the correct folder (I think this makes no difference) .So I did "the same" but with the _declspec(dllimport) and stuff .But ,as I said ,I didnt hace to explicit load the dll , because the application automatically loaded it .
I have one doubt :

(...)remember to add LIBS += mylibrary.lib in your application pro file (...)

Did you mean mylibrary.dll?
And MYLIBRARYEXPORT instead of QFD_USB_LIB_EXPORT?
Thank you very much .

[luf]

Sorry... my bad!
should be like this:

mylibrary.h

#ifdef COMPILING_LIBRARY 
	#define MYLIBRARYEXPORT Q_DECL_EXPORT
#else
	#define MYLIBRARYEXPORT  Q_DECL_IMPORT
#endif
 
class MYLIBRARYEXPORT  MyLibraryInDLL: public QWidget
{
    Q_OBJECT
 
public:
	MyLibraryInDLL(QWidget *parent);
}

#ifdef COMPILING_LIBRARY 
	#define MYLIBRARYEXPORT Q_DECL_EXPORT
#else
	#define MYLIBRARYEXPORT  Q_DECL_IMPORT
#endif

class MYLIBRARYEXPORT  MyLibraryInDLL: public QWidget
{
    Q_OBJECT

public:
	MyLibraryInDLL(QWidget *parent);
}

To copy to clipboard, switch view to plain text mode 

The only reason to load it is if you want to make sure it's loaded before calling a function. As that makes you able to handle a loading-library-error... If not, your app will just crash if there is a problem loading the library. (e.g. the user moved it).

As you say, you don't have to move the files. It was just a suggestion to keep projects like:
Application
--- library1
--- library2
--- library3
--- library3a
--- library3b

Just to make it easier for your self if the projects grows and gets big...

As for the LIBS += mylibrary.lib in the pro file, it's to make the linker find any links to the library. Nothing else...

cheers,
Leif

[Benne Gesserit]

(...)
As for the LIBS += mylibrary.lib in the pro file, it's to make the linker find any links to the library. Nothing else...
(...)

Ok ,lets say I have mylibrary.a and mylibrary.dll .Can the .pro file tell the difference between both files? I mean , after all ,wont it be -lmylibrary in the command? And then it looks for libmylibrary.a or mylibrary.dll? I dont know how to link the application with the library considering both files .
Well ,I have succesfully compiled the library the way you told me ,but got the same results : some items are not getting events .I loaded it with mapandload and loadlibrary ,so I think I will now give QLibrary a chance .
Thank you very much.
P.D.: And by the way , as it was normal to think , no matter if the dll "includes" .h files of the items (that means the .h has some funtion implementation).

[luf]

Other question. The object that doesn't get the event? What kind of object is it, and what kind of event is it that the object doesn't get?

cheers,
leif

[Benne Gesserit]

The object that doesnt get the event ....well ,I wont simplify it just in case it s important .
I have an abstract class (lets call it A) that inherits QGraphicsItem , then 2 clases (non abstract) that virtually inherit A (B,C) ,and then a class that inherits B and C (D) . (None is Q_OBJECT) .
In my application , I use only pointers to tha abstract base class.
The other items : one inherits QGraphicsTextItem (inherits QObject) ,and the other is a QGraphicsLineItem (doesnt inherit QObject) .

I realy dont know why it doesnt work
Thanks again.

[luf]

And the event it doesn't recieve?

Have you tried adding the Q_OBJECT macro to the classes to see what happens? It might be that since you don't have the macro, some events sent through signals/slots are not reciveved? I'm unsure about this...

[Benne Gesserit]

And the event it doesn't recieve?

Have you tried adding the Q_OBJECT macro to the classes to see what happens? It might be that since you don't have the macro, some events sent through signals/slots are not reciveved? I'm unsure about this...

Sorry ,I forgot that .They dont seem to recieve any event. If I click them,nothing happens , I had rubber band drag (or however it s called) and it doesnt work now .It s just like if the item wasnt there .
And about Q_OBJECT....maybe I try it if I have some time ,but I dont like that solution ,why should a graphics view item that was working perfectly have to inherit QObject and add that macro in order to be able to work in a DLL ? Maybe there is a reason ,I dont know ,but I wouldnt like that handicap.
Thanks , hopefuly I solve this......soon ,but I m a little bit faithless.

[Benne Gesserit]

-_- ,I think I have found the problem or at least a fix.I had a constructor without parameters like this:
Node()
{
}

Tha should implicitly call QGrapchicsItem() , what actualy is QGraphicsItem ( QGraphicsItem * parent = 0 ) .I had another constructor :
Node (...... ,QGraphicsScene * scene =0 ,QGraphicsItem * parent=0)
that called QGraphicsItem(parent) ,but parent was always null .So ,if I use the default contructor ,the events dont work ,if I use the other ,they do .It doesnt make any sense to me .I ll try to explicitly call the default base class constructors to see if it works that way ,otherwise,I ll just use the constructors with parameters .
Anyone knows why this happens?

[luf]

Hi

What happens is that when the item doesn't have a parent, it won't recieve events unless it has focus. (e.g. clicked on, selected or programatticly has focus)

When programming with Qt it's a good practice to have a parent for all objects, so that objects are deleted if the parent is deleted...

Leif

[Benne Gesserit]

Uhm.....So the thing was the items werer not getting focus....But other parentless items worked fine .
Thanks for the tips.