ConfigureCustomerListBox is the method of interest. It is very
straightforward until the last line.
- The fabulous "GoGetEm" method
fetches the customers for the list.
| |
C#:
public
static EntityList<Customer> GoGetEm(){
return
PersistenceManager.DefaultManager.GetEntities<Customer>();
}
VB.NET:
Public
Shared Function GoGetEm()
As EntityList(Of Customer)
Return
PersistenceManager.DefaultManager.GetEntities(Of
Customer)()
End
Function |
- We pour those customers in a DevForce
EntityList named customers.
- We set the ListBox's datasource
to that list.
- We tell the ListBox to display
the name of the customer which it
obtains from the "CompanyName" property.
- We set the "ValueMember" so
that, when asked for its "SelectedValue",
the ListBox returns the output. from
the selected Customer's "__Self" property.
We run, click on a customer and
see something like this:

The mystery here is the peculiar property
name given to the ValueMember. The
Customer doesn't have a "__Self" property?
What is it anyway and why would we
want it?
Returning Objects, Not Data
"__Self" is a property that
returns the selected customer instance.
Not the customer Id or the customer
name or any other property of the selected
customer. It returns the entire customer
instance.
"__Self" is a bit of cleverness
that grows on you as you become more
familiar with object-oriented programming.
In the "old days" we'd be
content to get back a single property
of the selected customer. That's what
the ListBox control was designed to
do. Of course a typical object property
can return only a piece of raw data.
What if we received the entire selected
customer object instead? Then we could
access all of the customer's aspects
including its properties, methods,
and events. This is a much richer foundation
for constructing our orders query or
whatever else we want to do with the
selected customer.
Unfortunately, that's not the way
the ListBox works. Like most controls,
it wants to give you some data from
the selected object rather than the
object itself. Most UI controls are
stuck in this pre-object-oriented world.
The DevForce "__Self" property
finesses the limitation by returning
the object itself.
The example event handler drives that
point home by concatenating the selected
customer's Id to its name in the MessageBox
text, something we could not do without
access to the whole customer object.
Phantom (Dynamic) Properties
Of course the Customer class does
not have a "__Self" property.
DevForce created it for us.
Now DevForce can't actually change
the Customer class; that was fixed
at compile time. But DevForce can create
a property on-the-fly and add it to
the EntityList that holds customers.
More precisely, it creates a "__Self" property
and adds that property to the set of "PropertyDescriptors" maintained
by that EntityList.
Here is the cool part. .NET databinding
checks the EntityList for properties
of Customers before it checks
the Customer class. .NET asks the EntityList, "Do
you have a " __Self" property?" to
which the EntityList replies "I
sure do and here it is!" .NET
then invokes that " __Self" property
and returns the customer object result.
.NET doesn't care whether or not this
is an actual property of the Customer.
It relies upon the EntityList to deliver
a property (a "PropertyDescriptor" actually)
that it can call. DevForce takes care
of constructing the "__Self" property
and conveying it to .NET.
You might say that "__Self" is
a phantom property of the Customer
class. We prefer to call it a "Dynamic" property
because such properties are created "dynamically" at
runtime.
"__Self" is only one example
of such a property. DevForce creates
others and you can create your own
dynamic properties as well. But that's
a tip for another day.
|