DataGridView column order?

[Peter Duniho]

I am playing around with the DataGridView control, and am curious if
anyone knows how the default order for columns is chosen when the
DataSource is a simple IList containing objects with public properties?

I assume that when you bind to an actual database data source, the order
of the columns matches the order of fields in the records in the
database. That is, the order of the columns in the table you're binding
to. But a class has no similar natural ordering per se.

I made up a test class with the public properties Name, Time, and
Northbound. They are declared in the class in that order. I would have
guessed that the DataGridView would use those properties either in
alphabetical order, or in the order that they are declared in the class
(on the assumption, possibly wrong, that the order I declare them in the
class affects how they are managed internally by the run-time). However,
the DataGridView uses neither of these. Instead, it orders them Time,
Name, and Northbound.

Using reflection, I can see that the properties are in fact at least
listed in the members of the class in the order in which they were
declared in the class. So, whatever DataGridView is doing, it's not just
pulling them out of the list in order as they appear in the collection of
members that reflection provides.

What criteria is DataGridView applying when deciding which order to
display the columns?

Pete

p.s. This is partially just an academic question, as I can of course
reorder the columns to suit my intent. I just figured if I knew how
DataGridView was deciding to order the columns, I could avoid having to
reorder them after the DataSource has been bound. And of course, I'm
curious.

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

I don't believe that this order is defined. The DataGrid view uses the
BindingManagerBase (in this case, the CurrencyManager class) to determine
what the properties on an object are. In order to do this, it calls
GetItemProperties on the BindingManagerBase to get the property information
for the grid.

Now, there are a number of options here, since you can have an
ITypedList implementation being used as well, which will have it's
GetItemProperties method called, or there can be a TypeDescriptor which
returns a custom type descriptor, and that will return the property
information.

Given all that (and there is more, I think, maybe an implementation of
ICustomTypeDescriptor as well which can return property information) it's
easy to see why there is no defined order that is given to the properties on
the grid, since there are so many different ways to obtain it.

 

[Peter Duniho]

[...]
Given all that (and there is more, I think, maybe an implementation
of
ICustomTypeDescriptor as well which can return property information) it's
easy to see why there is no defined order that is given to the
properties on
the grid, since there are so many different ways to obtain it.

Well, that's all well and good, of course. But obviously not all of those
things apply in this specific case.

I was curious if there was a specific explanation for the case I'm asking
about: a simple class with public properties.

Thanks!
Pete

 

