For best results in this case, you should use the same compiler as FTP. I'm going to guess that FTP uses something like Visual Studio 2008 rather than QtCreator (big companies don't like using free software)
Printable View
For best results in this case, you should use the same compiler as FTP. I'm going to guess that FTP uses something like Visual Studio 2008 rather than QtCreator (big companies don't like using free software)
yea I'm using Visual Studio 2008, How can I tell what's the FTP QT version?
Is it dynamically linked? (does it refuse to run if the DLLs are missing?)
Can you inject a dll into a statically linked app (which is probably packed or encrypted too) at all?
You can do it without altering the application code at all, if have something that easily identifies the 'target' application (such as the text for the window title or the process name) you can VirtualAllocEx and CreateRemoteThread, then your thread runs in the process space of the application and can do whatever it wishes.
Until you provide some code of yours (namely the header file for the class you wish to call a slot from) we're stuck so we might as well get a bit offtopic here.
Here are the files:
Attachment 5347
Attachment 5346
Attachment 5348
Attachment 5349
I'm injecting this DLL into the BasicLayout example (Comes with QT, run it to see where I'm going with this) , and do two connections:
1. Line1 with Line2
2. Line1 with mySlot function
I than change Line1 text, and see that Line2 also changes, and any change that I do to Line1 are reflected in Line2 too -> The connection is working!
And I did this connection from my DLL.
In mySlot function I change the Line3 text (We know that I'm able to do it)
so if the 2nd connection was successful we would have seen Line3 also change... but it doesn't... -> The connection didn't work!
I've created MyQWidgetMoc.cpp with moc.exe that comes with QT...
HELP HELP. :confused:
Thanks
So how do you know your slot was not called? And please don't reply that the text on lineEdit3 didn't change.
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.
The return value is TRUE for both connectionsQuote:
Check the return value of connect()
I can't use a debugger, because this code is an injected dll, and don't know how to use the qDebug()... (Sorry)Quote:
Use qDebug() or your debugger to see whether the slot is called.
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 triedand got 4!! the information is there! but not being called... :-(Code:
this->metaObject()->indexOfSlot("mySlot()")
I'm about to cry! anyone!? :crying:
So the connection is successfully made.
It doesn't change anything, you can still run the original application under the control of a debugger together with your dll.Quote:
I can't use a debugger, because this code is an injected dll,
So learn to use it.Quote:
and don't know how to use the qDebug()... (Sorry)
Maybe the respective signal is not emitted :)Quote:
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 triedand got 4!! the information is there! but not being called... :-(Code:
this->metaObject()->indexOfSlot("mySlot()")
I'm about to cry! anyone!? :crying:
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?
The caller is not having a problem, it is you who has a problem while trying to break into the application.
Maybe the signal is not emitted (I hate to repeat myself)?Quote:
maybe it can't find me in some slots table!?
It looks into the connection table for the object emitting the signal.Quote:
When a signal is fired, how does QT "know" where to call to?
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).
Post your solution (something loadable into VS or QtC) and we'll have a look at it.
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!