RE: Property Pages vs. Regular Dialogs

"Frank Paris" <frank.paris-1QkGJYM4wCNWk0Htik3J/[email protected]> Wed, 6 Aug 2003 09:23:21 -0700
Newsgroups gmane.comp.programming.keyholes
Message-ID <2D17324AFD25D74F85728567DC919F4F01783645@msgusawmb02.ads.autodesk.com>
A tabbed dialog with OK, Cancel, and Accept buttons are said to have one
page per tab and the entire dialog is called a property sheet (never
mind the poor choice of terminology: admittedly Microsoft came up with
bad names). Tabbed dialogs are getting old fashioned because tabs have
proliferated so much they very often don't fit on one line and you can
pick your poison: shift them back and forth or lay them out on multiple
lines. The preferred practice nowadays is to have a tree control on the
left that picks the page that displays on the right. But it's the same
principle: you have one property page per node in the tree control on
the left. They're called properties because they control the properties
of some facility: an application, a printer, the machine itself, the
network, whatever. There is also another paradigm called Property Grids.
Visual Basic used them and now they are canonized in .NET.

To get to your question, when property pages were implemented with
tabbed dialogs, there was (still is) a built-in facility in Windows that
lets you do this "simply". That facility does not support resizeable
property sheets. If you rolled your own, of course, you could do
anything you want, but that could be 100 times harder than using the
built-in tool in the development environment. You would basically have
to reinvent 100 different wheels and gears and make it more flexible on
top of everything else. I can't recall ever seeing a tabbed dialog that
was resizeable. Just thinking about what you would have to do makes my
head spin.

Property Grids associated with tree controls solve a lot of these
problems. Property Grids have sections that themselves are arranged
hierarchically and sections and subsections can collapse and expand like
tree controls themselves, giving the user great flexibility over how his
available screen real estate is managed.

Basically a Property Grid has a label column and a value column. The
label describes the property to be controlled. The value column has
"widgets" in it that become active when the mouse clicks the row. How
the widget behaves depends on the widget. It may turn into an edit box,
a drop down list, or provide a ... button that when clicked brings up a
dialog such as a color chooser: any number of things.

> -----Original Message-----
> From: Scott Meyers [mailto:smeyers-Q9ZaqOuDrMJWk0Htik3J/[email protected]] 
> Sent: August 05, 2003 7:48 PM
> To: Software Keyholes; Software Keyholes
> Subject: [SK] Property Pages vs. Regular Dialogs
> 
> 
> At 09:14 AM 7/29/2003, Frank Paris wrote:
> >> From: Scott Meyers [mailto:smeyers-Q9ZaqOuDrMJWk0Htik3J/[email protected]]
> >> keyholes that do not strike you as gratuitous?  For purposes 
> >> of this discussion, let us assume that dynamically sizeable 
> >> listboxes are easy to implement.
> >
> >It depends on where they are. If they're in a Windows 
> property page or 
> >wizard, they are not easily resized (I know of no way to do it, 
> >assuming they are already filling up all of the available 
> real estate 
> >on the property page (which by Bill Gates' design is fixed 
> in size). If 
> >they are in a regular dialog, resizing them is as easy as 
> dynamically 
> >moving around all the other controls on the dialog as the 
> user resizes 
> >the dialog.
> 
> Color me ignorant.  What is a property page, and how does it 
> differ from a regular dialog?
> 
> Scott
> 
> _______________________________________________
> software-keyholes mailing list software-keyholes-xIg/pKzrS18HpDbxM/[email protected]
> http://artima1.inetu.net/mailman/listinfo/software-keyholes
>