Исходники.RU - Информационный сервер для программистов: исходники со всего света.

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                   |

| Вернуться в корень Архива |