Question

Curious if there are any disadvantages to using an ElementHost to host a WPF UserControl in a Winform application?

I ask because in general I feel that it takes to much time for me create a new WPF application with a basic interface that looks decent. Decent in the sense that if I create a new Winforms application and throw some controls on it I end up with a basic interface that looks and behaves similar to many other applications but doesn’t look plain. If I do the same thing with a WPF application I don’t feel I achieve the same results, I end up with a “plain” application with a white background unless I change roles to designer and spend extra time to make it look a certain way.

However there are cases where WPF is desirable to me for it’s relative ease of creating a stylized interface. Consider a video player control; in WPF I can create something that looks very nice and custom but took much less time and effort than a Winforms control. In these cases it makes sense for me to use WPF since I end up spending less time than I would have overiding OnPaint :-).

I realize I’m using a lot of subjective terms but this is my reasoning behind the original question.

Update:

Just to clarify my “video player control” example. Not only does WPF give me the MediaElement to play with but if I want to say, overlay a Play button on the video when it is paused or if I wanted a semi-transparent “play/pause/stop/volume” bar to show up when the mouse in in a certain location, WPF makes that much simpler than any Winforms alternative.

Edit:

Maybe I have a configuration option wrong or something but it’s also frustrating the the “Description” section disappears when I am looking at a WPF vs. Winforms Control. Even more frustrating that pressing F1 in a WPF property form doesn’t take you to the specific property/event you were on.

Update:

Any one else? I’m more concerned about performance impacts and/or feature limitations that would be introduced by hosting the WPF UserControl in an ElementHost. So far it sounds like there is the onetime overhead of the runtime but is that all?

Answer 1

I see a few potential disadvantages.

First, you now have two ways of displaying UI. This can present issues from a maintenance point of view depending the developers touching the code.

Second, WPF does have a runtime associated with it (for dispatching events, dependency property management, etc, etc), but it’s a one-time cost. If you are using that for a small number of controls, then you are paying a relatively large cost in proportion to it’s usage.

I wouldn’t say these are deal-breakers, it’s all dependent on your app and your team.