Solved

CTabCtrl with Dialog Background problem

Posted on 2011-03-14
29
2,260 Views
Last Modified: 2013-11-20
Hi, I changed my code from CPorperty Sheet to use a CTabCtrl directly. But I have now the problem, that all dialogs I show inside the tab are grey and the tab background is white. How I can make the same background color to the CDialog I show inside the tab?
Ocrana
0
Comment
Question by:Ocrana
  • 8
  • 6
  • 5
  • +3
29 Comments
 
LVL 8

Accepted Solution

by:
SunnyDark earned 500 total points
ID: 35133099
You need to handle the WM_CTLCOLOR (Or in MFC onCtlColor) message in your dialog and return the system brush that correspondes to "window color", you can use GetSysColorBrush with COLOR_WINDOW to fetch the brush. Generally:

HBRUSH CMyDialog::OnCtlColor(CDC* pDC, CWND* pWnd, UINT nCtlColor)
{
if (nCtlColor == CTLCOLOR_DLG)
 return GetSysColorBrush(COLOR_WINDOW);
else
 return  CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
}

Open in new window

0
 
LVL 5

Expert Comment

by:JohnCz
ID: 35133409
Well, this is a good advice; however it may not work when different themes are applied.

Why did you switch from property sheet and property pages to dialogs and tab control?

If you did it to familiarize yourself with tab control, it may be justified. Any other reason?

You are losing a lot of functionality by dropping property sheet and opening a new can of worms if you are trying to use dialogs instead.
Property sheet gives you free resizing to fit all dialogs, handles switching between dialogs (pages) and more.
You will have to write a code to do many things that property sheet provides for free.
0
 

Author Comment

by:Ocrana
ID: 35133824
@SunnyDark:
sure, the dialog is changed but all controls are still grey.
0
 
LVL 8

Expert Comment

by:SunnyDark
ID: 35133838
then you need to handle other cases besides CTLCOLOR_DLG and return appropriate brush for each control...
0
 

Author Comment

by:Ocrana
ID: 35133845
@JohnCz
Its very simple: I do not have access to messages like page changes (SelChange). I do not like to send message acrros the whole software for a little settings page. This is in my eyes a bigger can of worms as to use dialogs inside a CTabCtrl.
Ocrana
0
 
LVL 5

Expert Comment

by:JohnCz
ID: 35134334
What selection change are you referring to? Tab control? Why would you need selection change notification?
I am not sure what you call bigger can of warms.
Property sheet notifies each page when tab selection changes by calling virtual members of the CPropertySheet OnSeteActive when page is activated and OnKillActive when page deactivates.
Property page class behaves the same way as dialog does; it also have additional functionality specific to so called tabbed dialog.
Are you using CPRopertySHeet and CPropertyPage classes?

>>This is in my eyes a bigger can of worms as to use dialogs inside a CTabCtrl.
>>sure, the dialog is changed but all controls are still grey.


The above is just a beginning of bigger problems.
Trust me. If you need tabbed dialogs use property page and property sheet.
0
 

Author Comment

by:Ocrana
ID: 35135747
Hi, we use very much embedded dialogs in our projects and we do not have real problems with it. Those can happen, we got and we know how to avoid.
But that a "control" like CPropertySheet is not able to send a notification to its parent, is really wired. I have to make a own class of CPropertySheet catch the message and send to the parent. So I do not know what the difference here is in compare to use a CTabCtrl.
0
 
LVL 32

Expert Comment

by:sarabande
ID: 35136940
what notification are you talking of?

the property sheet in mfc is not a genuine feature but somewhat was set above using existing mfc elements like dialogs, tab control. so the basic functionality is to have tabbed modal dialogs.

the CPropertySheet is not thought of being used as a control, it normally is the main window and has no parent to notify. so i don't understand what you were complaining about.

if you need a tabbed control your approach using a CTabCtrl is right. instead of changing color of all page dialogs and their controls, did you consider to change the colors of your parent (frame?) window?

Sara

0
 
LVL 5

Expert Comment

by:JohnCz
ID: 35137042
Firstly you do not catch messages; they are delivered to a window and it is up to you to handle messages or not.

>>I have to make a own class of CPropertySheet

