In need of some advice wrt "expanding" a ListView row

[Helmut Giese]

Hello out there,
I have to implement a control similar to the property editor in VS's
designer. I assume a ListView would be the right control to use as a
base, but I am lacking one idea:
When "expanding" a row (like e.g. the 'Anchor' property) some
additional rows are filled in. How do I manage these? How to store the
data (and types - some are text fields, some are combo boxes)
associated with these "sub rows"?

Any advice or link will be greatly appreciated.
Best regards
Helmut Giese

 

[Peter Duniho]

Hello out there,
I have to implement a control similar to the property editor in VS's
designer. I assume a ListView would be the right control to use as a
base, but I am lacking one idea:
When "expanding" a row (like e.g. the 'Anchor' property) some
additional rows are filled in. How do I manage these? How to store the
data (and types - some are text fields, some are combo boxes)
associated with these "sub rows"?

Sounds like you really want the TreeView control, rather than ListView.
Though, TreeView itself also won't support multi-column display the way
ListView will, so you'll have to pick what you want. Either one may
require doing some "owner draw" implementation to get exactly what you
want, assuming you can use the built-in controls at all.

Pete

 

[Scott Seligman]

Sounds like you really want the TreeView control, rather than ListView.
Though, TreeView itself also won't support multi-column display the way
ListView will, so you'll have to pick what you want. Either one may
require doing some "owner draw" implementation to get exactly what you
want, assuming you can use the built-in controls at all.

And there are "TreeListView" implementations floating around that you
might consider. http://www.codeproject.com/KB/list/treelistview.aspx is
one I've run across from time to time, but never had a compelling reason
to use.

 

[Helmut Giese]

Sounds like you really want the TreeView control, rather than ListView.
Though, TreeView itself also won't support multi-column display the way
ListView will, so you'll have to pick what you want. Either one may
require doing some "owner draw" implementation to get exactly what you
want, assuming you can use the built-in controls at all.

Hi Pete,
I am wondering: What is the property editor we use every day based on?
To me it looked like the base is a ListView since it has columns and
can handle groups (Accessibility, Appearance, etc.).
Maybe the 'TreeListview' Scott mentions is the way to go.
Best regards
Helmut Giese

 

[Helmut Giese]

And there are "TreeListView" implementations floating around that you
might consider. http://www.codeproject.com/KB/list/treelistview.aspx is
one I've run across from time to time, but never had a compelling reason
to use.

Hi Scott,
TreeListview - maybe that's the term I was looking for.
Thanks for the link and best regards
Helmut Giese

 

[Peter Duniho]

I am wondering: What is the property editor we use every day based on?
[...]

I don't know. I don't think that it's based on either ListView or
TreeView. AFAIK, that's the System.Windows.Forms.PropertyGrid control,
which doesn't inherit either ListView nor TreeView, and probably doesn't
use them via composition either.

I haven't used the PropertyGrid control myself in a program, but I suppose
it's possible that you could use _that_ control to get the behavior you
want. If you can represent the data you're editing as properties on an
object (which seems like that should not be a problem), the PropertyGrid
control could work for you.

Pete

 

[Helmut Giese]

I am wondering: What is the property editor we use every day based on?
[...]

I don't know. I don't think that it's based on either ListView or
TreeView. AFAIK, that's the System.Windows.Forms.PropertyGrid control,
which doesn't inherit either ListView nor TreeView, and probably doesn't
use them via composition either.

I haven't used the PropertyGrid control myself in a program, but I suppose
it's possible that you could use _that_ control to get the behavior you
want. If you can represent the data you're editing as properties on an
object (which seems like that should not be a problem), the PropertyGrid
control could work for you.

Hi Pete,
between my last posting and your answer I stumbled over the
PropertyGrid, and - yes - it is _exactly_ what I was looking for.
Thanks and best regards
Helmut Giese