CODEWITHSUNDEEP
c#wpf
Mathias Lykkegaard Lorenzen
Mathias Lykkegaard Lorenzen

Reputation: 15886

Design time events in WPF?

I am using Autofac with my WPF project.

At design time for some controls, I set the data context of these controls to a designer-specific view model. This view model then injects some services in through its constructor.

That's all fine. But how can I manage lifetime scoping for this? Is there any way to hook up to an event and dispose my Autofac container when the design-time phase is done?

Upvotes: 1

Views: 757

Answers (1)

quetzalcoatl
quetzalcoatl

Reputation: 33506

You've said in comments:

The problem is that some of my services (for instance a hotkey service) is using the RegisterHotkey API. For that service, it's important that it is unregistered when Visual Studio is done rendering my design.

In general, those should not even get registered first when your component is in DesignTime. Designtime if for previewing the layout and inspecting view modes/states, not really for testing (though it's very tempting sometimes).

When in designtime, all interactivity of the component should be disabled. VisualStudio tries to do that, you will notice that many interactivity events/triggers are not invoked or passed to your component. However, it sometimes fails badly at this, like in case of Popups (and therefore Dropdowns, Comboboxes, etc) you can sometimes force to actually open in design-time and it yields very strange/unstable/otsafe results.

This is why you shouldn't fully trust VS and the design-time mode to "just work". You probably already know well that poorly written component can, in desing-mode, try for example to connect to a database. It shouldn't happen. Usually.

I'd say, refactor that hotkey-registering bits out into some service and stub/nullify/disable it when you detect designtime mode.

I doubt they worked in designtime, but if you needed these hotkeys to flip some switches in VM on and off, or to invoke some behavior, bind that switches or behavior to a few new properties, and instead of pressing hotkeys, set them in the designer or by designtimedata to check the effect.

Just FYI - I never researched this for WPF/XAML, but for WinForms, each component could come with a special "designer" component. VisualStudio used that 'designer' component for preparing, mantaining, rendering, editing and serializing the edited component. You could actually write a designer for your custom control, and that designer could display extra windows with custom editors, and so on. Toolkits like DevExpress heavily relied on that. I'm not sure if that there is a similar framework for XAML components. I doubt it's the same, but there may be some similar concepts kept. Anyways, I wouldn't dig into this on your place, not for such things. It's not worth it unless you really want to start extending the Designer with your custom plugins.

Upvotes: 1

Related Questions