Well, if you have to handle a message you have to have window, message loop and window procedure, hence in MFC word you derive a class and attach window to its object. Than MFC framework allows you to amp messages to a member functions.
In Win 32 world, you create window and establish a message loop and window procedure; all of it is done by MFC framework
You I am not sure what message you are reefing to but I can assure you the property sheet works the way it was designes.

It is up to you what you are using and how you write your programs. For over 20 years of Windows programming I have never had any problems with property sheet.
I have my own programming rule: MEMC (Maximum Effect Minimum Coding).
Maybe in your app you need to use a tab control and dialogs; it is maybe justifiable. From my experience most of the time programmers take a harder route for a simple reason of not knowing how things work, not having enough experience. I am not saying you made your mind because of this.
Anyway maybe if you have explained in more details what functionality you are trying to implement, one of us would be able to  suggest different ways. It is up to you.
0
 
LVL 5

Expert Comment

by:JohnCz
ID: 35137260
Sarabande,

>>the property sheet in mfc is not a genuine feature but somewhat was set above using existing mfc
>>elements like dialogs, tab >>control. so the basic functionality is to have tabbed modal dialogs.


Neither property sheet, nor dialogs nor tab controls are elements of MFC. They are down to earth specialized windows delivered by the OS.
Property sheet does not use modal dialog they are modeless as any child window.

>>the CPropertySheet is not thought of being used as a control, it normally is the main window and
>>has no parent to notify. so i don't >>understand what you were complaining about.


There is nothing wrong calling it Control, since all Windows controls are windows. Usually control is a window that Is always used as a child.
 CProperySHeet is not a window; it is a class that encapsulates functionality of Windows property sheet predefined windows and object of this class may have window attached to it.
It may be used as a main window; however majority of time is used as modal top window owned or not by a main application window. It may be used as modeless top window or child window. It is used mainly to collect specific data grouped on property pages,

>>if you need a tabbed control your approach using a CTabCtrl is right. Instead of changing color of all
>>page dialogs and their >>controls, did you consider to change the colors of your parent (frame?)
>>window?

I think using tab control to create tabbed dialogs vs. property sheet is completely unnecessary and requires more coding than implementing a simple message and deliver it to a target window. It is an attempt to reinvent the wheel.
0
 
LVL 32

Expert Comment

by:sarabande
ID: 35138166
you missed my points (probably cause i explained it badly) which were an answer to the complaint that CPropertySheets do not have normal control behavior like notifying their parents from events
the CPropertySheet/CPropertyPage were not genuine mfc (window) classes like CDialog, CListbox, CEdit and others but were added later (i mean to remember it was because of OS/2 'notebook' but might be wrong). it doesn't matter for that argument that dialogs, and basic controls already had a base in the os but actually that was another difference. property sheet also doesn't belong to main mfc framework which has SDI, MDI and (single-)dialog only.

you may call all windows 'controls', i don't. i also don't think that a 'liberal' naming would bring any benefit (on the contrary, i think that is one of our major problems when explaining things).

