Friday, November 18, 2005
ListViewItem - what a good idea....
As I may have mentioned, I work on a fair size WinForms app in C#. This app up until now has shown images from only one source, but I've added the ability to import still frames from video files. We wanted to be able to show only video imports, so I added a field to the XML metadata that we store, and wrote a filter. At the moment there is a modified listview to show images, so I added a property to tell me which items to draw. As the listview organises items itself, it seemed logical to store all images in a seperate list, and then give the listview only the images it was supposed to display, so the drawing code would not need to be changed.
A ListView contains a ListViewItemCollection, and a ListViewItemCollection can only be created by telling it the ListView which it belongs to. So, in order to create a second collection, I needed to create a second ListView instance, inside my Listview derived class. That's fine. However, and this is my point, I discovered that the ListViewItemCollection has a method called AddRange. Just looking at it in C# 1.1, it appears to have one signature only, which takes an array of ListViewItems. However, in C# 2.0, it has a second signature. It takes a ListViewItemCollection, and also indexes to say which items to move.
Now, if you call this method, trying to copy items from one ListViewItemCollection to another, you get an error message, as it's not possible to place a ListViewItem into one ListView ( and therefore ListViewItemCollection ) without removing it from the other one. So, a method has been added to the framework which is useless, as it does not remove the item from the old collection before moving it to the new, which means it can never work.
Naturally, this was not a major impediment to my problem, which is now solved. It does lead me to question the quality control that goes on when these class libraries are designed, or perhaps written ( given that it's possible to write a method that does this and works ).
It almost makes me feel inspired to rave again about how terrible the implimention of the AudioVideoPlayback namespace in DX9 is.
A ListView contains a ListViewItemCollection, and a ListViewItemCollection can only be created by telling it the ListView which it belongs to. So, in order to create a second collection, I needed to create a second ListView instance, inside my Listview derived class. That's fine. However, and this is my point, I discovered that the ListViewItemCollection has a method called AddRange. Just looking at it in C# 1.1, it appears to have one signature only, which takes an array of ListViewItems. However, in C# 2.0, it has a second signature. It takes a ListViewItemCollection, and also indexes to say which items to move.
Now, if you call this method, trying to copy items from one ListViewItemCollection to another, you get an error message, as it's not possible to place a ListViewItem into one ListView ( and therefore ListViewItemCollection ) without removing it from the other one. So, a method has been added to the framework which is useless, as it does not remove the item from the old collection before moving it to the new, which means it can never work.
Naturally, this was not a major impediment to my problem, which is now solved. It does lead me to question the quality control that goes on when these class libraries are designed, or perhaps written ( given that it's possible to write a method that does this and works ).
It almost makes me feel inspired to rave again about how terrible the implimention of the AudioVideoPlayback namespace in DX9 is.
Comments:
<< Home
Heh, yeah I just tested it and confirmed it. It does indeed appear this method is useless! Might be a good one to let MS know about over at MSDN feedback.
And yeah, I definitely agree regarding AudioVideoPlayback. What a horribly designed class. What it really comes down to is, MS seems to be in this limbo, where they've dropped support for DirectMusic, DirectSound, done half-hearted managed wrappers of those, and then expect developers to be able to get by with this ugly set. I think they're trying to quietly tie more people to Windows by forcing game developers to code audio using the Platform SDK. :-p I haven't looked too thoroughly at the WinFX SDK though, maybe they have some audio functionality in there.
And yeah, I definitely agree regarding AudioVideoPlayback. What a horribly designed class. What it really comes down to is, MS seems to be in this limbo, where they've dropped support for DirectMusic, DirectSound, done half-hearted managed wrappers of those, and then expect developers to be able to get by with this ugly set. I think they're trying to quietly tie more people to Windows by forcing game developers to code audio using the Platform SDK. :-p I haven't looked too thoroughly at the WinFX SDK though, maybe they have some audio functionality in there.
Hi Judah. According to my Managed DX book, which was written by one of the guys on the team, that namespace was provided for only the most basic functionality, essentially it's there so you can play video on a texture. But I tried to write a Jukebox app with it, and found that it just doesn't work, it's full of bugs. I am hoping they fix it, but I embedded with WMP as a control instead, which had it's own issues, but at least it worked.
Post a Comment
<< Home
