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

[gilamran]

So how do you know your slot was not called? And please don't reply that the text on lineEdit3 didn't change.

sorry, but the text on lineEdit3 didn't change...
If the 2nd connection was working, the lineEdit3 should have changed to "mySlot CALLED, yey"...
What am I missing!?!?!?

[wysota]

sorry, but the text on lineEdit3 didn't change...
If the 2nd connection was working, the lineEdit3 should have changed to "mySlot CALLED, yey"...
What am I missing!?!?!?

Debugging your application by changing values of lineedits is not a very professional way of doing things. What if you change the value but the change isn't reflected on the widget? Or if something rewrites the old value?

1. Check the return value of connect()
2. Use qDebug() or your debugger to see whether the slot is called.

[gilamran]

Check the return value of connect()

The return value is TRUE for both connections

Use qDebug() or your debugger to see whether the slot is called.

I can't use a debugger, because this code is an injected dll, and don't know how to use the qDebug()... (Sorry)

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

[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