Disappearing list controls
-
I have a dialog based application. The main dialog contains a tab control and several child dialogs, one per tab on the tab control. (The child dialogs are children of the main dialog, not of the tab control.) When a tab is selected, I hide the currently visible child dialog, move the child dialog associated with the newly selected tab so that it immediately follows the tab control in the Z-order, and make the newly selected child dialog visible. This all seems to work fine, except sometimes list controls in the child dialogs disappear. I say they disappear, because they do get drawn, but are immediately erased. If I start clicking on portions of the list control, pieces of it will be drawn. For example, if I click on an item, the item will be drawn. If I click on a scroll bar, the scroll bar will get drawn. Any ideas? -------- There are 10 types of people in this world. Those who know binary and those who don't.
-
I have a dialog based application. The main dialog contains a tab control and several child dialogs, one per tab on the tab control. (The child dialogs are children of the main dialog, not of the tab control.) When a tab is selected, I hide the currently visible child dialog, move the child dialog associated with the newly selected tab so that it immediately follows the tab control in the Z-order, and make the newly selected child dialog visible. This all seems to work fine, except sometimes list controls in the child dialogs disappear. I say they disappear, because they do get drawn, but are immediately erased. If I start clicking on portions of the list control, pieces of it will be drawn. For example, if I click on an item, the item will be drawn. If I click on a scroll bar, the scroll bar will get drawn. Any ideas? -------- There are 10 types of people in this world. Those who know binary and those who don't.
I had that problem too: Back then I've figured out that the reason for that behaviour was screwed up message pump: WM_PAINT from dialog becoming visible was getting processed before WM_ERASEBACKGROUND of hidden one is getting processed -- both containing same screen device context. The only solution I came up with back then was: instead of playing with Z-order and visibility -- I was just moving window that becomes "invisible" somewhere to Hawaii without changing visibility, while moving "visible" one to the right position. Another side effect as I recall right now was: if you use IE WebBrowser window as your property window and change it visibility to not-visible -- it's getting destroyed -- therefore moving technique in my case was the only appropriate solution... Regards "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
-
I had that problem too: Back then I've figured out that the reason for that behaviour was screwed up message pump: WM_PAINT from dialog becoming visible was getting processed before WM_ERASEBACKGROUND of hidden one is getting processed -- both containing same screen device context. The only solution I came up with back then was: instead of playing with Z-order and visibility -- I was just moving window that becomes "invisible" somewhere to Hawaii without changing visibility, while moving "visible" one to the right position. Another side effect as I recall right now was: if you use IE WebBrowser window as your property window and change it visibility to not-visible -- it's getting destroyed -- therefore moving technique in my case was the only appropriate solution... Regards "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
Thanks for the response. I actually found the apparent "what was causing this", but I still don't understand the "why". I had a call to SetFocus that was setting the focus to the list control (before it would have been painted). Removing this SetFocus call appears to have solved the problem. I had used Spy++ to look at the WM_PAINT and WM_ERASEBKGND messages. In agreement with your posting, the order of messages didn't make much sense and would fairly clearly cause the problem I experienced. If anyone has any insight on the "why" of this problem, curiosity is killing this cat. -------- There are 10 types of people in this world. Those who know binary and those who don't.
-
Thanks for the response. I actually found the apparent "what was causing this", but I still don't understand the "why". I had a call to SetFocus that was setting the focus to the list control (before it would have been painted). Removing this SetFocus call appears to have solved the problem. I had used Spy++ to look at the WM_PAINT and WM_ERASEBKGND messages. In agreement with your posting, the order of messages didn't make much sense and would fairly clearly cause the problem I experienced. If anyone has any insight on the "why" of this problem, curiosity is killing this cat. -------- There are 10 types of people in this world. Those who know binary and those who don't.
Where was
SetFocus()being called from?
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
-
Where was
SetFocus()being called from?
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
It was being called after I was done adjusting the visibility and Z-order of the child dialogs but before the message pump was allowed to run. I'm pretty sure it was the last thing to happen before returning to the message pump. -------- There are 10 types of people in this world. Those who know binary and those who don't.