|
That would have been too easy... Doesn't help. :\
|
|
|
|
|
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.)?
|
|
|
|
|
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.)?
|
|
|
|
|
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.
|
|
|
|
|
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...
|
|
|
|
|
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. 
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
|
|
|
|
|
Make sure the dialog window has "Clip Children" set to "False" (Use the Resource Editor to verify)
|
|
|
|
|
That's also set to false.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
WM_ERASEBKGND isn't being used, so that doesn't help...
|
|
|
|
|
Hi,
Could anyone please advise which files in a VS2008 solution that I really don't need to back up as I have limited backup space?
So far, candidates for exclusion are: *.pch, *.obj, *.sbr, *.ncb.
How about *,pdb?
Any others - particularly large files.
Thanks
|
|
|
|
|
You don't need Debug and Release folders.
Other than that the only large file is .ncb for VS2008.
.pch and .pdb will be inside the Debug and Release folders.
.pdb contains symbols and is be used for debugging.
But this would only be needed if you're backing up the .exe as well.
If you're having the source and intend to backup the source as is without worrying about versions, then you can get rid of the Debug and Release folders.
|
|
|
|
|
«_Superman_» wrote: If you're having the source and intend to backup the source as is without worrying about versions, then you can get rid of the Debug and Release folders.
Why are versions important? You can create tags to take care of versions.
|
|
|
|
|
Are we talking about any version control system here?
|
|
|
|
|
Not sure what we're talking about actually... 
|
|
|
|
|
See my reply to this same question here[^].
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