for the usage of tabbed controls versus property sheet, i can say that i had experienced at least three huge frameworks based on mfc which made their own solution using tab controls. i did a lot myself by adding functionality for nested tab-controls and can say that using CPropertySheet never was an option. and the reinventing-of-the-wheel argument is weak in my opinion (if it ever had a justification) cause the base functionality of CPropertySheet is actually poor (you may look at the source code if you don't believe me). you also named the main weakness of the property sheet class: it is not a window. so you can't place controls above the tabs. if that is a must, you have to go your own ways using tab control.

Sara

0
 
LVL 8

Expert Comment

by:SunnyDark
ID: 35138696
I don't think the argument here is about what is better "CPropertySheets" or "CTabCtrl" there is a reason for them both to exist there and the choice is up to the developer whether to use one or another, each has it's advantages and disadvantages (as everything else in life... ) . However the original question was just "how to display the correct background".
0
 
LVL 32

Expert Comment

by:sarabande
ID: 35139040
the wrong color of the background comes from using the tab control instead of property sheet. so we can't separate the issues.

ocrana, what is your main window?

Sara
0
 
LVL 8

Expert Comment

by:SunnyDark
ID: 35139114
I believe that my comment  ID: 35133099 solves the issue with the dialog color which was confirmed by the author in comment ID: 35133824 and I do believe that my other comment  ID: 35133838 solves the issue with all the other controls.

0
Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

 
LVL 5

Expert Comment

by:JohnCz
ID: 35139284
I really do not want to drag this discussion, since it has nothing to do with original question.
If you want we can continue it but in different thread. Besides, I think that as far as windows is concerned we talk different languages.

CPropertySheets do not have normal control behavior like notifying their parents from events

Define normal behavior. It is by design. As I have mentioned property sheet is used most of the time as a top window – no parent. I am not sure what events you are referring to but Windows is message driven OS, not event driven. By the way dialogs do not notify parents either.

the CPropertySheet/CPropertyPage were not genuine mfc (window) classes like CDialog, CListbox, CEdit and others but were added later (i mean to remember it was because of OS/2 'notebook' but might be wrong). it doesn't matter for that argument that dialogs, and basic controls already had a base in the os but actually that was another difference. property sheet also doesn't belong to main mfc framework which has SDI, MDI and (single-)dialog only.

The very existence of dialog, list box, edit control, property sheet, button, and so on has nothing to do with existence of the MFC. Programs for Windows were written without C++ and MFC.
All of them exist as mere predefined windows classes (NOT MFC CLASSES) that have already designed window procedure that implements certain behavior and functionality.
MFC is just a set of classes that wraps Windows controls, providing simplified way of handling messages without a hassle ofwriting message loop and implementing window procedure. All MFC does is creating (or subclassing or attaching) Windows window created using Windows API.
MDI, SDI Dialog based are not an MFC framework. It is a name for an application type and you may easily create property sheet based application.
Ability to create main frame window  that is able to handle multiple frame window children is not introduced in MFC; it exists as Windows predefined entity. SDI, MDI etc. are only terms introduced by MFC to indicate object (document) centralized type of a design.
You can write any MFC application using pure Windows API, not using MFC at all.

you may call all windows 'controls', i don't. i also don't think that a 'liberal' naming would bring any benefit (on the contrary, i think that is one of our major problems when explaining things).

I fully agree with the part regarding liberal naming. That is why we should not refer to Windows messages as events.
However control is a loose term. Can you tell me how you define what constitute Windows control?

for the usage of tabbed controls versus property sheet, i can say that i had experienced at least three huge frameworks based on mfc which made their own solution using tab controls. i did a lot myself by adding functionality for nested tab-controls and can say that using CPropertySheet never was an option. and the reinventing-of-the-wheel argument is weak in my opinion (if it ever had a justification) cause the base functionality of CPropertySheet is actually poor (you may look at the source code if you don't believe me).

Implementation is up to the programmer. If you used tab control and dialogs is fine with me (against my  MEMC). However I still am in favor of using a property sheet.

you also named the main weakness of the property sheet class: it is not a window. so you can't place controls above the tabs. if that is a must, you have to go your own ways using tab control.

BUT property sheet is a window. CPropertySheet is not. Property sheet is not different in behavior than any dialog. The only difference is how it is created and fact that is using own dialog resource while dialogs use resource provided. You can put any control in a property sheet and place it anywhere as well as handle messages from controls in a property sheet.

0
 
LVL 44

Expert Comment

by:AndyAinscow
ID: 35139469
>>the CPropertySheet/CPropertyPage were not genuine mfc (window) classes like CDialog, CListbox, CEdit and others but were added later

If I remember correctly some of those 'examples of pure MFC' didn't exist in the first release in the early 1990's.  So are they MFC in that case then?  CPropertySheet/CPropertyPage are MFC based classes to simplify the work the programmer is faced with concerning 'reinventing the wheel'.  They might not be perfect but they do provide a good base functionality.
0
 
LVL 32

Expert Comment

by:sarabande
ID: 35139957
if you won't drag into that discussion why are you doing it?

i speak of mfc classes. so, when i said property sheet i meant a CPropertySheet and when i said listbox a CListBox and i do it cause we are discussing an mfc issue which likely should solved with mfc means and not using native winapi. these classes are not only adoptions of native winapi but have the advantage that they were elements of the mfc framework and so you could add them with resource editor, generate classes and 'event' handlers (yes, the 'messages' are called events when using the context menu for a 'control' in resource editor). all that you can't easily do when using the CPropertySheet and that's why it is not my favorite.

but i fully agree that if the only reason for turning CPropertySheet to a solution with CTabCtrl is the missing notification of a page change, it is a wrong decision, cause the CTabCtrl can't be fully specified in the resource editor either and has some flaws when using it where the color issue probably is of the minor ones.

Sara
0
 
LVL 32

Expert Comment

by:sarabande
ID: 35139975
welcome in the club, dinosaur andy :)

Sara
0
 

Author Comment

by:Ocrana
ID: 35140147
Guys, all this because each developer do it like he prefer? My point is, cause the CPropertySheet do not communicate with the parent window (messages/notifications) I use a CTabCtrl in this case. Others will build their own classes and shoot around with user messages. Where is the problem?
0
 
LVL 44

Expert Comment

by:AndyAinscow
ID: 35140663
>>CPropertySheet do not communicate with the parent window

I think it has already been said but that class is designed to be the parent window.  What you seem to want is non standard behaviour and is simply coded by forwarding the message onto the parent window in the handler in your proprety sheet based class.

Now back to hunting a steg for supper ;-)
0
 

