October 2007 - Posts
Pages and User Controls often have to expose certain values that are actually a value stored in a control. For instance, a user control may have several controls that hold dollar amount data, date/time data, or other kinds. Oftentimes, data is loaded into a database and passed through some means to the user control. It's very helpful to use a property to represent the underlying data for that control. The reason is there is often some sort of conversion that takes place with the data. For instance, I was doing this with a user control:
public DateTime SubmittedDate
{
get
{
DateTime value;
if (DateTime.TryParse(txtSubmittedDate.Text, value))
return value;
else
return new DateTime(1900, 1,1);
}
set
{
me.txtSubmittedDate.Text = value.ToString();
}
}
This worked nice because the field was optional, and if it did, it defaulted to the smalldatetime equivalent of the date, which safely allowed it to be passed to a database. However, a change came in, and they wanted the time to be stripped off, so I could easily change the setter assignment using value.ToShortDateString(), and that made maintenance so much easier!
Even though this is a common approach for user controls, it could also be used for pages as well, and can have the same benefit. This works really well with amount fields, so you can do some processing, trim extra numeric characters after the decimal, etc.
Events have multiple purposes. Not only do they notify someone that someone occurred, but they can also be used to request information. This requires that the event argument that you are using has a writable property. For instance, suppose there was this event argument:
public class DataEventArgs
{
public object Data
{
get { return _data; }
set { _data = value; }
}
}
An event can expose this event argument. Whoever consumes some object's event with this event argument can write to this property value, as such:
private void MyObject_RequestData(object sender, DataEventArgs e)
{
if (_someCondition)
e.Data = "Yes";
else
e.Data = "No";
}
This way, the data is passed back to the caller, thereby allowing the event to request information. However, this requires that someone consumes it. The key is to have a default if no one consumes it, though in your situation you most likely will consume it (because its your application).
I was recently working with an application where I had to add an additional validation summary, and trigger the validation manually through the Page.Validate() method. I had to do this because of the way that the form needed validation. So, the approach I took was to create a validation group, for the controls that were
defined in a user control, and call Page.Validate() and Page.Validate("Group") in the one button event handler, and Page.Validate() in the other.
What I found was Page.Validate() called everything in the button event handler I didn't want it to. It turns out to call the main validation group, one must call Page.Validate(nothing) or Page.Validate(null). The next problem I ran into was that any errors on that validation group didn't get added to the validation summary control, because the validation summary only works with validators defined in the same validation group. This posed a problem for me, because it was all in one form and I didn't want extra validation summaries; that would have been confusing.
The alternative approach was after calling Page.Validate("Group"), to use GetValidators("Group") to get the validators in the other group, then to duplicate them
by adding them to the validation summary using a new validator with no validation group. (To do this, I used an approach similar to http://www.codeproject.com/aspnet/RuntimeValidation.asp). This worked fine then.
