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

[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.

[gilamran]

That was the problem!!
I've created my QDialog on the heap and now I'm getting all the signals!!! yey!
This might be obvious to some of you, but I come from Java (With garbage collector)

Two things left:
1. When I close the main UI, I can still see it in memory (Probably because it still have a slot in an object that wasn't release...)
So I need a way to know when the window is trying to close, or when the data of the model is being deleted... are there any events/signals that I can listen to and delete myself?

2. Still when I use the QDialog show(), it's openning and closing (very fast), and when I use the exec(), the main UI is stuck till I close it... any idea how to solve this?

Thanks
Gil

[wysota]

Show us how you create the dialog.

[gilamran]

#include <windows.h>
 
 
INT APIENTRY DllMain(HMODULE hDLL, DWORD Reason, LPVOID Reserved)
{
	MyQDialog *m_MyQDialog = new MyQDialog();
 
	switch(Reason)
    {
		case DLL_PROCESS_ATTACH:
			m_MyQDialog->connectQWidget();
			m_MyQDialog->show();
			break;
 
		case DLL_PROCESS_DETACH:
			break;
 
		case DLL_THREAD_ATTACH:
			break;
 
		case DLL_THREAD_DETACH:
			break;
    }
    return TRUE;
}

#include <windows.h>


INT APIENTRY DllMain(HMODULE hDLL, DWORD Reason, LPVOID Reserved)
{
	MyQDialog *m_MyQDialog = new MyQDialog();

	switch(Reason)
    {
		case DLL_PROCESS_ATTACH:
			m_MyQDialog->connectQWidget();
			m_MyQDialog->show();
			break;

		case DLL_PROCESS_DETACH:
			break;

		case DLL_THREAD_ATTACH:
			break;

		case DLL_THREAD_DETACH:
			break;
    }
    return TRUE;
}

To copy to clipboard, switch view to plain text mode 

[wysota]

This shouldn't cause your dialog to disappear.

[tbscope]

At which point in time does DLL_PROCESS_ATTACH happen?

If it happens when the dll gets loaded before the main event loop is running, you're too soon to create the dialog.

Note that the main event loop is the one you want to use to create your dialog.
Try installing a hook into the main application event function. Then, when the application started event happens, create your dialog.

[gilamran]

I'm injecting my DLL when the application is fully running.
I took the QApplication:instance(), than I checked the applicationFilePath and got the injected exe file path. I guess that this means that My Dialog will be part of the exe application...

It looks like it's going to be inevitable... I will have to debug QT :-(
What's keeping a QDialog alive?

[wysota]

What's keeping a QDialog alive?

Please define "alive".

[gilamran]

"alive" means that it's in an events loop.
I did some debugging and got an ASSERT that said: "widgets must be created in the GUI thread"...
now I know that you're going to kill me and tell me that you already told me that it's "accessing widgets from the non-gui thread leads to a crash"... ok well, I did get access to the widgets, and even got my external DLL slot to get called...
but now the thing is that I can't create a dialog from my DLL... is there a way to work around it? (I think that can manage without the dialog)

[wysota]

Thus far I have an impression that you are doing some random things and expect to find a combination of them that works. This is not a good approach. You should first analyze what the applicaiton you are attaching to is actually doing. Otherwise your code might be called from a completely arbitrary context and it will not be possible to control it. Use a debugger to see whether the application uses threads and find a context where it will be running the main thread and try attaching to that. Otherwise you'll end up in a situation that you are doing something from a worker thread that gets terminated at some point and you won't be able to continue. Maybe you should find a different way to achieve your goal? Is the application dynamically or statically linked?

[gilamran]

Ok, after some time I've got some progress...
but now I have another question: (Should I open a new thread?)
I investigate the main application UI structure by going to it's children and printing out the widget name, x, y, visible etc.
BUT I have some window (A VERY important one for me) that contains a a very complex UI, but it's not a child of any of the QWidgets... A large portion of the UI is missing...
I found a QWidget with no children... can it be that this is the complex UI that I'm missing? can it be that a complex UI is some kind of external EXE running inside the QWidget?

any ideas?

Thanks

[wysota]

It's rather a graphics view or a custom widget that paints all its contents by itself.

[gilamran]

great! it's a graphics view... didn't know they exist...

ok, now that I have the graphics view, how can I enum all the items that inherit from QGraphicsTextItem? and print out their text...
yea, I know it's a dumb question, but I have no C++ background.... and I didn't find a way to do it.

Thanks
Gil

[wysota]

You ask the scene for all items and then you iterate over them checking their type and so on.

[gilamran]

yea I know.... but my C++ background is 0.
can't get it to work...

foreach (QGraphicsItem *item, scene->items())
{
  QGraphicsTextItem *gti = qgraphicsitem_cast<QGraphicsTextItem *>(item);
  if (gti)
  {
    sendmsg("QGraphicsTextItem found");
  }
}

foreach (QGraphicsItem *item, scene->items())
{
  QGraphicsTextItem *gti = qgraphicsitem_cast<QGraphicsTextItem *>(item);
  if (gti)
  {
    sendmsg("QGraphicsTextItem found");
  }
}

To copy to clipboard, switch view to plain text mode