Animate a Modal Dialog

The AnimateWindow() function provides special effects (roll, slide, collapse, expand, and alpha-blended fade) for showing and hiding windows. It is an alternative to the ShowWindow() function. However, in the case of a modal dialog, ShowWindow() is not call directly by the user, but by the framework, through the DoModal() method. This article shows how to fix this problem for modal dialogs.

If you run step by step into a DoModal() call, you will notice the following code:

TRY
{
   // create modeless dialog
   AfxHookWindowCreate(this);
   if (CreateDlgIndirect(lpDialogTemplate,
      CWnd::FromHandle(hWndParent), hInst))
   {
      if (m_nFlags & WF_CONTINUEMODAL)
      {
         // enter modal loop
         DWORD dwFlags = MLF_SHOWONIDLE;
         if (GetStyle() & DS_NOIDLEMSG)
            dwFlags |= MLF_NOIDLEMSG;
         VERIFY(RunModalLoop(dwFlags) == m_nModalResult);
      }
         // hide the window before enabling the parent, etc.
      if (m_hWnd != NULL)
      {
         SetWindowPos(NULL, 0, 0, 0, 0,
            SWP_HIDEWINDOW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOACTIVATE|
            SWP_NOZORDER);
      }
   }
}
CATCH_ALL(e)
{
   DELETE_EXCEPTION(e);
   m_nModalResult = -1;
}
END_CATCH_ALL

RunModalLoop() is the method where the message loop is implemented, and where the actual calls to ShowWindow() are located. Unfortunately, this method is not virtual, so you cannot override it, but you can hide it by creating a function with the same name in a derived of CDialog and overriding DoModal(). The code in DoModal() does not require any change, but it must be located in the derived class of CDialog, so that the new version of RunModalLoop() could be called.

I have derived from CDialog a class called CAnimDialog that has two constructors, matching over the constructors of CDialog, but with additional parameters to specify the effects and time to run them for the two possible cases: showing and hiding the window.

explicit CAnimDialog(LPCTSTR lpszTemplateName, CWnd* pParent = NULL,
   DWORD milisecsshow = 200, DWORD stylesshow = AW_SLIDE|AW_BLEND,
   DWORD milisecshide = 200, DWORD styleshide = AW_SLIDE|AW_BLEND);
explicit CAnimDialog(UINT nIDTemplate, CWnd* pParent = NULL,
   DWORD milisecsshow = 200, DWORD stylesshow = AW_SLIDE|AW_BLEND,
   DWORD milisecshide = 200, DWORD styleshide = AW_SLIDE|AW_BLEND);

The code of DoModal() is copied/pasted from CDialog's implementation. Same is RunModalLoop() with two exceptions: the calls to ShowWindow() that were replaced with:

m_dwStylesShow &= ~AW_HIDE;
AnimateWindow(m_dwMilisecondsShow, AW_ACTIVATE|m_dwStylesShow);

Before calling AnimateWindow() with the specified styles, it's better to make sure AW_HIDE was not set (by mistake). Here is the complete code of RunModalLoop():

int CAnimDialog::RunModalLoop(DWORD dwFlags)
{
   ASSERT(::IsWindow(m_hWnd));            // window must be created
   ASSERT(!(m_nFlags & WF_MODALLOOP));    // window must not already
                                          // be in modal state

   // for tracking the idle time state
   BOOL bIdle = TRUE;
   LONG lIdleCount = 0;
   BOOL bShowIdle = (dwFlags & MLF_SHOWONIDLE) && !(GetStyle()
      & WS_VISIBLE);
   HWND hWndParent = ::GetParent(m_hWnd);
   m_nFlags |= (WF_MODALLOOP|WF_CONTINUEMODAL);
   MSG *pMsg = AfxGetCurrentMessage();

   // acquire and dispatch messages until the modal state is done
   for (;;)
   {
      ASSERT(ContinueModal());

      // phase 1: check to see whether we can do idle work
      while (bIdle &&
         !::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE))
      {
         ASSERT(ContinueModal());

         // show the dialog when the message queue goes idle
         if (bShowIdle)
         {
            m_dwStylesShow &= ~AW_HIDE;
            AnimateWindow(m_dwMilisecondsShow,
                          AW_ACTIVATE|m_dwStylesShow);
            UpdateWindow();
            bShowIdle = FALSE;
         }

         // call OnIdle while in bIdle state
         if (!(dwFlags & MLF_NOIDLEMSG) && hWndParent
             != NULL && lIdleCount == 0)
         {
            // send WM_ENTERIDLE to the parent
            ::SendMessage(hWndParent, WM_ENTERIDLE, MSGF_DIALOGBOX,
                          (LPARAM)m_hWnd);
         }
         if ((dwFlags & MLF_NOKICKIDLE) ||
            !SendMessage(WM_KICKIDLE, MSGF_DIALOGBOX, lIdleCount++))
         {
            // stop idle processing next time
            bIdle = FALSE;
         }
      }

      // phase 2: pump messages while available
      do
      {
         ASSERT(ContinueModal());

         // pump message, but quit on WM_QUIT
         if (!AfxPumpMessage())
         {
            AfxPostQuitMessage(0);
            return -1;
         }

         // show the window when certain special messages rec'd
         if (bShowIdle &&
            (pMsg->message == 0x118 || pMsg->message == WM_SYSKEYDOWN))
         {
            m_dwStylesShow &= ~AW_HIDE;
            AnimateWindow(m_dwMilisecondsShow,
                          AW_ACTIVATE|m_dwStylesShow);
            UpdateWindow();
            bShowIdle = FALSE;
         }

         if (!ContinueModal())
            goto ExitModal;

         // reset "no idle" state after pumping "normal" message
         if (AfxIsIdleMessage(pMsg))
         {
            bIdle = TRUE;
            lIdleCount = 0;
         }

      } while (::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE));
   }

