Design question abt how to handle an abundance of properties.

[Tom P.]

This is a design question: I have a customized ListView with three
columns Name, Size, and Date.

I am painting each of these with a LinearGradientBrush so each of them
has a Color1, Color2, and Direction.

There is also a different color for Files and Directories and those
colors can change when the mouse passes over and/or when the item is
selected by the user.

This leads to an inordinate amount of Properties:
PlainDirNameColor1, PlainDirNameColor2, PlainDirNameDirection,
MouseOverDirNameColor1, MouseOverDirNameColor2,
MouseOverDirNameDirection,
SelectedDirNameColor1, SelectedDirNameColor2,
SelectedDirNameDirection,
SelectedMouseOverDirNameColor1, SelectedMouseOverDirNameColor2,
SelectedMouseOverDirNameDirection... etc.

And that's just the Directory Name properties!
3*3*2*4 = 72 properties just to pain the darn thing.

I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?
Thanks for the help,
Tom P.

 

[Tom P.]

[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?

Sounds like you need to encapsulate a group of properties as a new class, 
and then set that as an instance of the new class rather than as separate 
properties.

There is, of course, the separate question as to whether this is really a 
reasonable UI to present to the user.  But you didn't ask about that.  

Pete

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom P.

 

[Tom P.]

[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?

Sounds like you need to encapsulate a group of properties as a new class, 
and then set that as an instance of the new class rather than as separate 
properties.

There is, of course, the separate question as to whether this is really a 
reasonable UI to present to the user.  But you didn't ask about that.  

Pete

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom P.

 

[Ignacio Machin ( .NET/ C# MVP )]

This is a design question: I have a customized ListView with three
columns Name, Size, and Date.

I am painting each of these with a LinearGradientBrush so each of them
has a Color1, Color2, and Direction.

There is also a different color for Files and Directories and those
colors can change when the mouse passes over and/or when the item is
selected by the user.

This leads to an inordinate amount of Properties:
PlainDirNameColor1, PlainDirNameColor2, PlainDirNameDirection,
MouseOverDirNameColor1, MouseOverDirNameColor2,
MouseOverDirNameDirection,
SelectedDirNameColor1, SelectedDirNameColor2,
SelectedDirNameDirection,
SelectedMouseOverDirNameColor1, SelectedMouseOverDirNameColor2,
SelectedMouseOverDirNameDirection... etc.

And that's just the Directory Name properties!
3*3*2*4 = 72 properties just to pain the darn thing.

I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?
Thanks for the help,
Tom P.

Hi,

You can have one class with three properties, color1, color2,
direction, and then create several instances (selected, mouseover, etc)

 

[Ignacio Machin ( .NET/ C# MVP )]

This is a design question: I have a customized ListView with three
columns Name, Size, and Date.

I am painting each of these with a LinearGradientBrush so each of them
has a Color1, Color2, and Direction.

There is also a different color for Files and Directories and those
colors can change when the mouse passes over and/or when the item is
selected by the user.

This leads to an inordinate amount of Properties:
PlainDirNameColor1, PlainDirNameColor2, PlainDirNameDirection,
MouseOverDirNameColor1, MouseOverDirNameColor2,
MouseOverDirNameDirection,
SelectedDirNameColor1, SelectedDirNameColor2,
SelectedDirNameDirection,
SelectedMouseOverDirNameColor1, SelectedMouseOverDirNameColor2,
SelectedMouseOverDirNameDirection... etc.

And that's just the Directory Name properties!
3*3*2*4 = 72 properties just to pain the darn thing.

I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?
Thanks for the help,
Tom P.

Hi,

You can have one class with three properties, color1, color2,
direction, and then create several instances (selected, mouseover, etc)

 

[Ignacio Machin ( .NET/ C# MVP )]

[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.
What would you suggest?

Sounds like you need to encapsulate a group of properties as a new class,  
and then set that as an instance of the new class rather than as separate  
properties.

There is, of course, the separate question as to whether this is reallya  
reasonable UI to present to the user.  But you didn't ask about that. 

Pete

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom

I will place them there.
If otherwise I will inherit from ListView and create the properties
for the control itself; This has the advantage that if you have more
than one of a type of column you have to specify it only once.

 

[Ignacio Machin ( .NET/ C# MVP )]

[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.
What would you suggest?

Sounds like you need to encapsulate a group of properties as a new class,  
and then set that as an instance of the new class rather than as separate  
properties.

There is, of course, the separate question as to whether this is reallya  
reasonable UI to present to the user.  But you didn't ask about that. 

Pete

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom

I will place them there.
If otherwise I will inherit from ListView and create the properties
for the control itself; This has the advantage that if you have more
than one of a type of column you have to specify it only once.

 

[Larry Smith]

I was wondering if I should extend the ColumnHeader object and store

them in there or just have a property-only class that is a property of
the FileSystemListView.

If there's a lot of customization going on that affect each "ColumnHeader"
(many properties or whatever) then creating a new derivative is the way to
go. It's cleaner and you'll have a much easier time supporting things in the
long run.

 

[Larry Smith]

I was wondering if I should extend the ColumnHeader object and store

them in there or just have a property-only class that is a property of
the FileSystemListView.

If there's a lot of customization going on that affect each "ColumnHeader"
(many properties or whatever) then creating a new derivative is the way to
go. It's cleaner and you'll have a much easier time supporting things in the
long run.

 

[Tom P.]

[...]
I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Only you can answer that question.  My only insight so far is that you can
put the three values into a single class, since they are related and
always used together.

I have the impression that you are using the settings for the column
itself, not the header, so it's a bit awkward to store them as part of the
header.  On the other hand, ListView doesn't really offer a per-column
data structure other than the header, and so storing the settings in the
ListView itself would require extra overhead/management to deal with the
possibility of rearranging the columns.  At the very least, you'd probably
wind up with a Dictionary<ColumnHeader, ColumnSettingsClass> (where
"ColumnSettingsClass" is this hypothetical data structure to store the
settings).

You have hit the nail on the head! The settings are not going to be
for the ColumnHeader (well, there are settings for them but there are
settings for the file and directory items too). If I store them in the
ColumnHeader it's just inappropriate.

I find either approach imperfect, and continue to be distracted by the
seeming inappropriateness of the formatting in the first place.

Pete

No offense but, there are several industries that make quite a good
living off "inappropriateness".

In practice it's not really as bad as you might think. It's just a
gradient filled box which makes fro an easier presentation on the
eyes. There's a set of 3 properties for the Name, Date, and Size
columns (9). Then there's 4 states "Plain", "Selected", "MouseOver",
and "MouseOver Selected" (36) There is the obvious difference between
Files and directories, so that's one set for each (72). It's not like
you see all 72 on screen at one time, overlapping. But, again, it's
really up to the user how it looks.

Thanks guys, I'll take a look at a couple of these and then resign
myself to not have a perfect design. I'll just have to keep trying.

Tom P.

 

[Tom P.]

[...]
I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Only you can answer that question.  My only insight so far is that you can
put the three values into a single class, since they are related and
always used together.

I have the impression that you are using the settings for the column
itself, not the header, so it's a bit awkward to store them as part of the
header.  On the other hand, ListView doesn't really offer a per-column
data structure other than the header, and so storing the settings in the
ListView itself would require extra overhead/management to deal with the
possibility of rearranging the columns.  At the very least, you'd probably
wind up with a Dictionary<ColumnHeader, ColumnSettingsClass> (where
"ColumnSettingsClass" is this hypothetical data structure to store the
settings).

You have hit the nail on the head! The settings are not going to be
for the ColumnHeader (well, there are settings for them but there are
settings for the file and directory items too). If I store them in the
ColumnHeader it's just inappropriate.

I find either approach imperfect, and continue to be distracted by the
seeming inappropriateness of the formatting in the first place.

Pete

No offense but, there are several industries that make quite a good
living off "inappropriateness".

In practice it's not really as bad as you might think. It's just a
gradient filled box which makes fro an easier presentation on the
eyes. There's a set of 3 properties for the Name, Date, and Size
columns (9). Then there's 4 states "Plain", "Selected", "MouseOver",
and "MouseOver Selected" (36) There is the obvious difference between
Files and directories, so that's one set for each (72). It's not like
you see all 72 on screen at one time, overlapping. But, again, it's
really up to the user how it looks.

Thanks guys, I'll take a look at a couple of these and then resign
myself to not have a perfect design. I'll just have to keep trying.

Tom P.