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 >