FS2004 module development / MFC dialog

[arkos]

Hello all,

I currently have an issue with a module development for FS2004.
I have added a new menu to main FS menubar for the module and one the item opens a windows DialogBox with DoModal().

The problem is that the Dialog is not always visible.
Sometimes it works fine, sometimes I have to switch to windows and go back to be able to see the dialog.

Here is the kind of hack (ValidateRect) I am trying to use but it does not work always:

case ID_CONNECT_MENUITEM:
showConnect=true;
....

case WM_PAINT:
if(showConnect)
{
CDialogConnect dlgConnect;
dlgConnect.DoModal();
showConnect=false;
}
RECT rectFSwnd;
GetWindowRect(hwnd, &rectFSwnd);
ValidateRect(hwnd, &rectFSwnd);
return true;

...

Does not anyone has any idea on this?
I wonder how the developers of FS Recorder and FSPassenger managed to solve this problem.

Thanks a lot,

Francois.

 

[ziporama]

Step 1: must run in the same UI thread as FS - this is the same thread that calls your gauge or your module.

Step 2: look into WS_POPUP as your window style

Step 3: parent your window to 'FS98MAIN'.

There are some minor tips and tricks in there, but the above should save you the months it took me to figure this out.

It would be wonderful if ACES had an API exposed to the windowing parts of FS9/FSX. No such luck thus far, so it's all hacks.

DirectX (the main FS window content) does not care a bit about WM_PAINT, NC_PAINT or any of the standard win32 messages. It only cares about flipping buffers - and that code is not exposed nor available for hooks. It doesn't look possible at this time to know when you need to redraw, that is a function of the UI layer and deep inside the FS rendering pipeline. The problem is, the windows UI layer doesn't tell you because it doesn't know what the main FS window is doing at all, and FS doesn't know about your dialog, therefore, doesn't handle it. What typically happens is your window gets rendered exactly once, but the background is refreshed, the windows UI layer doesn't know it, therefore your window never gets the message to redraw itself. Of course, you can force it to redraw manually, but two things happen then - terrible performance, and a lot of flicker. FS' own windows knows about the main DX rendering thread, and renders properly, but is no way to chain into that I have found without crashing FS. Some have hacked directly into the DX Dlls at low levels and intercepted these calls to trap the buffer flips - that is very, very difficult to do, but possible. The good news is that it's not needed. The bad news is that your code must determine what FS is doing because the normal windowing UI has no clue.

The situation is a bit different if you don't want to render DX output below your window. This is why many FS dialogs blank the background and pause the sim to avoid having to deal with painting issues, and they are modal, not modeless. Examples are the FS message boxes, the map dialog box, and FSUIPC.

Modeless is possible, as demonstrated with FSNavigator and others. The best tool in your arsenal is Spy++. Use it wisely and good luck!

Etienne

 

[arkos]

Hi Etienne,

Thanks a lot for all these explanation.

I have already done the three steps you mentionned.
Regarding your explanation, what do you mean by:

your code must determine what FS is doing because the normal windowing UI has no clue.

Are there any FS messages or process/GUI states that I should catch ?

This is why many FS dialogs blank the background and pause the sim to avoid having to deal with painting issues, and they are modal

How can I do it? I do not really need to have the FS Direct X buffer below my dialog.

Thanks a lot for you help.

Francois.

 

[ziporama]

Salut Francois!

I'll try to answer both questions: there is no simple way to know what FS is doing. I'm mostly now familiar with FSX and SimConnect (I have used FSUIPC to interact with FS9 in my pushback gauge but not from a UI perspective - and my poor brain remembers little).

On 1)I'm not aware of any particular messages sent specific to FS, but you can certainly use the windows API to see what FS windows are displayed (or not), and query the simulator's state, primarily, whether a flight is loaded and if the simulator is paused or not, or in dialog mode (FSX). In FSX, I particularly look for the "Ready" event.

On 2), again, I have not done this in FS2004 - in FSX, you can pause the sim by sending it the pause event, and you also tell it to enter dialog mode (see SimConnect_SetSystemState).

I also surmise that you can subclass FS98MAIN and paint a dark background by sending an Invalidate() message, then in your own WM_PAINT handling, paint a black background. That should be fine because while the sim is paused, DX should not try to paint a new image on the visible surface.


Hope this helps,

Etienne