ExitModal:
   m_nFlags &= ~(WF_MODALLOOP|WF_CONTINUEMODAL);
   return m_nModalResult;
}

This part is responsible for displaying animation when the window is shown. To handle the window hiding, three methods must be overridden:

void CAnimDialog::OnClose()
{
   m_dwStylesHide &= ~AW_ACTIVATE;
   AnimateWindow(m_dwMilisecondsHide, AW_HIDE|m_dwStylesHide);

   CDialog::OnClose();
}

void CAnimDialog::OnOK()
{
   m_dwStylesHide &= ~AW_ACTIVATE;
   AnimateWindow(m_dwMilisecondsHide, AW_HIDE|m_dwStylesHide);

   CDialog::OnOK();
}

void CAnimDialog::OnCancel()
{
   m_dwStylesHide &= ~AW_ACTIVATE;
   AnimateWindow(m_dwMilisecondsHide, AW_HIDE|m_dwStylesHide);

   CDialog::OnCancel();
}

In this case, before calling AnimateWindow() I make sure that AW_ACTIVATE style is not specified because you want the window hidden, not shown.

It's very easy to use the CAnimDialog class: If you have a class derived from CDialog, just include the "AnimDialog.h" header in your class header and replace every occurrence of CDialog with CAnimDialog in your class.

In my demo application, CConcreteAnimDialog is a dialog derived from CAnimDialog. Displaying it as a modal dialog with a sliding and blending effect and hiding it rolling from the bottom up is as simple as this:

CConcreteAnimDialog dlg(200, AW_SLIDE|AW_BLEND,
                        200, AW_SLIDE|AW_VER_NEGATIVE);

dlg.DoModal();
Note: Make sure you read the documentation of AnimateWindow() carefully from MSDN before using the function. Not all combinations of styles are possible.


About the Author

Marius Bancila

Marius Bancila is a Microsoft MVP for VC++. He works as a software developer for a Norwegian-based company. He is mainly focused on building desktop applications with MFC and VC#. He keeps a blog at www.mariusbancila.ro/blog, focused on Windows programming. He is the co-founder of codexpert.ro, a community for Romanian C++/VC++ programmers.

Downloads

Comments

  • Thank you!

    Posted by vlongsoft on 10/04/2006 08:14pm

    It is really a good job.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: October 29, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Are you interested in building a cognitive application using the power of IBM Watson? Need a platform that provides speed and ease for rapidly deploying this application? Join Chris Madison, Watson Solution Architect, as he walks through the process of building a Watson powered application on IBM Bluemix. Chris will talk about the new Watson Services just released on IBM bluemix, but more importantly he will do a step by step cognitive …

  • Live Event Date: November 20, 2014 @ 2:00 p.m. ET / 11:00 a.m. PT Are you wanting to target two or more platforms such as iOS, Android, and/or Windows? You are not alone. 90% of enterprises today are targeting two or more platforms. Attend this eSeminar to discover how mobile app developers can rely on one IDE to create applications across platforms and approaches (web, native, and/or hybrid), saving time, money, and effort and introducing apps to market faster. You'll learn the trade-offs for gaining long …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds