0

So I have an issue that I assume has been explored before but I can’t seem to find anything on it. I made a custom Tab Control class that is completely custom drawn and shows/hides CDialog object as the user clicks on different tabs. To do this I overloaded the paint method (I did not use the user drawn feature). Everything seems to work fine except for one issue, the problem I am having is that when the user selects one of the controls in the dialog that is currently being shown (i.e. a CEdit) and presses the enter key, the tabCtrl will receive a WMPAINT message which causes the body of the tabCtrl to be drawn over the current dialog. To get around this issue I modified the erase background method of the tabCtrl to show the current dialog which fixes the dialog from being painted over but I get a flicker in the control every time the enter key is presses or held because of the paint/show dialog combination happening. I was wondering if anyone has dealt with this issue before and had a fix or any ideas. I haven’t been able to come up with anything that works. Sorry for the lack of code, I don’t have permission from the owner to share it.

JBode
  • 23
  • 3

1 Answers1

0

double-buffering will help you perhaps. Please google it - there are many examples. Use this article as a starting point

cha
  • 10,301
  • 1
  • 18
  • 26
  • Thanks for the sudgestion but its not a double buffering issue. Double buffering addresses the flicker produced by lag in the paint algorithem which this has nothing to do with. The flicker is happening because of how the overlapping controls are being drawn. The tabctrl is receiving a wmpaint message every time the enter key is presses on one of its child controls which causes it to repaint and the repaint covers the visable dialog. – JBode Apr 24 '13 at 12:01
  • It looks like you have your tab control rectangle to be as big as the pages inside it. FYI, there is absolutely no reason for this. Tab controls in MFC not like those in other languages (like VB or C++Builder). They are just tab controls. This means that when their size should be just the size of the tabs and should not include the pages – cha Apr 25 '13 at 23:14
  • I do have the tab control taking up the entire area of the pages inside it. I never considered shrinking it. The tab control draws a border around the area it defines for pages, if Im thinking correctly, by shrinking it you loose that border? The tab control also has a method for finding the pageRect GetTabPageRect(), this function would be usless if the tab control doesnt include the page area... That is an interesting way to treat tabControls but it seems like it would work. What do you think about not filling the page area of the tabControl so that it is transparent? – JBode Apr 29 '13 at 13:27