the WinFX API reviews continue… Tomorrow: System.Windows.Controls

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">At the PDC JimAll mentioned we are
doing painstaking API reviews of all of WinFX… Tomorrow we are doing our
*3rd* round on href="">System.Windows.Controls
(I am reviewing something slightly more up to date)…. I will let you know if
anything fun comes out of it, but if you have comments of your own… let me know
before 10a Seattle time.

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Remember, if you don’t speak up now,
don’t complain later. 

Comments (11)

  1. Roman says:

    It will be good, if common (base) controls will have screenshots (like "Button" – how it looks focused, pressed, disabled, etc.)

  2. Mads Houmann says:

    My main gripe: Don’t pollute WinFX with any more ‘home rolled’ strongly typed collections.
    For instance: VisualCollection, or ContactPropertyRequestCollection (phew)
    should be replaced with
    List<Visual> and List<ContactProperty> respectivly.
    or possibly:
    VisualCollection : List<Visual>, although I prefer the former.

  3. Nicole Calinoiu says:

    Given the time constraints, I started with a quick look at the Control class. I found enough potential problems that I pretty much stopped there too. <gdr> I’m guessing that compatibility/familiarity concerns may be driving some of the design decisions. However, if this isn’t actually the case, here’s some of what strikes me as potentially problematic on first glance:

    1. Very long member list (see discussion from microsoft.public.dotnet.languages.csharp newsgroup at For example, couldn’t the various border configuration, font, dimension, and mouse/keyboard handler members be bundled into separate objects accessible via properties of the the Control class? Besides addressing the member list length issue, this should provide for greater ease of extensibility of the framework itself and also facilitate the development of new controls (since interdependent member sets could be added/removed as a unit).

    2. Some properties have names that sound an awful lot like actions (e.g.: Clip, ClipToBounds, ForwardCommandsTo, RenderBounds).

    3. At least one method that looks like it should probably be a property (CanHandleAccessKeys).

    I took a quick glance at some of the other classes, and found similar issues in many. I also tried to look at the overall structure of the namespace, but that’s a wee bit difficult given the format of the documentation. However, one design choice that struck me as rather odd is the inclusion of the various Contact_____ classes in the MSAvalon.Windows.Controls namespace. Why not give them a namespace of their own? This would make it easier for developers to find what they need wrt both the "general" control classes and the less familiar contacts classes. It would also provide for a cleaner namespace hierarchy in case other specialized control sets are added at some time in the future.

  4. Brad Abrams says:

    Rob Relyea just told me this review is not untill Thursday, so you have a little more time..

  5. Mads Houmann says:

    And how about producing some UML diagrams, to provide newcomers with a chance of getting an overview, without spending months just getting to know one corner of WinFX, such as Avalon. I find that inheritance – as well as structural diagrams are often a good way to gauge the complexity of a design.

    After all, it’s not just the naming that counts…

  6. Sam says:

    Mads: hell no don’t add any generics for collections. Generics are a complete geek thing and the API is already hard enough. Furthermore, you can’t use a generic list class all the time since there is often more to a list. . Writing tools becomes a lot harder. Don’t use templates for system APIs.

  7. Mads Houmann says:

    Sam, with regards to generic collections:
    If the second option is used, e.g.

    class VisualCollection : List<Visual>

    you could use the collection just like it is now, and be none the wiser.

    The methods for VisualCollection would still be something like:

    public void Add(Visual v);
    public Visual this[int index];

    i.e., type safe and efficient, but without the (MS) developer having to write (or generate) custom collection classes.

    You can’t tell me that is hard – or geeky for that matter. 😉

  8. Keith Patrick says:

    Mads, why not still use the home rolled collections, but with a generic implementation (you seem to be advocating a bit with VisualCollection)? That’s actually what I am doing now: I have a bunch of typed collections (that subclass off a single implementation with some tricks to hide the methods taking/returning Object while still implementing the interfaces) that work just like the Controls ones, but my intent was abstracting it enough to change to a generic implementation once available. Going that route, there is a true black box implementation.

  9. Brad Abrams says:

    Another one I got in email:
    The current .net framework has rather poor support for parsing/formatting data from and to the target control. You have to override the OnParse and OnFormat method of the Binding class (similar to IDataTransformer InverseTransform and Transform). What is lacking currently (and I wondering about Avalon), is that when you encounter invalid data in the target control (e.g. you are parsing a number in a text property of a text box and it does not meet a certain validation rule you want to apply), there is no good way to throw an error and prevent further updates (until the user has corrected the data). Just throwing an exception would be one way, but, at least the Binding class in 1.1, just eats the exception and ‘gracefully’ continues updating the datasource. In the 1.1.-space we’ve ended up creating a custom BindingContext, and collect error information for ech binding in there, and then report to the user when the current edit is endend (overriding using an out-of-bound mechanism (that is after ending the current edit / applying the bindings, throw the excpetion).

  10. Mad Houmann says:

    Keith, we might be getting off topic here, and I’m not sure I understand your question, but I think I agree with you ;).

    For the MS developers, who already have accces to the generic collection classes, I think there is no question that they should use them. One big advantage to my mind, is that List<T> implements IList<T> so I can use generic algorithms (taking IList<T> arguments) on the different collections in the framework. And I would VERY much like to be able to do that – no matter how geeky that might seem to some people.

    The rest of us can do as you suggest, and change over once Whidbey is released. We’ll probably need to recompile though.

  11. Keith Patrick says:

    Mad: I’m only suggesting aliasing the collection as a classname, such that whether it’s a generic or not is hidden from the user. The way WinForms is right now, it’s prepared for that (not sure if MS is going that route) so that if they decide, for future maintenance’s sake, to switch over to a generics implementation would not break anyone’s consuming code. I guess that could explain why every specialized collection in there subclasses from Object rather than some AbstractSpecializedCollection class to reuse the guts of the collection code.

Skip to main content