Hi there,
Is there a general approach for preventing users from selecting a menu item
in an SDI or MDI application whenever the current field on your form is
invalid (assuuming the app consists of a data entry form). In my case, I'm
working with a "DataGridView" which occupies the entire child window of an
MDI app but the problem likely applies to any control. If you've entered
invalid data into a "TextBox" field of a form for instance (in my case a
grid cell), it's likely that most if not all items in your menus as well as
most hotkeys should be off-limits until the user corrects the field. Without
taking great pain to prevent users from gaining access to these items
however (it's not always trivial), is there an easier approach. Thanks.
11  1339 
The technique I use is to set, on the control(s), either Enabled or Visible
to false.
Another technique is to show a Dialog, which contains an input field, when
the error on the main form fails an audit. The Dialog is modal, meaning the
user must enter the data and dismiss the dialog before any other control can
be accessed. You process the Dialog by (re)auditing the data and reshowing
the Dialog if it is still incorrect. Else you accept it just as if it was
entered on the main form, and then continue with processing the form's other
input fields (in the same way).
"Jack White" <no_spam@_nospam.comwrote in message
news:Oc****************@TK2MSFTNGP06.phx.gbl...
Hi there,
Is there a general approach for preventing users from selecting a menu
item in an SDI or MDI application whenever the current field on your form
is invalid (assuuming the app consists of a data entry form). In my case,
I'm working with a "DataGridView" which occupies the entire child window
of an MDI app but the problem likely applies to any control. If you've
entered invalid data into a "TextBox" field of a form for instance (in my
case a grid cell), it's likely that most if not all items in your menus as
well as most hotkeys should be off-limits until the user corrects the
field. Without taking great pain to prevent users from gaining access to
these items however (it's not always trivial), is there an easier
approach. Thanks.
Thanks for the feedback.
The technique I use is to set, on the control(s), either Enabled or
Visible to false.
I find handling other controls easy enough because you can simply prevent
users from leaving the invalid control until it's valid. There are normally
custom events or overrides that assist with this, typically
"Control.OnValidating()" and "Control.OnValidated()". The problem is that
they don't prevent users from accessing the menu itself nor any hotkeys. For
that I'm finding a lot of re-wiring required to make everything work, even
if it's just disabling it (due to other issues I won't get into here). It's
not a smooth process.
Another technique is to show a Dialog, which contains an input field, when
the error on the main form fails an audit. The Dialog is modal, meaning
the user must enter the data and dismiss the dialog before any other
control can be accessed. You process the Dialog by (re)auditing the data
and reshowing the Dialog if it is still incorrect. Else you accept it
just as if it was entered on the main form, and then continue with
processing the form's other input fields (in the same way).
That's not a bad idea actually (for some controls anyway) but I'm wondering
if users would find it a little unwieldy. Maybe I can dock the field to the
dialog and then superimpose the whoe thing on the original field so the user
won't notice anything. A reusable control of this type would be useful for
this purpose but it's still unorthodox. You would also have to centralize
the logic for handling the field so it can now be called from the original
form and the dialog. I'll give it some more thought but I have to believe
there's a more mainstream way of handling this situation in general. Thanks
again though (appreciated).
On Mar 2, 6:23 pm, "Jack White" <no_spam@_nospam.comwrote:
Hi there,
Is there a general approach for preventing users from selecting a menu item
in an SDI or MDI application whenever the current field on your form is
invalid (assuuming the app consists of a data entry form). In my case, I'm
working with a "DataGridView" which occupies the entire child window of an
MDI app but the problem likely applies to any control. If you've entered
invalid data into a "TextBox" field of a form for instance (in my case a
grid cell), it's likely that most if not all items in your menus as well as
most hotkeys should be off-limits until the user corrects the field. Without
taking great pain to prevent users from gaining access to these items
however (it's not always trivial), is there an easier approach. Thanks.
Jack:
Are you asking how to validate the users data, or how to act once
validation has been processed?
Jack:
>
Are you asking how to validate the users data, or how to act once
validation has been processed?
I'm really asking if there's a mainstream way to prevent users from
selecting menu items or activating hot keys when they try to leave a control
that currently has invalid data in it. Relying on the "Control.Validating"
event for instance works fine for other controls (preventing the user from
selecting them) but it doesn't prevent users from selecting a menu item.
Most menu items however (and hot keys) are probably invalid at this stage as
well (just like other controls) but the user can click them anyway. The
plumbing involved to manually prevent it is often non-trivial and
inconsistent with the "Control.Validating" model. I'm wondering how others
handle this. Thanks for the feedback.
I use the Composite UI App block (CAB) which allows you to map menu
items, etc... to commands which I disable. When the command is
disabled, everything mapped to it is also disabled. The same thing
happens for hiding commands.
--
Bryan Phillips
MCSD, MCDBA, MCSE
Blog: http://bphillips76.spaces.live.com
"Jack White" <no_spam@_nospam.comwrote in message
news:#R**************@TK2MSFTNGP03.phx.gbl:
Jack:
Are you asking how to validate the users data, or how to act once
validation has been processed?
I'm really asking if there's a mainstream way to prevent users from
selecting menu items or activating hot keys when they try to leave a control
that currently has invalid data in it. Relying on the "Control.Validating"
event for instance works fine for other controls (preventing the user from
selecting them) but it doesn't prevent users from selecting a menu item.
Most menu items however (and hot keys) are probably invalid at this stage as
well (just like other controls) but the user can click them anyway. The
plumbing involved to manually prevent it is often non-trivial and
inconsistent with the "Control.Validating" model. I'm wondering how others
handle this. Thanks for the feedback.
>I use the Composite UI App block (CAB) which allows you to map menu items,
>etc... to commands which I disable. When the command is disabled,
everything mapped to it is also disabled. The same thing happens for
hiding commands.
I'll take a look at this. Thanks. Note however that disabling items is only
part of the story. When you write a "Control.Validating" handler for
instance, you'll typically display an error message for the user if the
current control is invalid and then cancel the event by setting
"CancelEventArgs.Cancel" to "true". This prevents users from changing focus
to another control. Since this doesn't prevent users from clicking a menu
item however (using the mouse or an accelerator key), you would have to
disable/enable these items at the very moment the control becomes
invalid/valid. Doing this isn't trivial however (it means validating a
textbox on every keystroke for instance) but even if you do disable them,
there's no feedback for the user as to why these items are suddenly
disabled. Instead, when they click a menu item (or use a hotkey), they
should see the same consistent error message that's normally displayed by
"Control.Validating". Unfortunately, wiring this all up is not a simple
task.
"Jack White" <no_spam@_nospam.comwrote in message
news:OH*************@TK2MSFTNGP05.phx.gbl...
I'll take a look at this. Thanks. Note however that disabling items is
only part of the story. When you write a "Control.Validating" handler for
instance, you'll typically display an error message for the user if the
current control is invalid and then cancel the event by setting
"CancelEventArgs.Cancel" to "true". This prevents users from changing
focus to another control. Since this doesn't prevent users from clicking a
menu item however (using the mouse or an accelerator key), you would have
to disable/enable these items at the very moment the control becomes
invalid/valid. Doing this isn't trivial however (it means validating a
textbox on every keystroke for instance) but even if you do disable them,
there's no feedback for the user as to why these items are suddenly
disabled. Instead, when they click a menu item (or use a hotkey), they
should see the same consistent error message that's normally displayed by
"Control.Validating". Unfortunately, wiring this all up is not a simple
task.
IMO, you are going to a lot of trouble to make your app worse. Restricting
the user to a particular control when it is invalid is one of the worst and
most annoying UI designs possible. It gives your app a very unprofessional
feel and a large number of users will uninstall it as soon as they encounter
this feature (assuming they have a choice :-).
You should allow your users to leave the control and validate what they have
entered when they push ok or whatever is appropriate.
Michael
IMO, you are going to a lot of trouble to make your app worse. Restricting
the user to a particular control when it is invalid is one of the worst
and most annoying UI designs possible. It gives your app a very
unprofessional feel and a large number of users will uninstall it as soon
as they encounter this feature (assuming they have a choice :-).
You should allow your users to leave the control and validate what they
have entered when they push ok or whatever is appropriate.
No, I disagree with that and so does MSFT (based on how their
"Control.Validating()" model works). In my (long) experience, if a field
contains invalid data then it should be trapped immediately unless it's
either a cross-validation errror (i.e., the field itself contains valid data
but it's invalid in conjunction with some other field), or it's a mandatory
field that's currently blank but hasn't been filled in yet. These should be
validated when OK is clicked (or in a grid control like "DataGridView", when
the user attempts to leave the row itself opposed to the cell). All other
validation errors should be trapped immediately since it makes no sense to
allow a user to leave a field (or a cell) if its data is invalid. This is
usually the ergonomically correct way of doing things and users wouldn't
(and shouldn't) expect otherwise. Moreover, in my own case, I have an MDI
child window which consists of one "DataGridView" control that consumes the
entire window. Just about everything on my menus applies to that control so
if the current cell is invalid, then almost all menu items are off-limits.
Even if I did things the way you're suggesting, I would still need to treat
these menu items as if the OK button was pressed, validating my control and
preventing the user from exercising these items.
"Jack White" <no_spam@_nospam.comwrote in message
news:eS**************@TK2MSFTNGP02.phx.gbl...
No, I disagree with that and so does MSFT (based on how their
"Control.Validating()" model works).
That's just plain wrong. MS rarely use the model you're describing in their
software. I was going to save never but I did think of at least 1 obscure
example. In the case when they do this (designing a query in MS Access), I
find it annoying and it is definately unnecessary (why can't I just leave
the field and fix it later?).
In my (long) experience, if a field contains invalid data then it should
be trapped immediately unless it's either a cross-validation errror (i.e.,
the field itself contains valid data but it's invalid in conjunction with
some other field), or it's a mandatory field that's currently blank but
hasn't been filled in yet. These should be validated when OK is clicked
(or in a grid control like "DataGridView", when the user attempts to leave
the row itself opposed to the cell). All other validation errors should be
trapped immediately since it makes no sense to allow a user to leave a
field (or a cell) if its data is invalid.
What if they want to push cancel? What if they want to fill it in last? What
if they want to copy-paste the result from another field? What if they just
want to leave because they want to? There is absolutely no reason to force
them to remain at that field. It's annoying and treats the user as an idiot.
What you say about leaving the row does make some sense assuming leaving the
row acts as pushing ok. This is annoying also but as leaving a row is the
same as pushing ok you need to validate then and there.
This is usually the ergonomically correct way of doing things and users
wouldn't (and shouldn't) expect otherwise.
It's extremely rare these days (to have the focus restricted to the field)
and 99% of users would expect to be able to leave the field. Try watching
some users use such an app, they most definately do expect otherwise. You
can watch them try to leave the field, get suprised at the message, click
ok, try to leave again, get annoyed, eventually enter false data and then
push cancel.
Moreover, in my own case, I have an MDI child window which consists of one
"DataGridView" control that consumes the entire window. Just about
everything on my menus applies to that control so if the current cell is
invalid, then almost all menu items are off-limits.
Other areas of the app should assume the previous data until valid data is
entered. Hence, nothing else should be off limits. This is fairly simple to
implement because as the data has not been saved to the database, the
database contains the previous data.
Even if I did things the way you're suggesting, I would still need to
treat these menu items as if the OK button was pressed, validating my
control and preventing the user from exercising these items.
No you wouldn't.
Michael
"Michael C" <no****@nospam.comwrote in message
news:e5**************@TK2MSFTNGP05.phx.gbl...
"Jack White" <no_spam@_nospam.comwrote in message
news:eS**************@TK2MSFTNGP02.phx.gbl...
>No, I disagree with that and so does MSFT (based on how their
"Control.Validating()" model works).
That's just plain wrong. MS rarely use the model you're describing in
their software. I was going to save never but I did think of at least 1
obscure example. In the case when they do this (designing a query in MS
Access), I find it annoying and it is definately unnecessary (why can't I
just leave the field and fix it later?).
>In my (long) experience, if a field contains invalid data then it should
be trapped immediately unless it's either a cross-validation errror
(i.e., the field itself contains valid data but it's invalid in
conjunction with some other field), or it's a mandatory field that's
currently blank but hasn't been filled in yet. These should be validated
when OK is clicked (or in a grid control like "DataGridView", when the
user attempts to leave the row itself opposed to the cell). All other
validation errors should be trapped immediately since it makes no sense
to allow a user to leave a field (or a cell) if its data is invalid.
What if they want to push cancel? What if they want to fill it in last?
What if they want to copy-paste the result from another field? What if
they just want to leave because they want to? There is absolutely no
reason to force them to remain at that field. It's annoying and treats
the user as an idiot.
What you say about leaving the row does make some sense assuming leaving
the row acts as pushing ok. This is annoying also but as leaving a row is
the same as pushing ok you need to validate then and there.
>This is usually the ergonomically correct way of doing things and users
wouldn't (and shouldn't) expect otherwise.
It's extremely rare these days (to have the focus restricted to the
field) and 99% of users would expect to be able to leave the field. Try
watching some users use such an app, they most definately do expect
otherwise. You can watch them try to leave the field, get suprised at the
message, click ok, try to leave again, get annoyed, eventually enter
false data and then push cancel.
>Moreover, in my own case, I have an MDI child window which consists of
one "DataGridView" control that consumes the entire window. Just about
everything on my menus applies to that control so if the current cell is
invalid, then almost all menu items are off-limits.
Other areas of the app should assume the previous data until valid data
is entered. Hence, nothing else should be off limits. This is fairly
simple to implement because as the data has not been saved to the
database, the database contains the previous data.
>Even if I did things the way you're suggesting, I would still need to
treat these menu items as if the OK button was pressed, validating my
control and preventing the user from exercising these items.
No you wouldn't.
Michael
I'm going to throw my two cents' worth in and say that I agree with
Michael. It would annoy me to no end, and I would toss the software out if
I could. Think how you would feel if Visual Studio made you fix every error
before letting you continue to the next word or statement.
For validation, I use the ErrorProvider control in combination with a
self-written Validation class that I inherit for each entry form. As the
user leaves the field, if it is wrong, it gets highlighted with an error
icon. I don't let them save the data unless there are no errors (which I
can check by checking the Count on my Validation class). If they try to
move to the next record or something like that, they have to save or cancel
their changes first. More code for me to write, but my users are much
happier.
Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-------------------------------------------------------------
"Jack White" <no_spam@_nospam.comwrote in message
news:Oc****************@TK2MSFTNGP06.phx.gbl...
>
Is there a general approach for preventing users from selecting a menu
item in an SDI or MDI application whenever the current field on your form
is invalid
1) Please use a meaningful subject line.
2) Please do not spam multiple groups.
3) Please do not post non-C# messages to a C# newsgroup.
Thanks,
///ark This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ali Eghtebas |
last post by:
Hi,
I've made this regex to catch the start of a valid multiline comment such as
"/*" in e.g. T-SQL code.
"(?<=^(?:*'*')*?*)(?<!^(?:*'*')*?--.*)/\*.*?$"
With Multiline option on.
As we know...
|
by: Michael Winter |
last post by:
In a recent post ("About C error" by Victor, 21 Sep 2003), comments were
made about the poster's use of macros. What I would like to know is why
they are considered bad? I'm not referring to...
|
by: Sandeep Sharma |
last post by:
Right from the time the first edition of K&R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute...
|
by: Capstar |
last post by:
Hi,
I am working on an application, which will run embedded without an OS.
The app is build up out of a couple of well defined parts. At first I
wanted to keep those parts seperated and use...
|
by: SStory |
last post by:
Hello Group.
I am a VB/VB.NET programmer. I have done some C/C++ years ago.
I am considering a job opportunity which is unfortunately in C# and not
VB.NET.
What is the group's opinion on...
|
by: Fao, Sean |
last post by:
A guy I know never refactors his code and insists on putting everything
in an event handler. For example, he does some initialization of a
DataGrid in the ItemDataBound event handler (which is...
|
by: =?Utf-8?B?TWljaGVsIFBvc3NldGggW01DUF0=?= |
last post by:
In my opinion rethrowing exceptions without providing anny extra information
is a totall waste
Examples :
in my opinion wrong :
A:
Public sub DoSomeStuff()
Try
do it
|
by: azrael |
last post by:
id like to hear your opinion about something.
I just started using Prolog yesterday and i have my doubts about it,
but it seems to me something like object oriented. so i wanted to ask
you how...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
