Getting the handle of the window

[Luc4]

mmh... If I'm uderstanding correctly you mean that I should send a show signal using winId(). Unfortunately I cannot modify the C# application which sends to my application the ShowWindow and the SetForegroundWindow. I need somehow to catch through Qt when those functions are sent to my window. I supposed ShowWindow should raise a QEvent::Show event in my evet(QEvent* event) function, but I get nothing. No event is sent to that function. I placed a log in there. Maybe it arrives somewhere else?
Thanks for your time!

[wysota]

Ok, let's start from the beginning, because I think I misunderstood what you were doing. What is the ultimate effect you want to obtain? What is the role of the C# application in all this?

[Luc4]

Ok, the problem is that I have some windows open, the first W1 is this C# application, then, over that window there is a window W2, which is my window of Qt application I'm writing. Then, in this Qt application, I run another application as a QProcess, with a window W3 (this can be another Qt application or something else). The order of the windows is W1, W2 and W3, where W3 is the topmost.

It happens that, in response to some events, window W1, which is the one written in C# behind all the others, comes over all the others. Then, that window sends a signal of ShowWindow and SetForegroundWindow to my Qt process (which owns W2), which comes again over W1. I need to handle this situation to show the process I started (which I called W3). I want W3 to be visible again,

Unfortunately, I noticed that once W1 calls those two functions, my Qt window W2 comes correctly over, but I get no event. I cannot find a way to handle that situation so I can bring over W3 somehow. I opened this topic as I supposed no QEvent::Show was received as W2 was visible. So I tried to hide it so that a show event could be received. Unfortunately, I discovered that the C# application got a handle 0 when the window W2 was hidden.

The restriction is that I can't recompile the C# application unfortunately. I didn't write it.

Thanks for any advice and for your answers!

EDIT: I forgot to mention a strange behavior I noticed. When W1 calls those two functions and W2 comes over, I get that, clicking on the portion of the screen where W3 was (it is not visible now), makes W3 visible again, just like only a repaint was needed. Isn't this strange? Anyway, I don't think this is Qt related.

[wysota]

This is all a bit weird design, I have to admit A window instead of lowering itself is artificially raising another window so that it can raise yet another window? Hmm... If you can't change this design, at least design W2 and W3 applications in a better way - provide some IPC mechanism to communicate between them and try to find a way for the first application to change its behaviour to something more sane The problem you are experiencing seems to be with W1 and not W2 so there isn't much you can do in W2 to change that.

[squidge]

If this is a Windows application, then maybe a better solution would be that App2 sets its Parent window property to that of App1, and App3 sets its Parent window property to that of App2, then the Windows will behave as if they were all in the same app and you don't have to do any of this monitoring events and bringing other processes windows to the front (which may fail on Windows7 without UAC compliance)

[Luc4]

This is all a bit weird design, I have to admit A window instead of lowering itself is artificially raising another window so that it can raise yet another window? Hmm... If you can't change this design, at least design W2 and W3 applications in a better way - provide some IPC mechanism to communicate between them and try to find a way for the first application to change its behaviour to something more sane The problem you are experiencing seems to be with W1 and not W2 so there isn't much you can do in W2 to change that.

I completely agree with you. This is not a good architecture, but I cannot change W1. I can only work on W2 and W3, so I'm trying to find any way to understand when those two functions are called to bring up W2, without success...
I thought I could work with focusIn events. When ShowWindow and SetForegroundWindow are called, W2 comes over, and I suppose some focusIn events will arrive. Unfortunately I cannot predict to which widget they'll arrive, right?

If this is a Windows application, then maybe a better solution would be that App2 sets its Parent window property to that of App1, and App3 sets its Parent window property to that of App2, then the Windows will behave as if they were all in the same app and you don't have to do any of this monitoring events and bringing other processes windows to the front (which may fail on Windows7 without UAC compliance)

The problem is that W1 is C#, W2 is Qt and W3 can be whatever. I cannot change W1, so it is calling ShowWindow and SetForegroundWindow to W2. This means that anything I can do, I suppose, cannot change the fact that W2 is overlapping W3 This is quite a mess, I know

Many thanks for your help guys!