Hi there. I am writing a DirectX7IM animation package, and I was wandering if anybody else has experienced the same problems. My app consists of a main rendering surface, a tree control (for the scene hierarchy) and a rebar control for the menu and toolbars. The problem is, that when my mouse is not above the parent window, it appears to lock up. The same problem also occurs when resizing the rebar control. The only solution I have found to the problem is to disable all calls to both DrawIndexedPrimitive and Flip. A copy of my message loop is shown below.

        
int ProcessMessageLoop(HWND hWnd)
{
  MSG      msg;
  HACCEL   hAccel = LoadAccelerators(NULL, MAKEINTRESOURCE(IDR_ACCELERATOR));

  while(msg.message != WM_QUIT)
  {
     BOOL bGotMsg;

     if(lpDirect3D->OkToRender())
         bGotMsg = PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE);
     else
         bGotMsg = GetMessage(&msg, NULL, 0U, 0U);


     if(bGotMsg)
     {
        if(!TranslateAccelerator(NULL, hAccel, &msg))
	{
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        };
     }
     else
     {
         RenderScene();
     };
  };
  return msg.wParam;
};
        

If anybody has experienced a similar problem before, or if anyone has any suggestions, then your help would be greatly appreciated. Jon. Edited by - j0n3z on 7/27/00 2:30:58 PM Edited by - j0n3z on 7/27/00 2:31:46 PM

Whoa, hold on there, are you using MFC? If so how does your ProcessMessageLoop work with MFC (what is calling ProcessMessageLoop)?

To animate (assuming you are using a single thread of execution) you can try handeling the WM_TIMER message (in MFC use CWndDerivative::OnTimer). You can also try performing your animation during CWinApp::OnIdle.

Alternatively, in MFC you can use CWndThread to performe the rendering. You have to read the MSDN docs on CWndThread yourself, but create the thread in the suspended state at the start of your app. Then start the thread''s execution to play the animation. Now you can watch your animation and poke and prod your rebar at the same time. You can even drag and drop things on your tree durring an animation.

If your not using MFC then define a thread entry point

    DWORD WINAPI MyThreadEntryFn( DWORD ){     while( bNotEndOfAnimation )     {         pScene->Animate( FrameTimer );         pScene->Draw( pSurface );         pSurface->FlipOrBlt();     }     return 0;}    

and use the Win32API function CreateThread()

I think I see something else wrong. You don''t want to use GetMessage() here at all, you should only use PeekMessage().

Perhaps you already know that GetMessage() does not return unless there is a message in your app''s message queue. PeekMessage() however, always returns, message or not. GetMessage() yield''s your idle time to the system and lets your app cooperate with other app''s (when you have no messages, your app is suspended by the system and it doesn''t get a time slice). PeekMessage let''s you do idle time processing.

In my opinion, there is no point to writing an animation app that uses GetMessage(). PeekMessage() does everything you need, and you don''t need you share CPU cycles with other apps.

Try this

     PeekMessage( &msg, 0,0,0, PM_REMOVE );  while(msg.message != WM_QUIT) {     if(!TranslateAccelerator(NULL, hAccel, &msg))     {         TranslateMessage(&msg);         DispatchMessage(&msg);     };     while( !PeekMessage( &msg, 0,0,0, PM_REMOVE ) )     {          // Do Idle time processing          if( bAnimating )          {              pScene->Animate( FrameTimer );              pScene->Draw( pSurface );              pSurface->FlipOrBlt();          }     }         }    

Thanks for your quick response.

For your information, the program is written using Win32. I have tried a message loop similar to that in your second response with no luck. It was altered it to be the same as that contained in the DirectX SDK, as Microsoft ''should'' know what they are doing.

I have altered the code to run on a timer, as mentioned in your first reply, and that appears to have solved the problem. It could also be used to allow the user to target a specific frame rate.

Once again, thank you for your help.

Jon Allsop.
Swansea University, Wales.

Uh, maybe a long shot, but did you remember to call pDevice->BeginScene() and pDevice->EndScene()?

Another long shot, Are you flipping while you are in a window? Are you using a ReBar control while you are fullscreen?

Hmmm...Ok, I''ll ask, Why do you bother using a ReBar if you don''t use MFC?

Yep.

I''ve been sweating over this problem for some time now, and I''ve been through every line of code in microsoft''s framework and nvidia''s framework (although I''m not using them) looking for something I''ve missed.

The problem exists when the app is in windowed mode, and I''m using a rebar partly because I new how to implement one and secondly because they look flash!! I am considering removing it, although it wouldn''t solve the problem that the mouse locks up when it''s not over the window.

The WM_TIMER event does seem to be coping much better than the message loop.

Jon.

For five bucks I can sell you a flashy ToolBar thingy that sets the x86 instruction pointer to NULL!

Have you ever tried using ATL? I threw out the MS supplied framework and wrote one that inherits from CWindowImpl.