Question about using DataBindings

  • Thread starter Thread starter BobRoyAce
  • Start date Start date
B

BobRoyAce

Let's say that I have a form on which a user can edit a Customer
record. On the form I have a module level variable as follows:

Private mo_CurrentCustomer As Customer

where Customer is a class defined in the system. After the user makes
all of their data entries on the form, I move the data they entered
into the properties of the Customer object and save the data if all is
well with the data they entered.

Well, to do this type of thing in the past, I would use two Sub's on
every form like follows:

Private Sub UpdateFormToReflectCurrentCustomer()
txtCustomerName.Text = mo_CurrentCustomer.CustomerName

If (mo_CurrentCustomer.DOB.HasValue) Then
deDOB.DateTime = mo_CurrentCustomer.DOB
Else
deDOB.EditValue = System.DBNull.Value
End If

'...etc.
End Sub

Private Sub UpdateCurrentCustomerToReflectForm()
mo_CurrentCustomer.CustomerName = txtCustomerName.Text

If (Not IsDBNull(deDOB.DateTime)) Then
mo_CurrentCustomer.DOB = deDOB.DateTime
Else
mo_CurrentCustomer.DOB = Nothing
End If

'...etc.
End Sub

Well, this has worked fine for me. However, I just noticed that edit
controls can be bound to object properties like follows:

txtCustomerName.DataBindings.Add("Text", mo_CurrentCustomer,
"CustomerName")

Well, that seems pretty slick and easier to code. However, I am
wondering if there are any downsides to this.
For example, how will certain controls handle NULL values in
properties?
What happens if a control has a NULL value and is bound to a property
of the object that is not NULLABLE?
For a DATE control, which property of the control would I bind to a
date field of an object?
 
Well, this has worked fine for me. However, I just noticed that edit
controls can be bound to object properties like follows:

txtCustomerName.DataBindings.Add("Text", mo_CurrentCustomer,
"CustomerName")

Well, that seems pretty slick and easier to code. However, I am
wondering if there are any downsides to this.
For example, how will certain controls handle NULL values in
properties?
What happens if a control has a NULL value and is bound to a property
of the object that is not NULLABLE?
Click to expand...
Create a non-null version of the property on the object and bind to it.
For a DATE control, which property of the control would I bind to a
date field of an object?
Click to expand...
Assuming you mean the DateTimePicker control, you would use the Value
property.

Lars
 
What happens if a control has a NULL value and is bound to a property
Create a non-null version of the property on the object and bind to it.
Click to expand...

I don't quite understand what you mean by this. Could you explain?

I am thinking that the best solution to this issue might be to just
make sure that all properties that would be bound to controls that
could have NULL values, would just have to be NULLABLE types (e.g.
Nullable(Of Date)).
 
What happens if a control has a NULL value and is bound to a property
I don't quite understand what you mean by this. Could you explain?
Click to expand...
Sorry, I meant: Create a nullable version of the property on the object and
bind to it.
Date values are a good example of a common problem with null values.

Let's say you have a property "DueDate" that is of type DateTime, you could
create a property DueDateString of type string and bind that to your control
instead. In the setter, you would parse the date string into a date and set
DueDate to that date. If the text is blank or null, you set DueDate to
DateTime.Min instead. This works really well for textboxes - I have not
tried it with a DateTimePicker.

Check out this link for more info on how to handle nullable dates and
DateTimePickers:
http://www.codeguru.com/csharp/csharp/cs_controls/custom/article.php/c9645/
I am thinking that the best solution to this issue might be to just
make sure that all properties that would be bound to controls that
could have NULL values, would just have to be NULLABLE types (e.g.
Nullable(Of Date)).
Click to expand...
You could take that approach, but having tried both approaches, I have to
say the DateTimeString solution I mentioned above has worked better for me.
You might want to check out the SmartDate class in the CSLA framework.

Lars
 
Back
Top