This post originated from an RSS feed registered with .NET Buzz
by Eric Gunnerson.
Original Post: More on DirectShow and C#
Feed Title: Eric Gunnerson's C# Compendium
Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx
Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles
To respond to a few of the comments on my first post
One person asked whether MM would be rewritten to use the media foundation classes in LH. I'm not really the right person to comment on that - that would seem to be a marketing function. In the C# team, I did some quasi-marketing stuff and knew what I could talk about and not talk about, but I'm not there yet here, and my initial read is that the Windows division has a different bar than the developer division on such things.
On the question about my use of generic methods - yes, I could have just use a normal method, and for my use, there's not much reason to prefer one over the other, though there could be cases where using Activator.CreateInstance<T> was preferable. But in general, I prefer the type to come out of the function rather than having to coerce it in my code, and I think CreateComObject<X> is a bit more readable.
On DirectShow.NET - yes, I know of its existence, and it's possible that I could get permission to use it, but in this case, writing my own is easier than getting permission. Also, the whole point was for me to spend some time writing code, and having me write it all furthered that goal. I have no idea what the DirectShow team plans in the longer term - you'd have to take it up with them.
Finally, on the subject of getting "dirty" results out of IDL->MIDL->TLBIMP->Assembly, is is true that it is some COM interfaces can be fully expressed in C#, but there are some interfaces that can't. I might consider converting them to C# definitions in the future, but there isn't necessarily much reason to do so.
Previous Topic
