CODEWITHSUNDEEP
c#wpfmodal-dialogcaliburn.micro
Christian Sauer
Christian Sauer

Reputation: 10889

Caliburn.Micro locking the main view

I am currently launching a rather lengthy operation from my main view. While this operation continues, it should be impossible to press any button on the main View. Furthermore, the progress should be reported in another Window. I could update every CanXXX Guard properties, but that would be tons of code.

I would like to use the ShowDialog Method of Caliburn.Micro, but this methods waits until the Window returns with a return value. So how can I show a modal Window with Caliburn.Micro which does not wait for some dialog to return ?

Upvotes: 0

Views: 425

Answers (2)

Charleh
Charleh

Reputation: 14012

I've done this in the past...

In your main/shell view -

<ContentControl IsEnabled="{Binding UILocked, Converter={StaticResource BooleanInverter}}">
    <SomeOtherControls..... blah blah />
</ContentControl>

In the main/shell viewmodel -

public bool UILocked { get { // getter } set { // prop changed code/setter etc... } }

Upon setting UILocked to true the whole UI should be disabled. ContentControl will disable all child elements and IsEnabled bindings for its children will be ignored

You can ensure that the main view subscribes to the event aggregator too:

public class MainViewModel : IHandle<ChangeUIStateMessage>
{
    public bool UILocked { get { // getter } set { // prop changed code/setter etc... } }

    public MainViewModel(IEventAggregator aggregator)
    {
        aggregator.Subscribe(this);
    }

    public void Handle(ChangeUIStateMessage message)
    {
        UILocked = message.UILocked;
    }
}

The message class may be as simple as:

public class ChangeUIStateMessage
{
    public bool UILocked { get; private set; }

    public ChangeUIStateMessage(bool uiLocked)
    {
        UILocked = uiLocked;
    }
}

Then you can just fire this via the aggregator from any VM to lock/unlock the UI

aggregator.Publish(new ChangeUIStateMessage(true));

If needed you can also modify the handler so that a list of objects that have initiated a lock is maintained, ensuring the UI is locked until all workers have finished (in case multiple VMs kick off a lock/unlock operation simultaneously)

Edit: Forgot to add - if your popup controls are in a separate visual tree (as popups usually are) they will not be disabled which most of the time works to your advantage (interactive popups/locked app).

Upvotes: 2

devdigital
devdigital

Reputation: 34349

You might want to consider the BusyIndicator provided with the Extended WPF Toolkit.

Upvotes: 1

Related Questions