Window over FS in full screen mode

[Daniel Delande]

My problem is not directly related to FSUIPC, however I found a number of posts related to it on this forum, but I could not find a post with the solution.

The issue is how can a module (triggered by a menu item of FS) display its own window over FS window when the latter is in full screen mode? It was easy with FS2002 and DirecX8, but, as stated in different posts, it's not easy with FS2004 and DirectX9.

Can someone who has found the solution explain it (or direct me to a site where it is explained)?

Daniel Delande (d147@tiscali.fr)

[Pete Dowson]

The issue is how can a module (triggered by a menu item of FS) display its own window over FS window when the latter is in full screen mode? It was easy with FS2002 and DirecX8, but, as stated in different posts, it's not easy with FS2004 and DirectX9.

Can someone who has found the solution explain it (or direct me to a site where it is explained)?

I'd like to know that too. Even to stop the FSUIPC options dialogue flashing in FS2004 full screen mode I have to intercpet the WM_PAINT messages to FS's Window and validate them without passing them on. Try moving the FSUIPC options window and you'll see one of the horrible results. I asked the FS team why this was and they just said "blame DirectX8, it's out of our control" (FS2004 is programmed to the DX8 API).

Regards,

Pete

[Daniel Delande]

Thank you for answering.

I already tried tricks such as using LockWindowUpdate() with FS's window handle or trapping the WM_PAINT messages. The best result I could get is that I could move around my window for a while (with the same 'horrible result' you get when you move FSUIPC's window), but randomly, the screen finally goes black (that is not the case with FSUIPC's window), and I can recover from that situation by depressing Alt+Enter so as to exit the full screen mode. So, I suspect that there is something else to do to prevent DirectX9 from covering all windows with that black screen.

Regards,

Daniel Delande

[Pete Dowson]

... randomly, the screen finally goes black (that is not the case with FSUIPC's window), and I can recover from that situation by depressing Alt+Enter so as to exit the full screen mode. So, I suspect that there is something else to do to prevent DirectX9 from covering all windows with that black screen.

Ah, the black screen. That is easy to get without programming. I really don't know what sort of mess DX8/9 is in, but black screens seem to be typical. I wish I knew the answers. If you do solve them, please let us know.

It is likely that the only difference between yours and FSUIPC's window is the fact that FSUIPC's is a modal dialog within FS, so most of the normal FS activities are frozen whilst it is active. I don't know that there's any way of accomplishing this from an external program.

Regards,

Pete

[Daniel Delande]

the only difference between yours and FSUIPC's window is the fact that FSUIPC's is a modal dialog within FS

Well, my window is supposed to be also a modal window within FS. It is created within FS (my application is a module, i.e. a dll loaded by FS) and seems modal as expected (FS hangs until my window is closed). The only non-modal visible effect is that damn black screen.

Regards,

Daniel Delande

[Pete Dowson]

the only difference between yours and FSUIPC's window is the fact that FSUIPC's is a modal dialog within FS

Well, my window is supposed to be also a modal window within FS. It is created within FS (my application is a module, i.e. a dll loaded by FS) and seems modal as expected (FS hangs until my window is closed). The only non-modal visible effect is that damn black screen.

Ah, well that's odd then. I can't imagine why yours makes the black screen and mine doesn't. Hmmm.

Pete

[Daniel Delande]

I noticed a difference between my window and yours, when FS is NOT in full screen mode:

- with mine, from time to time, FS redraws partially its window.

- with yours, FS never redraws its window.

I concluded from this that I had not hooked the WindowProc of the right window (the only hook installed was on the main FS window).

So I tested this:

- enumerate the child windows of the main window of FS, and hook the WindowProc of those whose class name is FS98CHILD (there are 8 of them).

- in the 8 new WindowProc's, just return 0, whatever is the incoming message.

- of course, restore the original WindowProc's when my window closes.

The result is that FS does not redraw its window(s) and that in full screen mode, the black screen problem is not there anymore.

This is brutal a method, I think I had better refine it a little.

Daniel Delande

[Pete Dowson]

I concluded from this that I had not hooked the WindowProc of the right window (the only hook installed was on the main FS window).

I am certainly only hooking the main (FS98MAIN) window for this. Maybe you weren't validating the Paint request?

This is brutal a method, I think I had better refine it a little.

Try only hooking the main window but validating the WM_PAINT, thus:

{ RECT rcl;

GetClientRect(hwnd, &rcl);

ValidateRect(hwnd, &rcl);

return 0;

}

Regards,

Pete

[Daniel Delande]

{ RECT rcl;

GetClientRect(hwnd, &rcl);

ValidateRect(hwnd, &rcl);

return 0;

}

This is the right thing that actually solves the problem! My poor code (only 'return 0;') was not sufficient.

:D Thanks a lot for your help, Pete.

Daniel Delande

[Pete Dowson]

This is the right thing that actually solves the problem! My poor code (only 'return 0;') was not sufficient.

Not only that, but it would slow things down too -- the WM_PAINT messages would keep repeating very frequently because the painting is not being done. Windows isn't happy until you've told it you've painted the area which it thinks needs it. That's what the Validate does -- tell it you've dealt with the area in question.

Regards,

Pete

[Daniel Delande]

Yes, that's what the Win32 API help page dedicated to ValidateRect reads, but unfortunatly the WM_PAINT help page has no direct link to the ValidateRect one. I am not familiar with this level of Windows API programming, so I really thank you again for sharing your experience.

Daniel Delande