Disappearing MFC controls [modified]
-
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
Make sure the dialog window has "Clip Children" set to "False" (Use the Resource Editor to verify)
-
Make sure the dialog window has "Clip Children" set to "False" (Use the Resource Editor to verify)
-
Check the tab order of the controls, especially if you have group controls ( which you do have). I don't remember if the group should be before or after the controls that are "inside" it.
Watched code never compiles.
-
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.
j_schultz wrote:
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.
Are you sure that is that true? It's been a long time since I've dealt with tooltips (in MFC), but I don't remember that restriction. I think the only side effect of having the group boxes be lower in the tab order than their content would be that they could right click on the group box to get "What's This" on whatever the next control in the tab order is. It would be interesting to see if that fixes the disappearing problem, even if it's not satisfactory. Have you tried programatically bringing the disappearing controls to the front by using SetWindowPos(HWND_TOP, etc.)?
-
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
Just for grins, remove the "group" controls.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
-
j_schultz wrote:
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.
Are you sure that is that true? It's been a long time since I've dealt with tooltips (in MFC), but I don't remember that restriction. I think the only side effect of having the group boxes be lower in the tab order than their content would be that they could right click on the group box to get "What's This" on whatever the next control in the tab order is. It would be interesting to see if that fixes the disappearing problem, even if it's not satisfactory. Have you tried programatically bringing the disappearing controls to the front by using SetWindowPos(HWND_TOP, etc.)?
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.
-
Just for grins, remove the "group" controls.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
-
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?
j_schultz wrote:
Are the no common code problems that could cause this?
Only if you've explicitly added such code.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
-
j_schultz wrote:
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.
Are you sure that is that true? It's been a long time since I've dealt with tooltips (in MFC), but I don't remember that restriction. I think the only side effect of having the group boxes be lower in the tab order than their content would be that they could right click on the group box to get "What's This" on whatever the next control in the tab order is. It would be interesting to see if that fixes the disappearing problem, even if it's not satisfactory. Have you tried programatically bringing the disappearing controls to the front by using SetWindowPos(HWND_TOP, etc.)?
David Kentley wrote:
Are you sure that is that true? It's been a long time since I've dealt with tooltips (in MFC), but I don't remember that restriction.
Yes, z-order can make or break tooltips.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
-
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
According to your description, seem the controls are overlapped. please use Spy++ to check the control rect to verify that these controls are overlapped. If this is the case, you just need to re-pos the overlapped controls.
-
David Kentley wrote:
Are you sure that is that true? It's been a long time since I've dealt with tooltips (in MFC), but I don't remember that restriction.
Yes, z-order can make or break tooltips.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
DavidCrow wrote:
Yes, z-order can make or break tooltips.
Yes, but I thought if a right click was pressed on a control, that control would be checked for a tooltip. If that didn't have one, it would look at the next one in the tab order, and so on, until it found a tooltip. So if I had a groupbox as the first in the tab order, then a static control, then an edit control that has a tooltip associated with it, I can right click on any of the three to get the tooltip. To bring it back to the original question, wouldn't re-ordering them in this way at least be a way to see if it fixes his disappearing controls. If he doesn't want the groupbox to ever have a tooltip associated with it, it needs to be the last in the tab order (which is why I guess he's doing that), but that messes with the z-order. That's why I had the SetWindowPos solution as well. This is one of those things that I spent years dealing with, and I thought I had a pretty good system for it, but it's been a long time since I've worried about it. I just realized I've been talking about context sensitive help and this has been about tooltips. :-O There are similar issues involved, though, involving tab ordering.
-
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.
-
Have you tried programatically bringing the disappearing controls to the front by using SetWindowPos(HWND_TOP, etc.)?
-
DavidCrow wrote:
Yes, z-order can make or break tooltips.
Yes, but I thought if a right click was pressed on a control, that control would be checked for a tooltip. If that didn't have one, it would look at the next one in the tab order, and so on, until it found a tooltip. So if I had a groupbox as the first in the tab order, then a static control, then an edit control that has a tooltip associated with it, I can right click on any of the three to get the tooltip. To bring it back to the original question, wouldn't re-ordering them in this way at least be a way to see if it fixes his disappearing controls. If he doesn't want the groupbox to ever have a tooltip associated with it, it needs to be the last in the tab order (which is why I guess he's doing that), but that messes with the z-order. That's why I had the SetWindowPos solution as well. This is one of those things that I spent years dealing with, and I thought I had a pretty good system for it, but it's been a long time since I've worried about it. I just realized I've been talking about context sensitive help and this has been about tooltips. :-O There are similar issues involved, though, involving tab ordering.
David Kentley wrote:
To bring it back to the original question, wouldn't re-ordering them in this way at least be a way to see if it fixes his disappearing controls.
No, because the group controls are no longer part of the problem. At this point, all controls are at the same "level." See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
-
Have you tried programatically bringing the disappearing controls to the front by using SetWindowPos(HWND_TOP, etc.)?
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 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
Are you handling the WM_ERASEBKGND message for the window to reduce flickering? If you are, try removing it temporarily to see whether it makes a difference.
If you vote me down, my score will only get lower
-
Are you handling the WM_ERASEBKGND message for the window to reduce flickering? If you are, try removing it temporarily to see whether it makes a difference.
If you vote me down, my score will only get lower
