By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,757 Members | 1,990 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,757 IT Pros & Developers. It's quick & easy.

GUI:Instructions in the Title Bar

P: n/a
I notice in http://homepage.mac.com/bradster/iar...t/controls.htm
that in the comments on the "Click & Print Certificates" dialog (less
than a quarter way down the page) that "instructions in the title bar"
are frowned upon.

Why? Here are two examples where I did something I thought OK.

1) On a data sheet subform, a double click action brings up a modal pop
up with more details on the selected record. The pop up has navigation
keys which allow you to next, previous, first, last your way through the
data sheet without having to leave the pop-up. The data sheet is a
listing of work orders and fuel tickets. The title bar of the pop up
displays: "Work Order: FM-30012345" or "Fuel Ticket: 123456", depending
on which record is selected/is current in the data sheet. These titles
are repeated in each tab on the tab control on the pop up, albeit in
smaller lettering. I like my approach, especially when I have the auto
repeat property of the first/next/previous/last buttons I've installed
set to yes, as the selection blazes through on the background data sheet
and the only indication anything is changing on the pop up is the fast
changing notation in the title bar.

2) Error messages. Here are two typical of what I use.

The first is my standard case else for select err.number:

MsgBox "Error " & Err.Number & " " & Err.Description, vbCritical,
"sReportFormat", Err.HelpFile, Err.HelpContext

I usually put the name of the procedure in which the error takes place
in the title argument of the message box.

Another example might be, in an error handling routine or as part of a
loop, when a numeric is required instead of a non-numeric character:

MsgBox "You entered a character that was not a number!", vbExclamation,
"Enter a Number!"

What's critically wrong with any of the above examples?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Aug 7 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I think the problem is not following established interface standards,
confusing your users. Type "Interface Hall of Shame", you will find examples
of things to do and not to do.

In your 1st example, you could use the progress meter which lets the user
know you program is not hung and how far along your process has progressed.

In the 2nd, you are supplying error information, that cannot be acted on by
most users.

"Tim Marshall" <TI****@PurplePandaChasers.Moertheriumwrote in message
news:eb**********@coranto.ucs.mun.ca...
I notice in http://homepage.mac.com/bradster/iar...t/controls.htm
that in the comments on the "Click & Print Certificates" dialog (less
than a quarter way down the page) that "instructions in the title bar"
are frowned upon.

Why? Here are two examples where I did something I thought OK.

1) On a data sheet subform, a double click action brings up a modal pop
up with more details on the selected record. The pop up has navigation
keys which allow you to next, previous, first, last your way through the
data sheet without having to leave the pop-up. The data sheet is a
listing of work orders and fuel tickets. The title bar of the pop up
displays: "Work Order: FM-30012345" or "Fuel Ticket: 123456", depending
on which record is selected/is current in the data sheet. These titles
are repeated in each tab on the tab control on the pop up, albeit in
smaller lettering. I like my approach, especially when I have the auto
repeat property of the first/next/previous/last buttons I've installed
set to yes, as the selection blazes through on the background data sheet
and the only indication anything is changing on the pop up is the fast
changing notation in the title bar.

2) Error messages. Here are two typical of what I use.

The first is my standard case else for select err.number:

MsgBox "Error " & Err.Number & " " & Err.Description, vbCritical,
"sReportFormat", Err.HelpFile, Err.HelpContext

I usually put the name of the procedure in which the error takes place
in the title argument of the message box.

Another example might be, in an error handling routine or as part of a
loop, when a numeric is required instead of a non-numeric character:

MsgBox "You entered a character that was not a number!", vbExclamation,
"Enter a Number!"

What's critically wrong with any of the above examples?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

Aug 7 '06 #2

P: n/a
Tim Marshall wrote:
I notice in http://homepage.mac.com/bradster/iar...t/controls.htm
that in the comments on the "Click & Print Certificates" dialog (less
than a quarter way down the page) that "instructions in the title bar"
are frowned upon.

Why? Here are two examples where I did something I thought OK.

1) On a data sheet subform, a double click action brings up a modal pop
up with more details on the selected record. The pop up has navigation
keys which allow you to next, previous, first, last your way through the
data sheet without having to leave the pop-up. The data sheet is a
listing of work orders and fuel tickets. The title bar of the pop up
displays: "Work Order: FM-30012345" or "Fuel Ticket: 123456", depending
on which record is selected/is current in the data sheet. These titles
are repeated in each tab on the tab control on the pop up, albeit in
smaller lettering. I like my approach, especially when I have the auto
repeat property of the first/next/previous/last buttons I've installed
set to yes, as the selection blazes through on the background data sheet
and the only indication anything is changing on the pop up is the fast
changing notation in the title bar.

2) Error messages. Here are two typical of what I use.

The first is my standard case else for select err.number:

MsgBox "Error " & Err.Number & " " & Err.Description, vbCritical,
"sReportFormat", Err.HelpFile, Err.HelpContext

I usually put the name of the procedure in which the error takes place
in the title argument of the message box.

Another example might be, in an error handling routine or as part of a
loop, when a numeric is required instead of a non-numeric character:

MsgBox "You entered a character that was not a number!", vbExclamation,
"Enter a Number!"

What's critically wrong with any of the above examples?
I do both. No user/client has ever complained or reported being unable
to use the objects. TTBOMK no loss of efficiency has occurred. Up to
this time the sky has not fallen and civilization, such as it is, has
continued to plod along.
I plan to continue in my error-stricken way,

Aug 7 '06 #3

P: n/a

Tim Marshall wrote:
The title bar of the pop up
displays: "Work Order: FM-30012345" or "Fuel Ticket: 123456", depending
on which record is selected/is current in the data sheet. These titles
are repeated in each tab on the tab control on the pop up, albeit in
smaller lettering.
You are not displaying an instruction but are providing information,
i.e. you are not asking the user to do anything. I use this approach.

>
MsgBox "You entered a character that was not a number!", vbExclamation,
"Enter a Number!"
I would however reverse the prompt and the title to have:
MsgBox "Enter a number",vbExclamation,"You entered a character that was
not a number'

So in this example I would agree with orginal advice you were
questioning.

Now you have got me to think about I guess that I place information but
not an instruction in the title.

Aug 7 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.