Ocrana
asked on
CTabCtrl with Dialog Background problem
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
Ocrana
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@SunnyDark:
sure, the dialog is changed but all controls are still grey.
sure, the dialog is changed but all controls are still grey.
then you need to handle other cases besides CTLCOLOR_DLG and return appropriate brush for each control...
ASKER
@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
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
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.
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.
ASKER
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.
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.
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
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
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.
>>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.
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.
>>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.
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/CPropertyPa
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
the CPropertySheet/CPropertyPa
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
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".
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
ocrana, what is your main window?
Sara
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.
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/CPropertyPa
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.
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/CPropertyPa
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.
>>the CPropertySheet/CPropertyPa
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/CPropertyPa
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/CPropertyPa
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
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
welcome in the club, dinosaur andy :)
Sara
Sara
ASKER
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?
>>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 ;-)
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 ;-)
ASKER
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.
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.
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.
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.
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.
@JohnCz:
You could start up a museum!
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!
>>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.
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.
Andy, it was not (only) a Chinese version. 
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
I didn't get workbench.
Sara
MSDN subscription and VC++ were separate at this time. Later, MS bundled all together.
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.
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.
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.