PDA

View Full Version : signal/slot mechanism and shared library



mickael
18th November 2012, 18:07
Hi everyone,

It is the first time I play with shared libraries and I have an issue about the signals and the slots.
I have an interface ServiceServer that defines two functions :


void ServiceServer::emitInitReady(bool is_error, Client* client)
{
qDebug() << "emit init ready";
emit initReady(is_error, client);
qDebug() << "emited";
}

void ServiceServer::wrappedInit(bool is_error, Client* client)
{
qDebug() << "wrapped init";
if(is_error)
{
qDebug() << " error";
initError(client);
}
else
{
qDebug() << " ok";
init(client);
}
reset();
}

Please note that :


bool ok = connect(this, SIGNAL(initReady(bool, Client*)), this, SLOT(wrappedInit(bool, Client*)));

returns true.

For a "built with the application " implementation, it works and outputs :


init
emit init ready
wrapped init
ok
//some stuff
emited

but for an implementation that is a plugin : it does not work since it outputs that :


init
emit init ready
emited

So the slot was not called.

the plugin .pro file is :


TEMPLATE = lib
TARGET = Chat
DEPENDPATH += .
INCLUDEPATH += .

QT += network
QT += sql

CONFIG += qt debug dll

# Input
HEADERS += Chat.h \
../client/ServiceGlobal.h \
../client/ServiceClient.h \
../common/Service.h \
../client/ConfigEntry.h \
../common/WrapperHelper.h \
../common/Wrapper.h \
../common/Rights.h \
../common/WrapperManager.h \
../common/ServicesContainer.h \
../client/SingletonFactoryClient.h \
../client/WrapperManagerClient.h \
../client/Room0Client.h \
../common/Room0.h \
../server/ServiceServer.h \
../server/InWrapperServer.h \
../server/CircularBuffer.h

SOURCES += Chat.cpp \
../client/ServiceGlobal.cpp \
../client/ServiceClient.cpp \
../client/ConfigEntry.cpp \
../common/Wrapper.cpp \
../common/WrapperManager.cpp \
../client/SingletonFactoryClient.cpp \
../client/WrapperManagerClient.cpp \
../client/Room0Client.cpp \
../server/ServiceServer.cpp \
../server/InWrapperServer.cpp


I don't know if the problem has something to do with the shared library but this example make me think that yes.
Could someone explain me where am I wrong ? Maybe, it is about (un)exported symbols but I run linux and I think that those problems are windows specific.
Please ask me for more details if I am not clear enough.
Thanks

amleto
18th November 2012, 19:16
you don't give any information about how you make your plugin, or how you load the plugin into the main app. please read my sig - issues with your post being the complete + compilable parts.

mickael
19th November 2012, 16:16
Sorry, I thought it would be a classic problem. The easiest way to give a complete code is to give all the code, so there is the client side code, the server side code and a plugin : "Chat". The problem appears (at least) on the server side.
In order to test, you can type make in the root folder then run server_build/server then client_build/client. I use two terminals :


tar -xvf program.tar.gz
cd program
make
cd server_build
./server

in the second one, after the first step is finished (the server is running)


cd program/client_build
./client

It is important to be in a *_build folder to test it because relative paths are used.

The plugin files are in src/services.
The file src/common/Service.h defines which functions are exported
To see how the plugin was loaded, see src/server/ServicesFactoryServer.* and src/common/ServicesFactory.*
You can see the problem when executing in ServiceServer.cpp line 153, this function emits a signal and as shown in th first post the connected function below is not called (wrappedInit). It works for the built-in class that inherits ServiceServer : Room0Server but not for the plugin Chat. ServiceServer itself inherits from InWrapper that is defined at the end of src/common/Wrapper.h.

Thanks a lot for taking time to help me.

ChrisW67
20th November 2012, 04:18
Where is your connect() call made?

mickael
20th November 2012, 12:42
In the constructor of ServiceServer (server/ServiceServer.cpp line 20) which is an ancestor of the Chat plugin.

mickael
25th November 2012, 14:08
It seems to work if the methods called in the slot are not pure virtual.