WM_ERASEBKGND isn't being used, so that doesn't help...

Sorry if it was not obvious from the screenshot, but both the dark grey area as well as the scroll bar are pixel garbage which is shown instead of the default background colour. The scrollbar that you can see in the screenset becomes visible after minimizing the MDI child window at exactly the same position where previously a "real" scrollbar was.

I'm having some problems with my rather old codebase in VS2010 again. I have a MDI program where the child windows have a tabbed layout; This worked nicely up to VS2008, but in VS2010 the background of the tab bar is broken, see here. Any idea what could be causing this? Note that the tab bar looks perfectly OK when using the Win2k theme in Win7, it only looks like this with Aero enabled. Somehow I think it could be related to the fact that the child windows are using a splitter pane with a top and a bottom pane, but the upper pane appears to be a CDialog - I have been told that this should actually not be possible at all, but somehow the previous developer of this app got it to work...

It should be simple to rewrite the implementation to work with normal memory chunks instead of real files - as the downloaded file should be in some kind of byte array, you can emulate the fseek / etc. calls by simply advancing a pointer in this array.

There is probably some C/C++ code that does this, but so far I have only seen an implementation in PHP. Maybe you could just translate this to C/C++.

I have kind of found a way to fix it now. I'm calling Invalidate() in the page activation code, and it seems to help. Interestingly, before doing so, the combobox that disappeared most didn't disappear anymore when I removed the code in the page activation code that was responsible for filling the combo box - which is weird, it just calls ResetContent and AddString...

I have tried using MFC's BringWindowToTop() on the combo boxes in OnInitDialog() and in the page activation code, but sadly that doesn't help, either.

That also didn't help. I think the problem is far more down in the code, not in the dialog resource. Are the no common code problems that could cause this?

Yes it is true. I have had issues with tooltips not appearing at all, and the solution was to change the tab order. And as said in another reply, removing the boxes alltogether does not fix the problem, either, so changing tab order will not fix it either as well.

To make tooltips on controls work, group boxes must have a higher tab value than their content. So all group boxes have a higher tab order in this case.

That's also set to false.

That would have been too easy... Doesn't help. :\

I have a project that seems to have quite some trouble with MFC. First off, the code base is quite old, the earliest GUI code is from around 1997. It's a MDI GUI with a splitter pane, and in the upper panel, some MFC controls disappear all the time since I switched from VS2003 to VS2008/VS2010. They do not disappear all the time, and it's not always the same controls that disappear. In the worst case, the window can look like this while it's supposed to look like this. Clicking the invisible controls makes the visible again. Do you have any idea what could be causing this? Edit: I should also add that "switching" to the tab using a shortcut when you already are on the tab makes the combo boxes visible, but without their border, just the white edit part of the combo box (the dropdown button is also missing).

modified on Tuesday, August 30, 2011 4:50 PM