PropertyPage Communications
Ron H
parameters.
BACKGROUND!
CPropertySheet PropSht;
PropertyPage1 Pg1;
PropertyPage2 Pg2;
PropertyPage3 Pg3;
PropertyPage4 Pg4;
PropSht.AddPage(&Pg1);
PropSht.AddPage(&Pg2);
PropSht.AddPage(&Pg3);
PropSht.AddPage(&Pg4);
Pg1.variable = some variable; etc etc
PropSht.DoModal(); etc etc
PROBLEM!
One of the checkboxes on page 4 ( they are grouped by function ) enables a
feature on page 1.
QUESTION!
Is there a convenient way to have page 4 tell page 1 that a variable has
changed while the property sheet is open? Currently , the operator has to
close the property sheet and reopen it to see the effect.
Ron H.
David Wilkinson
I would use a derived CPropertySheet class and use variables in this class to
communicate between the pages.
--
David Wilkinson
Visual C++ MVP
Joseph M. Newcomer
they are the "views".
Create a BOOL variable that holds the state of the check box.
In the OnKillActive of page 4, store the boolean value of the check box.
In the OnSetActive of page 1, read the boolean value. Actually, what I do in the
OnSetActive is call my one central function, updateControls(), and IT knows to look in the
boolean value of the derived property sheet to see the state. See my essay on Dialog Box
Control Management on my MVP Tips site.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Pete Delgado
"Ron H" <rnh...@nospam.net> wrote in message
news:hrY8m.40789$Ta5....@newsfe15.iad...
>I have a dialog based application that has a 4 page property sheet for
>setup parameters.
> feature on page 1.
Shouldn't this be your first clue to poor UI design? A selection on one page
enables a feature on another page that is hidden from the user unless they
know where to look for it.
Since you haven't given the specifics, there's no way to know for sure, but
based upon your description it sounds as if this is a distinct possibility.
-Pete
Joseph M. Newcomer
page 4 enables the option on page 4, but if you switch back to page 1, the settings you
made on page 4 are "retained".
joe
Pete Delgado
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:hl9965tp1u79uth1u...@4ax.com...
> Another solution is to make the feature visible on both pages, so clicking
> the option on
> page 4 enables the option on page 4, but if you switch back to page 1, the
> settings you
> made on page 4 are "retained".
Joe,
That particular solution could be equally confusing because the user may not
understand why a particular setting or group of settings has been duplicated
on multiple pages.
I think this illustrates why UI design is such a high art and why, in many
cases, even the most successful designs are compromises.
-Pete
Joseph M. Newcomer
something like a "name" field that appears in each page of a property sheet, and editing
it in any one page changes it in all pages.
joe
Ron H
with external inputs such as an encoder. It also allows the user to enter
values for the encoder ( ppr etc.) and it requires a deeper knowledge of the
hardware. The first page ( default) only deals with the display options
which are personal preferences but require no knowledge of the hardware. One
of the display options depends upon having an optional encoder attached AND
knowing the ppr etc. My thought was that it is much cleaner to just not
make the option available if the encoder was not attached.
Sorry if it is a poor UI but it seems like the best way to deal with the
issue...
Ron H.
Ron H
employing the base class. I can pass variables to/from each page but my
feeble brain can't figure out how to pass variable info back and forth
between the sheet and each page. Can you point me to some example code?
Thanks
RonH.
Scott McPhillips [MVP]
The CPropertySheet-derived class should have a member variable for each
CPropertyPage. The constructor will do something like this:
// Create the tabbed pages
AddPage(&m_DogPage);
AddPage(&m_CatPage);
// Give them access to shared variables
m_DogPage.m_pParent = this;
m_CatPage.m_pParent = this;
Sheet uses the member variables to access page variables, each Page uses
m_pParent to access Sheet variables.
--
Scott McPhillips [VC++ MVP]
Joseph M. Newcomer
CMyPropertySheet from CPropertySheet and use that. Then I added to each page
CMyPropertySheet * GetPropertySheet() { return (CMyPropertySheet *)GetParent(); }
Note that my solution is usually a lot more general, and therefore this line of code
appears in the superclass property page from which all my property pages are derived, but
see my essay on subclassing dialogs (and form views and property pages). The simple
solution is just copy-and-paste the line shown above, and at that point you have access to
the property sheet.
joe
Pete Delgado
> Well, a certain amount of intelligence is expected in the user. It is
> very common to have
> something like a "name" field that appears in each page of a property
> sheet, and editing
> it in any one page changes it in all pages.
> joe
In such cases, it would likely be better to use a property page with an
embedded tab control. I personally cannot think of any major software
product that operates in the manner that you suggest, but I will take your
word that such programs exist.
I still believe that as a general rule, this is a very bad idea and unless
there is a very compelling reason to do so, the design should be avoided.
-Pete
Joseph M. Newcomer
reverse-engineered how to do it when the need arose in a product I was developing. I
didn't invent the approach.
joe
Pete Delgado
> Actually, I've run across several major products that do this, which is
> why I
> reverse-engineered how to do it when the need arose in a product I was
> developing. I
> didn't invent the approach.
> joe
All I can say is... Yuk!!! :-)
-Pete
Joseph M. Newcomer
change this setting, when the user may want to change it at any time. Can you set it up
so this is displayed in every page?" So I did. It worked well. The end users loved it,
especially because it was such an improvement over the old interface. Fewer mouse clicks.
joe
Pete Delgado
> My client said "It is really annoying that we have to keep switching back
> to this page to
> change this setting, when the user may want to change it at any time. Can
> you set it up
> so this is displayed in every page?" So I did. It worked well. The end
> users loved it,
> especially because it was such an improvement over the old interface.
> Fewer mouse clicks.
> joe
Depending upon the state of the previous interface, your redesign
modifications may indeed have been an improvement. I don't have enough
information to tell! However, based upon your style and design sensibilities
at the flounder web site, I'd have to conclude that you're still in the
stone age GUI-wise! ;)
All kidding aside, as I stated earlier, when I someone mentions this type of
thing, it's a red flag for me. While it may not always be a design faux pas,
in many cases it is. I think a good example of an alternative design for
situation that you mentioned earlier in the thread is shown in the project
properties dialog box for Visual Studio. The configuration and platform
categories are fixed on the dialog because a change in configuration or
platform will change the available properties and default values underneath.
-Pete
Joseph M. Newcomer
graphics. And I won't do anything that attacks my readers' machines by running unknown
code (such as JavaVirus) on them.
Then again, I could be using the fancier interfaces like Word does, such as a ribbon bar,
but I have this fundamental idea that GUIs ought to be *usable*. Weird, I know, but a
design criterion that clearly escaped the designers at Microsoft. Core idea is that the
GUI has to support workflow, instead of dictating it.
While the approach used in VS works when there is the potential for *everything* to
change, it is more problematic when only one or two elements change. For example, see my
Locale Explorer, which follows your suggestion; it has a fixed area at the bottom which is
common to all pages, and the pages above are all different. The issue is not one of
absolutes of design, but of examining the workflow of the task and accomodating what the
users need to do, in the least intrusive way possible. A smooth flow is essential. This
is the design issue that Microsoft totally ignored in the "improved" VS IDE and in the
"improved" Office IDE. The introduction of context sensitivity everywhere in VS means you
can't jump from one task to another; you have to sneak up on each by first getting
yourself into the context you need to be in so the commands you need are available. This
is poor interface design. The ribbon bar is the ultimate realization of the prinicple
"Never trust a UI designed by a programmer. It is logical, hierarchical, well-organized,
and completely and utterly unusable". In Word 2007 and PowerPoint 2007, I find that
everything I need to do is always 3-4 mouse clicks away. Due to terminal brain damage,
they do not support my creating a custom ribbon bar tab with everything *I* need to do all
in front of me; instead, I have to use whatever brain-dead ideas the original designer
thought helped organize the toolbar for first-time users. The concept of "workflow", of
having a toolbar that did what *I* need for *my* editing styles, escaped them entirely.
The fact that after I select a tab in Word and do something, it *reverts* to some other
tab based on the designer's misplaced ideas of workflow, is severely annoying; I had three
or four things to do from that selected tab, and now I have to select it *again*
(gee...sounds like VS all over; obviously, once I add a handler, I want to edit that
handler, not just add another handler...). They ignored workflow. They ignored *my*
workflow, which, under Office 2003, I could easily deal with by making custom toolbars so
everything I needed was one mouse click away! (In addition, they retained most of the
really stupid modal dialogs of Office 2003, such as the paragraph settings dialog, the
table properties dialog, etc., which would have been among the first things I would have
eliminated! I am more and more convinced that modal dialogs are a poor user interface for
most tasks, because they violate workflow)
Bottom line: look at workflow. Everything else is there to serve it.
joe
Pete Delgado
> My Web site looks like it does because I have no interest in wasting my
> time on fancy
> graphics. And I won't do anything that attacks my readers' machines by
> running unknown
> code (such as JavaVirus) on them.
Joe,
An effective and attractive web site design does not require fancy
graphics, javascript or anything of the sort. Take a look at the templates
that Andreas Vilkund offers for free. Note that his designs are about using
web and publishing standards to achieve attractive, usable designs.
http://andreasviklund.com/templates/
The reason for the "stone age" comment was because you still seem to think
that image rollovers and some of the other effects used on web pages are
achieved with javascript. In many cases, standard CSS selectors can be used.
For some interesting code examples and a look at the state of the art of web
design, take a look at http://www.alistapart.com/
I think that my main complaint about your site has always been about the
color and background choices that reduce contrast and increase eye strain.
>
> Then again, I could be using the fancier interfaces like Word does, such
> as a ribbon bar,
> but I have this fundamental idea that GUIs ought to be *usable*. Weird, I
> know, but a
> design criterion that clearly escaped the designers at Microsoft. Core
> idea is that the
> GUI has to support workflow, instead of dictating it.
I'd have to agree. I too find the ribbons used in many newer programs less
than usable. Certianly part of the problem is that I am "unlearning" many of
the things that I know from previous versions of Windows, but I find some of
the newer eye-candy to be less than useful and it seems more difficult to
actually find the items that I want and need at any given time.
Good rant! I enjoyed it! Have you considered using it as a basis for a new
article?
-Pete
Joseph M. Newcomer
On Fri, 24 Jul 2009 13:22:48 -0400, "Pete Delgado" <Peter....@NoSpam.com> wrote:
>
>"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
>news:sbhj65lons81jtcsf...@4ax.com...
>> My Web site looks like it does because I have no interest in wasting my
>> time on fancy
>> graphics. And I won't do anything that attacks my readers' machines by
>> running unknown
>> code (such as JavaVirus) on them.
>
>Joe,
>An effective and attractive web site design does not require fancy
>graphics, javascript or anything of the sort. Take a look at the templates
>that Andreas Vilkund offers for free. Note that his designs are about using
>web and publishing standards to achieve attractive, usable designs.
>
>http://andreasviklund.com/templates/
****
However, this would require that I edit the existing base of several hundred pages. There
is zero motivation for doing this.
****
>
>
>The reason for the "stone age" comment was because you still seem to think
>that image rollovers and some of the other effects used on web pages are
>achieved with javascript. In many cases, standard CSS selectors can be used.
>For some interesting code examples and a look at the state of the art of web
>design, take a look at http://www.alistapart.com/
****
This assumes that I care in the slightest about any of this. I don't need it on pages I
look at, and I don't feel like editing several hundred pages to add it to mine.
****
>
>I think that my main complaint about your site has always been about the
>color and background choices that reduce contrast and increase eye strain.
****
I find plain white boring. I want a little color. I didn't want to waste much time
figuring it out, so when I found something that looked OK, I used it. At least this is in
one style sheet, so if I ever felt motivated to change it, this would be easy.
But largely, I don't care too much about Web page design. As long as the pages don't
attack my machine, I can deal with most anything. Since I turned off animation and sound,
the Web has become tolerable to browse.
****
>
>
>>
>> Then again, I could be using the fancier interfaces like Word does, such
>> as a ribbon bar,
>> but I have this fundamental idea that GUIs ought to be *usable*. Weird, I
>> know, but a
>> design criterion that clearly escaped the designers at Microsoft. Core
>> idea is that the
>> GUI has to support workflow, instead of dictating it.
>
>I'd have to agree. I too find the ribbons used in many newer programs less
>than usable. Certianly part of the problem is that I am "unlearning" many of
>the things that I know from previous versions of Windows, but I find some of
>the newer eye-candy to be less than useful and it seems more difficult to
>actually find the items that I want and need at any given time.
****
If I can't have the 99% of what I want in front of me, all the time, no more than one
mouse click away, then the program is not usable. In Office 2007, at any given instant,
less than 10% of what I need to do is right in front of me all the time. The other 90% is
carefully hidden away in places where it is not useful, based on some designer dweeb's
idea that the ribbons should support my 90-year-old mother comfortably, but should not
ever be permitted to support me, even if I want to have something different. This is why
I still use Office 2003 for "real work"
****
****
No, but I probably should...right after the current project is finished...
joe
****