none
MFC Multi-UI-Threaded Application Hangs under Vista but not Classic Windows theme

    Question

  • Hi, I have a MFC multi-ui-threaded application that hangs under Vista theme but not under Classic Windows theme.

    My application is a MDI variant  I have a Main window that contains multiple child windows.  However, the parent window and each child window run in their own ui-thread, CWndApp.  Sometimes all my windows loads nicely.  Sometimes, they don't.

    Please give me some ideas on what I should look at to get all the child windows to load correctly.

    Thursday, November 16, 2006 8:50 PM

Answers

  • When you say the Vista theme, do you mean Aero (glass)? That "theme" also enables the DWM. The classic theme does not use DWM, so you lose any differences in behavior that the DWM brings when you use this theme.

    Are you performing all of your rendering in response to WM_PAINT messages? There are some differences in behavior with the DWM when you draw at a time that is not in response to this message. Since you are getting unusual behavior with timing, this may be where the issue lies...?

    Friday, November 17, 2006 6:14 PM

All replies

  • Hello antigone,

    Have you tried running your appliation elevated to see if you get the same results? I would also try an XP SP2 compatibility shim as well as disabling desktop composition. Do you do any custom drawing in your application? Check out the Vista Application Compatibility Cookbook at http://msdn.microsoft.com/windowsvista/letter/default.aspx?pull=/library/en-us/dnlong/html/AppComp.asp to see if there are any components in your application that might have compatibility issues. Also is this a Win32 or .NET application?

    Thanks!

    Matthew Braun

    Thursday, November 16, 2006 9:37 PM
  • Thank you, Matthew, for taking the time to reply my post.  This is pretty neat.

    My application was developed under VC6 MFC.  It is definitely Win32.  I do have some controls where I do custom drawings such as text updates, dialog resizing, controls rearrangement.  But nothing fancy.

    I learned that WM_PAINT under Vista is redirected offscreen, and then, rendered onscreen when Vista deems it's the right time.  Since my application works under Classic Windows theme and not under Vista theme, is there a difference in how Vista paints windows on the desktop between Classic and Vista themes?  In other words, does the Desktop Window Manager intercept window paints for Vista theme but not for Classic theme?

    I ran my application in XP SP2 compatibility mode.  It still acts up.  I will try to run it in elevated?  I don't really know what this means.  Do I elevated my application to a higher privilege?  I ran my application under an administrator account.  I read the Vista Application Compatibility Cookbook, and I was tipped off about the Vista composition layer.  But I don't know if there's anything pointed that would pertain to me.  I will try the Application Compatibility Kit.  

    My application does sometimes run fine under Vista theme.  I think it's somehow related to timing.  I fear the Desktop Window Manager intercession is somehow deadlock with the windows in my application.  All my windows, parent and children, run on their own ui-thread.  The child windows are all contained in the parent window.  So, only the parent window is a top-level window.

    Friday, November 17, 2006 4:51 PM
  • When you say the Vista theme, do you mean Aero (glass)? That "theme" also enables the DWM. The classic theme does not use DWM, so you lose any differences in behavior that the DWM brings when you use this theme.

    Are you performing all of your rendering in response to WM_PAINT messages? There are some differences in behavior with the DWM when you draw at a time that is not in response to this message. Since you are getting unusual behavior with timing, this may be where the issue lies...?

    Friday, November 17, 2006 6:14 PM
  • My multi-ui-threaded MFC application runs fine under Windows Classic theme but not Windows Vista theme.

    I am switching between the themes from Appearance and Personalization\Themes\Theme Settings

    I do not know if the Windows Vista theme is the Aero(glass). 

    I also disable DWM while still using Windows Vista theme.  I also ran in XP Compatibility mode.  In both instances, my app hung. 

    No, I do not render in response to WM_PAINT.  I do updates on say a list control on a timer with GDI device context and invalidation calls WM_PAINT. 

    By wondering if it's timing related, I meant timing in reference to the interweaving of the ui-threads as my child windows are being shown in the parent client area.  When my app starts, it spawns ui-threads.  Each ui-thread creates and shows a child window.  So, multiple child windows are being displayed simultaneously at the start of my app.

    Thanks you for your help.

    Friday, November 17, 2006 10:23 PM
  • Is this still an issue? If you know the solution can you post it.

    Otherwise I will continue to research this. Some questions I have are:

    You don't do any special painting with the themes, but is there some method that the your application hangs on? Have you taken a memory dump or used windbg to know what is getting executed before the "hang"

     

    Monday, December 11, 2006 10:07 PM
  • Hi, Oliver!

    I'm glad to tell you the hung up was due to SetWindowPos on WM_ACTIVATETOPLEVEL.  I would really like to understand how window drawing is different between Vista and Classic Windows.  I learned that Vista has a composition engine that draws offscreen before updating onscreen. A window draws directly to the desktop under Classic Windows. 

    Because child windows run in their own UI threads, it has been observed that the parent and/or children can have active window states.  I'm thinking that there was a deadlock between the mainframe and children on drawing their windows under Vista.    The mainframe tries to SetWindowPos, consequently drawing the whole application window, while one or more child windows are trying also to draw themselves in the mainframe. 

    Tuesday, December 19, 2006 3:57 PM