Tabs Controls vs CPropertySheet
Gene Sewell -- genes@fast.net
Friday, April 19, 1996
Hi,
Environment : Windows NT Version :3.51 VC++ 4.1
I have a question of philosophy, if you all don't mind....
I wanted to implement a dialog box with tab controls in it. My bias was
that I didn't want to use a Property Sheet dialog because that was is geared
towards a specific function - i.e. "Properties of something." It would have
a specific kind of appearance, and since I wanted different buttons in
different locations, etc, the PropertySheet didn't seem to be what I would
use. I also didn't like the fact that the PropertySheet isn't derived from
CDialog, and might behave differently....
I found one helpful on-line doc called "Creating a Tabbed Dialog Box" which
helped me (somewhat) create a tabbed dialog box. I had a lot of trouble,
which was related to style settings....
One difference between my implementation and the article was that I used the
dialog editor to put a tab control in my dialog box and then called
GetDlgItem to get the window handle to it, rather than create the window
from scratch.
Anyway, after all the work, I now have a dialog box that works fine - I can
design the entire appearance of the dialog, and everything seems to work
just fine.
I have gotten the impression form this forum that more people were using
PropertySheets and were sometimes fighting the defaults involved (e.g. the
"Apply" button.)
My question is, if you want a dialog box that has a tab control, under what
situation would you use a PropertySheet vs a fully custom dialog box with
your own tab control embedded in it? What are the reasons why one would
choose one over the other. I have the feeling that it took a bit more work
to get the dialog box to work, but is that the issue, or is there somethign
else that I'm missing?
Thanks
Gene
----
If we don't change the direction we are going,
we are likely to end up where we are heading.
--- Chinese saying
Cleve Littlefield -- halfacre@intermind.net
Monday, April 22, 1996
[Mini-digest: 3 responses]
Gene Sewell wrote:
> I wanted to implement a dialog box with tab controls in it. My bias was
> that I didn't want to use a Property Sheet dialog because that was is geared
> towards a specific function - i.e. "Properties of something." It would have
> a specific kind of appearance, and since I wanted different buttons in
> different locations, etc, the PropertySheet didn't seem to be what I would
> use. I also didn't like the fact that the PropertySheet isn't derived from
> CDialog, and might behave differently....
>
> I found one helpful on-line doc called "Creating a Tabbed Dialog Box" which
> helped me (somewhat) create a tabbed dialog box. I had a lot of trouble,
> which was related to style settings....
>
> One difference between my implementation and the article was that I used the
> dialog editor to put a tab control in my dialog box and then called
> GetDlgItem to get the window handle to it, rather than create the window
> from scratch.
>
> Anyway, after all the work, I now have a dialog box that works fine - I can
> design the entire appearance of the dialog, and everything seems to work
> just fine.
>
> I have gotten the impression form this forum that more people were using
> PropertySheets and were sometimes fighting the defaults involved (e.g. the
> "Apply" button.)
>
> My question is, if you want a dialog box that has a tab control, under what
> situation would you use a PropertySheet vs a fully custom dialog box with
> your own tab control embedded in it? What are the reasons why one would
> choose one over the other. I have the feeling that it took a bit more work
> to get the dialog box to work, but is that the issue, or is there somethign
> else that I'm missing?
Environment: VC4.1, Win95
I, too, wanted to have a tab control inside a dialog box, like the one
inside the find dialog located in explorer. I instantiated a
CPropertySheet right inside of the dialog and had a dialog resource to
handle the rest. It works somewhat well, the onle problem being that I
can't move it where I want it without parts of it being cut off.
I don't know which is easier. Can you e-mail me the source for your tab
control so that I can see what you did? I will e-mail you mine if you
want and you can tell me what you think.
I looked into using a tab control directly but that seemed too
difficult, but I can't figure out how to make my existing CPropertySheet
look right. I seems you can't just do a movewindow on it, you also have
to move the tab control contained inside the CPropertySheet, then move
the individual pages. And even after you do that, the pages in the
CPropertySheet move back to their old position when the user selects a
different tab.
I don't know what the correct answer is, I am just struggling through
like everyone else.
--
*********************************
* *
* Cleve W. Littlefield *
* halfacre@intermind.net *
* kurt@skylink.net *
* *
*********************************
-----From: "David W. Gillett"
I've recently considered something very like this question, and
came down pretty much on the other side.
It seems to me that the big things that a raw CTabCtrl gives you is
owner-draw or button style as appearance options. There may be one
or two other minor benefits.
On the other hand, CPropertySheet with CPropertyPage provides
AddPage() and (even more importantly) pre-implemented redirection of
tab control notification events to the relevant pages -- CTabCtrl
gives you half the tools you need to build this. And property page
dialogs don't get created until the sheet needs to actually display
them.
AppStudio will let you embed a tab control in a dialog. It
provides less support for embedding a property page, but you can lay
out an invisible static group box or rectangle and size a property
sheet derivative to fit it with less than a dozen lines of (reusable)
code.
So my conclusion was that most of the time, a CPropertySheet will
do the job, and so wrestling with CTabCtrl is probably wasted effort.
Dave
-----From: "David Ohlssen"
I have successfully made an app that starts off with a single modal
propertysheet where each page is a button-board of related menu
options, eg data entry, reports, graphs, etc. Each button on a page
will open a modeless dialog which can float anywhere on the screen
for handy reference while others are open at the same time. By
stored pointers the open pages can communiate on the basis of list
box selections etc. to cause updates. The main property sheet is
not a dialog but the pages are. It easy to "get" the unneeded
buttons by id name and hide them.
The only problem is that there is no framework present and it is lot
of work to try and simulate print preview etc. I later did a
similar app with full doc/view and hid the main window after opening
the PS. Still struggling with preview. All this because I did
not want to have a window with "FILE ETC ETC HELP" menu as the main
interface!!!! A large PS with pages named "FILE", "HELP" etc. looks
really cool!
David O. Ohlssen
I _____________________________________ I
I | Davido@Commerce.CTech.ac.ZA | I
I | __ ____________ | I
I | / \/ Cape Town \ _ | I
I |__/ South Africa \/ \__________| I
I_________________________________________I
Thomas Schall -- Thomas.Schall@csv.ICA.Uni-Stuttgart.DE
Thursday, April 25, 1996
[Mini-digest: 2 responses]
On Apr 22, 12:39pm, Mads_G._Houmann@olicom.dk wrote:
> Subject: CStatusBar problem
> VC++ 4.0 / MSDN / Win95:
>
> I have a problem with the CStatusBar. I can't get it to use a 3D-look
> border, that "interfaces" with my framewindow border.
>
> I have created a skeleton SDI app. using AppWizard, but since I don't want
> an Doc-View application I have replaced the standard AppWizard window
> creation:
>
> CSingleDocTemplate* pDocTemplate;
> pDocTemplate = new CSingleDocTemplate(
> IDR_MAINFRAME,
> RUNTIME_CLASS(CATMSwMgVDoc),
> RUNTIME_CLASS(CMainWindow), // main SDI frame window
> RUNTIME_CLASS(CATMSwMgVView));
> AddDocTemplate(pDocTemplate);
>
> in my CMyWinApp::InitInstance() with a LoadFrame call:
>
> CMainWindow *pMainFrame = new CMainWindow();
> if ( !pMainFrame->LoadFrame( IDR_MAINFRAME,
> WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE ) )
> return FALSE;
> m_pMainWnd = (CWnd*) pMainFrame;
> pMainFrame->ShowWindow( m_nCmdShow );
> pMainFrame->UpdateWindow();
>
>
> When I use the DocTemplate code the stausbar gets the normal 3D look, but
> when I use my own code it is flat with no border. The CStatusBar is created
> in CMyFrameWnd::OnCreate() and is a member variable. The StatusBar creation
> code is the same for the two examples.
>
> --
> Mads Houmann [mgh@olicom.dk]
> Software Engineer
> Olicom A/S Denmark
>-- End of excerpt from Mads_G._Houmann@olicom.dk
I had the same problem and I found a more or less comfortable solution. In fact
I did not find a solution to get the 3D look of a toolbar in a frame window
without any tricks. I posted a message with the same question some days ago and
after a hard night I figured this out:
You get the look (that 3D line below the toolbat) by adding a view to the frame
window. I use a CFormView for that purpose because I only need some controls in
the client area. The initialization is done in the constructor of the frame
window (class CFrame in the following example).
CFrame::CFrame()
{
Create(NULL, "title");
m_toolbar.Create(this);
m_toolbar.LoadToolBar(SOME_ID);
m_toolbar.SetBarStyle( ... whatever you want ...);
// make the toolbar dockable or not
// the interesting part comes here
CRunTimeClass *pNewViewClass = RUNTIME_CLASS(CYourViewClass);
CCreateContext context;
// initialize the necessary structure members for the new view
context.m_pNewViewClass = pNewViewClass;
// the debugger states a warning if you don't provide a valid pointer
// but I have no problems so far because I don not use any document
// features
context.m_pCurrentDoc = NULL;
CView *pNewView = STATIC_DOWNCAST(CView, CreateView(&context));
if(pNewView != NULL)
{
// you have to activate the view manually
pNewView->ShowWindow(SW_SHOW);
SetActiveView(pNewView);
RecalcLayout();
}
}
That's it. I am sure this is not the best way to do the work but it just works.
Thomas
--
Dipl.-Ing. Thomas Schall
ICA-CSV EMail: schall@csv.ica.uni-stuttgart.de
Universitaet Stuttgart
Pfaffenwaldring 27 Tel. : +49 (0) 711 / 685 3756
70550 Stuttgart, Germany Fax : +49 (0) 711 / 685 3758
-----From: Luc Comeau
I wanted to move the CPropertySheet and pages too. I found an article in
the Microsoft Knowledge base at their WEB site. It number Q143291. It goes
through the steps to move the control in the dialog box at runtime. This
code is for version 4.x of MFC only.
I hope this helps.
Luc
Luc Comeau |
Bell SYGMA Telecom Solutions | email: lcomeau@on.bell.ca
900-160 Elgin Street | Phone: +1(613)781-4433
Ottawa, Ontario | Fax: +1(613)238-5239
CANADA, K1G 3J4 |
| Вернуться в корень Архива
|