Author Comment

by:Ocrana
ID: 35140886
The problem is that this MFC rubbish do not have any base. Different in MDI, SDI and dialog based. I know why I prefer to develop with QT.
0
 
LVL 44

Expert Comment

by:AndyAinscow
ID: 35141487
The problem is that this MFC rubbish do not have any base. Different in MDI, SDI and dialog based.

class CPropertySheet : public CWnd  
and
class CDialog : public CWnd

Hmmm !
One is rubbish because it is based on CWnd and the other is not rubbish because it is based on CWnd.
0
 
LVL 5

Expert Comment

by:JohnCz
ID: 35152967
If I remember correctly some of those 'examples of pure MFC' didn't exist in the first release in the early 1990's.
Andy,
Just for fun of it I have installed (virtual PC on 7) Windows 3.11 and 98 and VC++ 1.5 2.0 respectively using iso images of VC.
1.5 had just several classes. CPropertySHeet and CProperyPages appeared in VC++ 2.
Reminiscence of odl windows. . .
I still have original disk with VC++ 1.5 and 2 in unpacked wrapped in cellophane CD case. Until version 4.2, there was no Visual Studio. It was called Visual Wokbench.
0
 
LVL 8

Expert Comment

by:SunnyDark
ID: 35154333
@JohnCz:
I still have original disk with VC++ 1.5 and 2 in unpacked wrapped in cellophane CD case.
Respect man!
You could start up a museum!
0
 
LVL 44

Expert Comment

by:AndyAinscow
ID: 35154403
>>It was called Visual Wokbench.
Aha, the Chinese version ?  ;-)


My CD of Ver 1.52 says Visual C++ for 16 bit windows development.  I don't know if I have (in the cellar somewhere in a box?) floppies for Version 1.0  
It does bring back memories, using it to make a dll to patch up a problem in Access 2 - a big print job would not release resources properly after each report until the PC crashed and had to be rebooted.
0
 
LVL 5

Expert Comment

by:JohnCz
ID: 35155421
Andy, it was not (only) a Chinese version. Workbench in 3.11
0
 
LVL 32

Expert Comment

by:sarabande
ID: 35155655
i had subscription these times which got me all versions from 1.1 (NT3.5) over 1.3(W3.1) up to 4.3 (NT4.0). then they stopped subscription cause people didn't want a new visual studio every quarter.
I didn't get workbench.

Sara
0
 
LVL 5

Expert Comment

by:JohnCz
ID: 35156116
MSDN subscription and VC++ were separate at this time. Later, MS bundled all together.
0
 

Expert Comment

by:g_do
ID: 38604164
What the hell are all these pointless rambling comments by "experts"?
No solution to the question asked, other than a workaround that breaks with themes.
I've just wasted 10 minutes reading off-topic replies here - thanks, guys.
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Introduction: Database storage, where is the exe actually on the disc? Playing a game selected randomly (how to generate random numbers).  Error trapping with try..catch to help the code run even if something goes wrong. Continuing from the seve…
After several hours of googling I could not gather any information on this topic. There are several ways of controlling the USB port connected to any storage device. The best example of that is by changing the registry value of "HKEY_LOCAL_MACHINE\S…
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now