Module programming

[Delvos]

Dear Peter, i'm currently writing a Module (MS VC6, SP5 running under W2K SP4) for both FS2002 and FS2004. When the module is activated through menu or hotkey (Shift - F8), a dialog box appears: This box is closed by clicking either OK or Cancel Buttons. So far so good.

In FS2002 everything works fine. In FS2004 everything works when FS is running in windowd mode. When FS2004 runs in fullscreen mode i have the following phenomenon: activating the module via menu causes its normal work. Doing this by pressing the hotkey the dialog box opens but cannot be seen; it is somnehiw not being displayed, but - it is there and you can click its buttons which do their work. This happens most of the times activating by hotkey - sometimes it works.. Very strange..

Best regards and thx in advance,

Michael

Coded as follows:

//

// Dialog box

//

BOOL DoMdlDialogBox( VOID )

{

DialogBox( hInst,

MAKEINTRESOURCE( IDD_MDL_DIALOG ),

hFSimWindow,

(DLGPROC)DlgProc );

return( TRUE );

}

//

//

// FS Windows procedure (subclassed)

LRESULT CALLBACK FSimWindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

{

fShift = (BOOL)GetAsyncKeyState( VK_SHIFT );

fCtrl = (BOOL)GetAsyncKeyState( VK_CONTROL );

switch (uMsg)

{

case WM_KEYDOWN:

{

if( wParam == VK_F8 && fShift )

{

DoMdlDialogBox();

return( 0 );

}

break;

}

case WM_COMMAND:

{

if (LOWORD(wParam) == ID_MY_MENUITEM)

{

DoMdlDialogBox();

return( 0 );

}

break;

}

}

// Call the original window procedure to handle all other messages

return CallWindowProc(oldWndProc, hwnd, uMsg, wParam, lParam);

}

[Pete Dowson]

In FS2002 everything works fine. In FS2004 everything works when FS is running in windowd mode. When FS2004 runs in fullscreen mode i have the following phenomenon: activating the module via menu causes its normal work. Doing this by pressing the hotkey the dialog box opens but cannot be seen

Full screen display of windows over FS is very precarious in FS2004. When I asked Microsoft about this (I thought it was a bug) they said it was down to the way DirecX had changed, and nothing could be done excepting using the FS display system -- i.e. like a gauge.

I don't even know how you have managed to make your window display okay when activated by menu. I got flickering. The FSUIPC dialogue gets around that by preventing the FS window from re-painting -- i.e. it intercepts the WM_PAINT and validates the paint area without doing anything. You could try something like that.

There is a side effect -- if the user moves the FSUIPC window multiple copies of it will be left behind, because FS is prevented from repainting them.

Regards,

Pete

[pzand]

Realizing this is an old topic by now, but...

The "multiplayer chat window" in FS2004 seems to do things exactly right. (although it does seem to block WM_PAINT while it's being dragged)

Trying to obtain the same goal, I did something completely different. I created a module, but started a new thread that waits for FSUIPC to be available, then registers a menu item through FSUIPC's menu facility and spins waiting for the menu item to have been selected (sleeping and refreshing the menu item every so often). Once the menu item gets selected, it does the DoDialog...

Interestingly, since this new dialog is from a different thread, FS now gets a WM_APPACTIVATE(false) and promptly minimizes while in full screen. I guess this is the correct behavior for switching to an "external", non-directX app?

I guess my question is: how do you get to be in the same thread as the FS window? Who's WndProc do you take over? And why does the "chat" window work right? :roll:

Peter

[Pete Dowson]

The "multiplayer chat window" in FS2004 seems to do things exactly right. (although it does seem to block WM_PAINT while it's being dragged)

The FSUIPC options dialogue also blocks FS paint messages, as you can see when it is dragged!

Trying to obtain the same goal, I did something completely different. I created a module, but started a new thread that waits for FSUIPC to be available

If you want unregistered FSUIPC access take care to at least Open the FS interface in the main FS thread. If you don't it will not be able to identify your module when you call (wrong stack) and will fail the access check.

Interestingly, since this new dialog is from a different thread, FS now gets a WM_APPACTIVATE(false) and promptly minimizes while in full screen. I guess this is the correct behavior for switching to an "external", non-directX app?

I don't know why it minimisesthat's sounds strange.

I guess my question is: how do you get to be in the same thread as the FS window?

When your module is initialised and de-initialised by the two mandatory calls you get from FS, you ARE in that thread! You can use that to start threads, as you are apparently doing, or create (invisible) windows to receive messages, but of course you can also SetTimer to get later and regular entry to a TIMERPROC, and on one of those, if you need to, you can subclass the main FS window which is of course the Foreground one with Class "FS98MAIN".

Regards,

Pete

[pzand]

If you want unregistered FSUIPC access take care to at least Open the FS interface in the main FS thread. If you don't it will not be able to identify your module when you call (wrong stack) and will fail the access check.

I have obviously convinced everyone I know to go buy and register! But this is still good to know :)

When your module is initialised and de-initialised by the two mandatory calls you get from FS, you ARE in that thread!

DOH! I knew that... really... I did...

Thank you Pete!