Enable / Disabled - data entry fields at runtime

[Dan Tallent]

I have a scenerio when my forms are first opened that the user cannot modify
the data. The fields are disabled to prevent them from modifying any of the
data. If a user wishes to modify the data he would be required to click a
"Edit" button which will test permissions or status information of the
record. If the application determines it is ok for the user to modify the
data, it enables the fields where the user now can make changes as
necessary. When the user is finished they can click the save button. The
fields background color is changed to reflect the edit-status of the field.

I have noticed that the read only flag seems to handle this situation,
however I do have one problem. Some of the fields on the form should
remain read-only. If I write a loop to enable/disable all of the controls
on the form then the "read-only" fields are enabled as well. I could write
code for each field but this seems a little backward to me. How is this
type of scenerio usually handled? I thought of adding a new property to
my controls, but then I would be required to inherit every possible user
control. I imagine there has to be a better way so I could continue to use
the standard controls and not have to write code for every control on the
form.

Anyone have any ideas on how this is normally addressed?

Thanks
Dan

[Roger Frost]

>... I have noticed that the read only flag seems to handle this situation,

>however I do have one problem. Some of the fields on the form should
remain read-only. If I write a loop to enable/disable all of the controls
on the form then the "read-only" fields are enabled as well. I could
write code for each field but this seems a little backward to me. How is
this type of scenerio usually handled? I thought of adding a new
property to my controls, but then I would be required to inherit every
possible user control. I imagine there has to be a better way so I could
continue to use the standard controls and not have to write code for every
control on the form.

I don't logically see how adding a new property to the controls would solve
this problem, even if you did want to customize them all...

Can you put the controls you wish to toggle inside a Panel control (or
multiple Panels), and leave the read-only fields out of it (them)?

[Dan Tallent]

With an additional property the code can be written to Enable the control
ONLY if the the the property is set to true. This property would be set at
design-time and would not
change during runtime.

Then code like the following could test this property. I haven't tested
this code, but this is the idea.

BTW, Thanks Jeff about the idea about using the tag property. It may be the
way I go unless I find a more standarized method.

public void Active(boolean mEnable)
{
foreach(Control oControl in this.Controls)
oControl.Enable d = (mEnable && (oControl.tag == "TRUE"));

}

"Roger Frost" <fr*****@hotmai l.comwrote in message
news:8E******** *************** ***********@mic rosoft.com...

... I have noticed that the read only flag seems to handle this
situation, however I do have one problem. Some of the fields on the
form should remain read-only. If I write a loop to enable/disable all
of the controls on the form then the "read-only" fields are enabled as
well. I could write code for each field but this seems a little
backward to me. How is this type of scenerio usually handled? I
thought of adding a new property to my controls, but then I would be
required to inherit every possible user control. I imagine there has to
be a better way so I could continue to use the standard controls and not
have to write code for every control on the form.

I don't logically see how adding a new property to the controls would
solve this problem, even if you did want to customize them all...

Can you put the controls you wish to toggle inside a Panel control (or
multiple Panels), and leave the read-only fields out of it (them)?

[G.S.]

On Sep 3, 9:52*am, "Dan Tallent" <s...@microsoft .comwrote:

With an additional property the code can be written to Enable the control
ONLY if the the the property is set to true. * This property would be set at
design-time and would not
change during runtime.

Then code like the following could test this property. * I haven't tested
this code, but this is the idea.

BTW, Thanks Jeff about the idea about using the tag property. *It may be the
way I go unless I find a more standarized method.

public void Active(boolean mEnable)
{
* * foreach(Control oControl in this.Controls)
* * * * * *oControl.Enabl ed = (mEnable *&& *(oControl.tag == "TRUE"));

}
"Roger Frost" <fros...@hotmai l.comwrote in message

news:8E******** *************** ***********@mic rosoft.com...

>... I have noticed that the read only flag seems to handle this
>situation, however I do have one problem. * Some of the fields on the
>form should remain read-only. * If I write a loop to enable/disable all
>of the controls on the form then the "read-only" fields are enabled as
>well. * I could write code for each field but this seems a little
>backward to me. *How is this type of *scenerio usually handled? * I
>thought of adding a new property to my controls, but then I would be
>required to inherit every possible user control. * I imagine there has to
>be a better way so I could continue to use the standard controls and not
>have to write code for every control on the form.

I don't logically see how adding a new property to the controls would
solve this problem, even if you did want to customize them all...

Can you put the controls you wish to toggle inside a Panel control (or
multiple Panels), and leave the read-only fields out of it (them)?- Hide quoted text -

- Show quoted text -

If you're using the standard BindingSource, you may find a neat way of
doing this to be the solution where you extend the BindingSource and
make it render the control read-only based on underlying data element
it binds to.

[Roger Frost]

>With an additional property the code can be written to Enable the control

>ONLY if the the the property is set to true. This property would be set
at
design-time and would not
change during runtime.

Then code like the following could test this property. I haven't tested
this code, but this is the idea.

BTW, Thanks Jeff about the idea about using the tag property. It may be
the
way I go unless I find a more standarized method.

public void Active(boolean mEnable)
{
foreach(Contro l oControl in this.Controls)
oControl.Enabl ed = (mEnable && (oControl.tag == "TRUE"));

}

Good thinking, and probably the same procedure Jeff had in mind. It seems
much more logical now. I just couldn't wrap my mind around the idea until I
seen this example. Thank you. :) As far as standardized goes, I think the
tag property was created to somewhat standardize non-standard "handling."
Give or take...

...
If you're using the standard BindingSource, you may find a neat way of
doing this to be the solution where you extend the BindingSource and
make it render the control read-only based on underlying data element
it binds to.

But for what it's worth, this is my favorite solution so far...

-Roger Frost

[Dan Tallent]

If you're using the standard BindingSource, you may find a neat way of
doing this to be the solution where you extend the BindingSource and
make it render the control read-only based on underlying data element
it binds to.

I am fairly new to C#, but this concept seems interesting. Thanks for idea
I'll check it out.

Thanks again
Dan