[Nicholas Paldino [.NET/C# MVP]]

That's the thing, without knowing the types that are offered up by the
IList implementation, those things could be possible. The IList
implementation does not offer any information about the types contained.
The ITypedList interface doesn't apply here, since you are just using the
IList implementation, but an ICustomTypeDescriptor implementation, or a
TypeDescriptionProviderAttribute is specific to the class its on and you
make no mention of these things.

Regardless, there is no order defined for any of these case. The
documentation makes no mention about how the property descriptors are to be
returned to the caller in any of these cases, so I would regard any
knowledge of such as an implementation detail.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

[...]
Given all that (and there is more, I think, maybe an implementation
of
ICustomTypeDescriptor as well which can return property information) it's
easy to see why there is no defined order that is given to the
properties on
the grid, since there are so many different ways to obtain it.

Well, that's all well and good, of course. But obviously not all of those
things apply in this specific case.

I was curious if there was a specific explanation for the case I'm asking
about: a simple class with public properties.

Thanks!
Pete

 

[Peter Duniho]

That's the thing, without knowing the types that are offered up by
the
IList implementation, those things could be possible. The IList
implementation does not offer any information about the types contained.

I'm not sure what you mean here. I am using a generic List<> array for
the IList, containing only the one type I've declared. I thought that was
reasonably clear in my original post (at least the part about my own class
being the data provider via its properties), but if not I apologize.

In other words, I _do_ know the type that is offered up by the IList, and
with that information it should be possible to explain why the order of
the columns is the way it is.

[...]
Regardless, there is no order defined for any of these case. The
documentation makes no mention about how the property descriptors are to
be
returned to the caller in any of these cases, so I would regard any
knowledge of such as an implementation detail.

I recognize why the documentation doesn't define this. It's obvious that
there are a broad variety of things that can be used as the DataSource.
However, I'm asking about a specific case, and I already made it clear
that half my interest is simply curiosity.

If you don't know the answer, that's fine. But telling me that I don't
need to know isn't useful. I already know that I don't _need_ to know.

Pete

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

Please tell me where I said that you don't need to know, because that is
most definitely not what I said.

In your original post, you state:

I am playing around with the DataGridView control, and am curious if anyone
knows how the default order for columns is chosen when the DataSource is a
simple IList containing objects with public properties?

While you do mention the IList implementation, you make no mention of
the objects themselves. If the objects contained in the IList implement
ICustomTypeDescriptor, or if they have a TypeDescriptorProviderAttribute
indicating a type which should be used to provide a TypeDescriptor instance,
then either of these can provide property information for the DataGridView
to consume. As a matter of fact, reflection is never used directly by the
DataGridView for the properties, it is ALWAYS through a TypeDescriptor.

You go on to state:

In other words, I _do_ know the type that is offered up by the IList, and
with that information it should be possible to explain why the order of the
columns is the way it is.

What you say is very true, but you fail to convey what you know to
everyone else, which is, do these types implement the previously mentioned
interface or have the attribute attached to them. I'm assuming no, but you
never make a statement one way or another.

To answer your original question (again), while you could inspect how in
your specific case the TypeDescriptor for your type returns the properties,
that is purely an implementation detail, something that you shouldn't base
any kind of design or implementation decision on.

It's really analagous to saying you know how a particular C++ compiler
is going to handle undefined cases in C++. You can know the specific
implementation detail, but it's not going to do you much good.

The best answer anyone can give you in this case is that the properties
are returned in the order that the TypeDescriptor for your type will offer
them up. In my case, I wired together a small example (see attached file),
which for me, has the properties returned in alphabetical order. This
properties are shown in the same order in a program using the same type when
a list of those is bound to a DataView.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

That's the thing, without knowing the types that are offered up by
the
IList implementation, those things could be possible. The IList
implementation does not offer any information about the types contained.

I'm not sure what you mean here. I am using a generic List<> array for
the IList, containing only the one type I've declared. I thought that was
reasonably clear in my original post (at least the part about my own class
being the data provider via its properties), but if not I apologize.

In other words, I _do_ know the type that is offered up by the IList, and
with that information it should be possible to explain why the order of
the columns is the way it is.

[...]
Regardless, there is no order defined for any of these case. The
documentation makes no mention about how the property descriptors are to
be
returned to the caller in any of these cases, so I would regard any
knowledge of such as an implementation detail.

I recognize why the documentation doesn't define this. It's obvious that
there are a broad variety of things that can be used as the DataSource.
However, I'm asking about a specific case, and I already made it clear
that half my interest is simply curiosity.

If you don't know the answer, that's fine. But telling me that I don't
need to know isn't useful. I already know that I don't _need_ to know.

Pete

 

[Peter Duniho]

Please tell me where I said that you don't need to know, because
that is
most definitely not what I said.

When you write: "so I would regard any knowledge of such as an
implementation detail", while at the same time not actually providing the
information I specifically asked for, that implies that you are simply
saying I don't need to know.

Maybe that's not what you meant, but it's sure how it came across.

If you don't know the answer to my question, why not just say so instead
of going on about all that other stuff. While I don't know the details as
well as you do, I _do_ understand that due to the nature of the
DataGridView control, the specifics of how the columns are populated will
vary according to the actual data source.

I don't need a reiteration of that. It's a given.

In your original post, you state:

I am playing around with the DataGridView control, and am curious if
anyone
knows how the default order for columns is chosen when the DataSource is
a
simple IList containing objects with public properties?

While you do mention the IList implementation, you make no mention of
the objects themselves.

Huh? You quoted the text in which I did in fact mention them: "objects
with public properties".

I further in the same post wrote: "I made up a test class with the public
properties Name, Time, and Northbound".

I didn't say anything about implementing ICustomTypeDescriptor or anything
else. It's a simple scenario, and there's no need to infer anything above
and beyond what I specifically stated. It should be clear from my
original post that I have a simple IList containing objects, with public
properties, that are each an instance of a single class.

Trust me, I would have included more details about anything else I was
doing in the code, had anything else existed.

[...]
You go on to state:

In other words, I _do_ know the type that is offered up by the IList, and
with that information it should be possible to explain why the order of
the
columns is the way it is.

What you say is very true, but you fail to convey what you know to
everyone else, which is, do these types implement the previously
mentioned
interface or have the attribute attached to them. I'm assuming no, but
you
never make a statement one way or another.

You didn't assume "no" in your previous response. Or if you did, you
failed to use that assumption in any way useful in your reply.

Since I did detail what I did implement, I see no reason for me to have to
write all the details about what I did NOT implement. Especially when
they are details that I'm not even aware are relevant (since I didn't know
about the whole TypeDescriptor thing).

The fact is, this is a very simple test scenario. If I explicitly stated
everything that I did _not_ implement, my post with be nearly as long as
the entire MSDN documentation, for the simple fact that I have _not_
implemented practically everything in the MSDN documentation.

To answer your original question (again), while you could inspect
how in
your specific case the TypeDescriptor for your type returns the
properties,
that is purely an implementation detail, something that you shouldn't
base
any kind of design or implementation decision on.

Are you saying that even when I don't do anything to explicitly implement
this "TypeDescription" of which you speak, than one still exists and is
relevant to my class?

That would have been useful information for you to mention when you first
brought it up, especially since you seem to be of the opinion that it
applies to my specific case.

It's really analagous to saying you know how a particular
C++ compiler
is going to handle undefined cases in C++. You can know the specific
implementation detail, but it's not going to do you much good.

I guess that depends on your definition of "good". I find that
practically any new knowledge does me "good". Whether I can use that
knowledge in the design of my applications is a separate question.

The best answer anyone can give you in this case is that the
properties
are returned in the order that the TypeDescriptor for your type will
offer
them up.

Thank you. That's the answer I was looking for in the first place. The
only thing missing from your first reply was to point out that even though
I did nothing to implement a TypeDescriptor, one still exists and is
applicable to my class. Without that specific statement, your post did
not appear to answer the question I asked.

In my case, I wired together a small example (see attached file),

Don't include attachments in non-binary newsgroups. They are usually
removed by news hosts. In fact, many simply block any post that has an
attachment (fortunately, mine just removes the attachments, so at least I
got to see your post).

which for me, has the properties returned in alphabetical order. This
properties are shown in the same order in a program using the same type
when
a list of those is bound to a DataView.

Are you sure that the properties are returned in alphabetical order? Or
is it possible that you have few enough properties, or all identical
types, or something like that that just makes it look like they are
returned in alphabetical order.

The reason I ask is that obviously in my own case, the properties are NOT
returned in alphabetical order (which would have been my guess as to what
order alternative to declaration order might be used). In my case, each
property is a different type: DateTime, string, and bool (that's the order
they appear in the DataGridView...they are declared in the order string,
DateTime, and bool, and alphabetically they would be in the order string,
bool, DateTime).

Pete