WPF using the "Data Sources Window" RRS feed

  • Question

  • Hi,

    From the CTP, it seems the designer support for WPF data binding is based on the same old Data Sources Window used for WinForms. drag-and-drop data binding is an incredibly useful feature, but the Data Sources Window has some annoying limitations that make it very hard to use effectively in a real world application.

    Since WPF came along a few years ago, I figured it was hopeless to try to get these limitations addressed because Microsoft is not going to invest heavily in the old WinForms. Now that WPF uses the same window, any chance of improving the Data Sources Window for the VS2010 release?

    Some examples of missing extensibility options-
    • An ability to filter what is displayed in the data tree itself. For example, if all our business object have "Min" and "Max" property, I'd like to be able to let the tree ignore these.
    • An ability to capture the drag and drop operation from the tree, get the full path to the key that was dragged, and let me handle creating the controls instead of the built-in mechanism. This will be useful in order to create multiple custom controls, do post processing to "patch up" some properties to be suitable for our application, or just about anything else we'll need.
    • Ability to attach custom controls to specific types of enums. For example, attach a specific "OnOffEnum" to a specific custom control, instead of just mapping all enums to the same.
    Saturday, November 8, 2008 4:31 PM

All replies

  • Hi Orion5,
    Thank you very much for your feedback. The Data Sources Window is very much alive :) and we definitely want to improve it.

    I have logged your suggestions and the respecive teams will review them for possible inclusion. Although I can't quite say which, if any will be added to VS2010.

    I do have a question about one of your suggestions.

    >An ability to capture the drag and drop operation from the tree...
    Can you give me an example of what you might do in the 'post processing' step?


    Milind Lele
    Program Manager
    Visual Studio
    Thursday, November 13, 2008 2:24 PM
  • Hi, thank you for your interest!

    It would be great if a design-time event would occur on every drag-and-drop operation from the data tree. This event should give us as input:

    • The path of the key.
    • Type of the object represented by the key.
    • The default control that would be created, already initialized.

    By handling this event, we can tell the IDE to create one or more controls, instead of the default behavior. Therefore, the output will be a list of controls to create. It will also give us the ability to change the binding path (perhaps by simply returning a new bound control).

    Some examples of using this:

    • Representing a TimeSpan as several text boxes. We could create a User Control instead, but sometimes it is desirable to drop the controls straight on the form without being locked up in a user control. For example to allow the user to move\delete some of the text boxes, or to have the text boxes blend in with the layout of the form.
    • Patching up properties – suppose in our application each data bound control supports multiple views of the same data. It's useful to be able to set the desired view (a property of the control) based on some state in the IDE.
    • Patching up properties to work around unwanted behavior of the data binding mechanism. I've worked with WinForms data binding and had to implement several hacks to the same effect. Hopefully WPF data binding is more flexible, but I guess there will always be places where custom workarounds will be necessary.


    And a few more ideas of capabilities that would make Data Sources Window truly useful:

    1. In the data UI customization window (that allows assigning user controls to some types), only built-in types are shown, and all other types are grouped as "Other". This is not very useful, because if we have several custom types, we need each of them to be associated with different controls. For instance an IPAddress type might be associated with an IPAddressControl. Instead, the best we can do is to have everything associated with "Other", overwhelming our users with irrelevant choices.

    One way to add this capability might be to allow adding specific custom types to the UI Customization window.

    Another way would be to export a delegate in the IDE called "GetApplicableControlsForObject", getting again the key and the object type, and returning a list of Types of controls that will be displayed to the user.


    2. We'd like to be able to fully control the display of nodes in the tree. Something similar to Virtual Mode that pops up an event asking us how to draw each node. This will give us the ability to add application-specific options to each node. For example, give the user a choice of a custom "view" for the created control, like the one I mentioned above. It would fit in nicely with the ability to intercept the drop operation, because then the user could choose a view straight from the data sources window, and we'll apply the choice in the drop event.


    With good extensibility, the Data Sources Window would be a killer feature for us. It's a little difficult to give good examples without digging into application-specific logic, so I hope the explanation is clear enough.  Let me know if I can elaborate any further.

    Saturday, November 29, 2008 3:41 PM