DLL Injection with slots... ?!?!?

[wysota]

The return value is TRUE for both connections

So the connection is successfully made.

I can't use a debugger, because this code is an injected dll,

It doesn't change anything, you can still run the original application under the control of a debugger together with your dll.

and don't know how to use the qDebug()... (Sorry)

So learn to use it.

But just to make sure, inside mySlot function I disconnected the first connection, but it wasn't getting disconnected... man! this function is NOT being called!

I've also tried

this->metaObject()->indexOfSlot("mySlot()")

this->metaObject()->indexOfSlot("mySlot()")

To copy to clipboard, switch view to plain text mode 

and got 4!! the information is there! but not being called... :-(

I'm about to cry! anyone!?

Maybe the respective signal is not emitted

[gilamran]

for a better test I did this:
I've opened the BasicLayout project in Visual Studio, added my MyQWidget.cpp/h and moc and connected the fields there...
Inside mySlot function I did a qDebug out, and saw it!!! when I do the connection from inside the app it's working! meaning -> MyQWidget is good for receiving signals! the caller is having a problem! maybe it can't find me in some slots table!?

When a signal is fired, how does QT "know" where to call to?

[wysota]

the caller is having a problem!

The caller is not having a problem, it is you who has a problem while trying to break into the application.

maybe it can't find me in some slots table!?

Maybe the signal is not emitted (I hate to repeat myself)?

When a signal is fired, how does QT "know" where to call to?

It looks into the connection table for the object emitting the signal.

[gilamran]

It looks into the connection table for the object emitting the signal.

Where can I see this code? I want to debug it.

[wysota]

QMetaObject class, as far as I remember. If not, then it's in QObject. But trust me, you won't be able to debug it, it's complicated. If your connect() statement returned true, it means the connection is placed in the connection table. As long as both interested objects are alive, it will stay there (if you don't disconnect the signal manually).

[squidge]

Post your solution (something loadable into VS or QtC) and we'll have a look at it.

[gilamran]

The solution is "Qt::DirectConnection"

I did some deep debugging and found that the code is checking if the caller and the sender are from the same thread... OR Qt::AutoConnection! so I did DirectConnection and it's working!!!!!!!!!!!!!!!!!

I want to thank all of you guys, for the time and effort! you are the best!

[wysota]

Hold on, there is something wrong here. Regardless of what the connection type is (be it AutoConnection or DirectConnection or QueuedConnection), the slot eventually gets called unless the target slot is in a thread that doesn't have an event loop running. So if your slot doesn't get called if you use AutoConnection then it means it runs within a thread without an event loop which in turn implies it is not the main application thread. And accessing widgets from the non-gui thread leads to a crash. I see some contradictions here:
1. since your test app doesn't use worker threads, auto and direct connections should be equivalent
2. your test app doesn't crash so you are not accessing widgets from a worker thread which in turn means the slot should work in the first place
2. if the application you are trying to break into uses threads and that's why the auto connect doesn't work (because your injection code works in the context of one of the worker threads), then accessing any component behind its back will/should likely lead to a crash.

To sum things up - either you are wrong now about direct connections or your solution will be crashing on you like hell soon.

[gilamran]

ok, ok... we have something here.
I'm comming for managed languages (Java) and I'm used to Garbdge collectors... (Be nice)

The new problem is that the slot is being called only one time.... I'm creating an object of MyQWidget when the DLL is being called, I'm calling the function that does the slot-signal connection, and I'm not releasing the object...
The DLL is still in the Main Application memory space, but MyQWidget is somehwere in memory!? maybe that was the reason that slot was not getting called...

I understand that I'm suppose to have some kind of events loop, that will keep MyQWidget alive, so my slot is available for SIGNALS. How Do I do that?

Am I right?
I guess that now you'll send me to read something (Please do)

Many thanks
Gil

[gilamran]

(Please read the previous post, first)

I'm trying now to prevent my MyQWidget from terminating (So it can be available for signals) I've changed it to inherit from QDialog (And not just QWidget or QObject)
When the DLL is running for the first time, I'm creating my "dialog" and calling a public function to do the signal connection, and than calling the "exec()" function of the dialog (To keep it alive)
BUT! the main UI is freezing, until I close my Dialog...

Do I have to create the dialog in a different thread? so the main UI will be able to actually send the signal...

Gil.

[wysota]

If the application is a Qt application (and it is) then there is already an event loop running and you shouldn't need to do anything more. Especially don't try handling anything related to widgets from another thread (in doubt read my previous post again). It doesn't matter if you inherit from QWidget or QDialog, the main event loop is already handling your widget. As for the memory thing, as long as you don't delete the object yourself and as long as its parent doesn't go out of scope, you'll object will remain alive.

[gilamran]

As far as I can see, I have two options:
1. use exec() -> leads to the main UI waiting for the dialog to close.
2. use show() -> The dialog opens, and closes very fast, no Idea why...

any ideas?

[wysota]

2. use show() -> The dialog opens, and closes very fast, no Idea why...

You are probably creating it on the stack and not on heap so it gets out of scope and gets deleted by the compiler.