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

Detecting edit mode - general

P: n/a
We have a client server application where we would like to not show Save and
Cancel buttons on a winform until the user has actually entered something
into a textbox or combobox etc., and there is something to actually save.
This logic is fundamental to the way we would like to do things in general
so it is worth our while to get this figured out correctly once and for all.

To my mind, what needs to be done is to be able to detect when the user has
entered edit mode. We have discovered a way that works, but it's kind of
kludge. We have discovered that we can make use of onKeyPress and detect
when a key is entered. When a key is pressed this effectively means the
user is in edit mode but there are catches. What if the user selects
something from a combobox instead of using the keyboard? we would then have
to trap for keyboard changes, listbox selections and one and on. I think
there is a better way but am not sure what it is.

There are two different issues - one with fields on a winform and another
with regard to grids on a winform. I have a question about grids posted
elsewhere.

Does anyone else have a better way for us to be able to detect if the user
has entered edit mode? I am aware that you can trap for column changing but
this only fires after the user has entered something and is getting ready to
leave the column. This is not what we want. We are hoping that something
fires as soon as the user makes a change to any cell so we can trap for it
and thereby make the buttons visible when they should be.

Anyone?

Nov 21 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Woody,

I've dealth with this problem many times. It is less painful to simply trap
the TextChanged event of a textbox, combobox, or datagrid cell. This event
triggers when the control's text changes with keyboard input, item
selections, etc...

-Fabricio
fg*************@yahoo.com

"Woody Splawn" wrote:
We have a client server application where we would like to not show Save and
Cancel buttons on a winform until the user has actually entered something
into a textbox or combobox etc., and there is something to actually save.
This logic is fundamental to the way we would like to do things in general
so it is worth our while to get this figured out correctly once and for all.

To my mind, what needs to be done is to be able to detect when the user has
entered edit mode. We have discovered a way that works, but it's kind of
kludge. We have discovered that we can make use of onKeyPress and detect
when a key is entered. When a key is pressed this effectively means the
user is in edit mode but there are catches. What if the user selects
something from a combobox instead of using the keyboard? we would then have
to trap for keyboard changes, listbox selections and one and on. I think
there is a better way but am not sure what it is.

There are two different issues - one with fields on a winform and another
with regard to grids on a winform. I have a question about grids posted
elsewhere.

Does anyone else have a better way for us to be able to detect if the user
has entered edit mode? I am aware that you can trap for column changing but
this only fires after the user has entered something and is getting ready to
leave the column. This is not what we want. We are hoping that something
fires as soon as the user makes a change to any cell so we can trap for it
and thereby make the buttons visible when they should be.

Anyone?

Nov 21 '05 #2

P: n/a
Are you suggesting that I trap the texchanged event of every textbox or
combobox etc., on the form? This seems rather onerous.
I have been told elsewhere that what I am really trying to do is to check to
see if the row is dirty.
"Fabricio" <Fa******@discussions.microsoft.com> wrote in message
news:5E**********************************@microsof t.com...
Woody,

I've dealth with this problem many times. It is less painful to simply trap the TextChanged event of a textbox, combobox, or datagrid cell. This event triggers when the control's text changes with keyboard input, item
selections, etc...

-Fabricio
fg*************@yahoo.com

"Woody Splawn" wrote:
We have a client server application where we would like to not show Save and Cancel buttons on a winform until the user has actually entered something into a textbox or combobox etc., and there is something to actually save. This logic is fundamental to the way we would like to do things in general so it is worth our while to get this figured out correctly once and for all.
To my mind, what needs to be done is to be able to detect when the user has entered edit mode. We have discovered a way that works, but it's kind of kludge. We have discovered that we can make use of onKeyPress and detect when a key is entered. When a key is pressed this effectively means the
user is in edit mode but there are catches. What if the user selects
something from a combobox instead of using the keyboard? we would then have to trap for keyboard changes, listbox selections and one and on. I think there is a better way but am not sure what it is.

There are two different issues - one with fields on a winform and another with regard to grids on a winform. I have a question about grids posted
elsewhere.

Does anyone else have a better way for us to be able to detect if the user has entered edit mode? I am aware that you can trap for column changing but this only fires after the user has entered something and is getting ready to leave the column. This is not what we want. We are hoping that something fires as soon as the user makes a change to any cell so we can trap for it and thereby make the buttons visible when they should be.

Anyone?

Nov 21 '05 #3

P: n/a
Yes, precisely what I suggested... trap the textchanged event. VB.NET allows
you to attach multiple delegates from different controls to a single event
handler (i.e. you only need one function to handle all the textchanged
events).

-Fabricio

"Woody Splawn" wrote:
Are you suggesting that I trap the texchanged event of every textbox or
combobox etc., on the form? This seems rather onerous.
I have been told elsewhere that what I am really trying to do is to check to
see if the row is dirty.
"Fabricio" <Fa******@discussions.microsoft.com> wrote in message
news:5E**********************************@microsof t.com...
Woody,

I've dealth with this problem many times. It is less painful to simply

trap
the TextChanged event of a textbox, combobox, or datagrid cell. This

event
triggers when the control's text changes with keyboard input, item
selections, etc...

-Fabricio
fg*************@yahoo.com

"Woody Splawn" wrote:
We have a client server application where we would like to not show Save and Cancel buttons on a winform until the user has actually entered something into a textbox or combobox etc., and there is something to actually save. This logic is fundamental to the way we would like to do things in general so it is worth our while to get this figured out correctly once and for all.
To my mind, what needs to be done is to be able to detect when the user has entered edit mode. We have discovered a way that works, but it's kind of kludge. We have discovered that we can make use of onKeyPress and detect when a key is entered. When a key is pressed this effectively means the
user is in edit mode but there are catches. What if the user selects
something from a combobox instead of using the keyboard? we would then have to trap for keyboard changes, listbox selections and one and on. I think there is a better way but am not sure what it is.

There are two different issues - one with fields on a winform and another with regard to grids on a winform. I have a question about grids posted
elsewhere.

Does anyone else have a better way for us to be able to detect if the user has entered edit mode? I am aware that you can trap for column changing but this only fires after the user has entered something and is getting ready to leave the column. This is not what we want. We are hoping that something fires as soon as the user makes a change to any cell so we can trap for it and thereby make the buttons visible when they should be.

Anyone?


Nov 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.