Material: Catch events on mdDialog

[no-more]

Hi,

This is not a bug, I was looking for a way to catch events on mddialog.

There's two main cases :

• Trigger a function on dialog close. I know show() returns a promise on which I can attach a function, but this have to be done in the caller function. I would like to be able to do the same from inside the dialog and I didn't find a simple way to do this. How can I catch the ESC keyboard event for example?
• The other reason and this is my main requirement currently, how can I prevent the dialog to close, in case of unsaved data for example ? I would like to be able to show a confirmation box before allowing the dialog close (or even the page and browser).

Thanks.

[no-more]

I just find out than $destroy event is generated but I still don't know how to prevent closing the dialog in case of unsaved changes.

Thanks.

[KReden]

If you haven't yet you should post this over on the forums https://groups.google.com/forum/#!forum/ngmaterial as you will probably get more answers there.

You might also try the angular forums seeing as this strikes me more of a general 'how can I do this in angular?' question. https://groups.google.com/forum/#!forum/angular

With that said I did a google search and came up with this stackoverflow post that looks like it could be what you are looking for: http://stackoverflow.com/questions/14852802/detect-unsaved-changes-and-alert-user-using-angularjs

Cheers mate

[no-more]

Hi, Thanks for the response, but I know how to catch event in angular, and I already managed them at page level. My question was specific to mdDialog, is there any specific way to catch closing event before it occurs. I can do it in the button when clicked, but how can I catch other events (ESC keyboard, or other $mddialog calls that will close the current one. I would like to be able to prevent the closing of the dialog if there's unsaved changes inside it.

I was also wondering, is there any way to know if a dialog is already opened ? and if it's possible can we get it's controller or scope ? I'm talking from outside of the dialog controller.

In the end I think $mddialog might be missing some tools functions (isOpen, getCurrentDialogController, ...) , or maybe it's only the docs that are not complete.

It's in another request I think but it would really be great to have stackable dialog too.

Thanks.

[gligoran]

I have a very similar problem. I'd like to prevent dialog closing while processing an ajax request. For example the user fills out the form on the dialog, clicks save and at that point I call my API, which takes a few moments. In that time I don't want the user to close the dialog or having the impression that clicking Cancel/Close button of the dialog will prevent the save to happen. Also ESC and click outside don't give me any notice before actually closing the dialog.

This could be solved by an event $onDialogClosing that I can intercept and say cancel closing or having the ability to change the esc and click-outside settings of the currently active dialog.

[ThomasBurleson]

One of our Angular Material best-practices is to encourage core team developers to avoid custom event dispatching within components. And while a callback would work, perhaps another solution is better:

How about using the md-is-locked-open expression?

• if the expression evaluates to true, then ESC, outside modal-clicks, and other close attempts will be ignored.
• if the expression evaluates to false, then the dialog responds to close as normal.

<md-dialog md-is-locked-open="isLockedOpen()">
  <form>
    <md-toolbar></md-toolbar>
    <md-dialog-content></md-dialog-content>
    <div class="md-actions" layout="row">
       <md-button md-autofocus> More on Wikipedia</md-button>
       <md-button ng-click="searchWiki('useful')" >Useful</md-button>
  </div>
  </form>
</md-dialog>

[gligoran]

@ThomasBurleson: That sounds like a great solution.

[tgeft]

I don't understand how the md-is-locked-open expression solves the problem of asking for confirmation before closing the dialog in case of unsaved changes. In such a case, I would not like prevent the dialog from closing but instead to be able to detect an attempt to close it in order to ask for confirmation. Keeping the dialog "locked open" might have its uses but I don't think that it would help for the scenario presented above.

[Duder-onomy]

+1 This will be useful to override the clickOutsideToClose and escapeToClose parameters.

I need to lock down the modal while doing some work, the user should not be allowed to close.

These options are super awesome, (used to doing this by hand) but i need a way to prevent them if a condition is met.

Thanks

[akhan-netfore]

+1 @tgeft
Need to detect that someone is trying to close the modal / dialog

[corelgott]

+1

[rienk-git]

I just found a solution (it has a little delay).

clickOutsideToClose and escape can be catched by using finally.

for instance:

        $mdDialog.show({
          templateUrl: 'templates/dialogs/sometemplate.html',
         clickOutsideToClose: true,
         scope: $scope.$new(),
         openFrom : "#someid",
         closeTo: "#someid"           
     }).finally(function() {
         console.log('I get called on escape and clickoutside');
     });

cheers,

[Aaike]

Why has this been deprecated ? is there a different way now to prevent closing of dialogs ?

[Duder-onomy]

@ThomasBurleson Any explanation for deprecation? Is there a proper way for us to handle this issue now?

[hasanfar]

@ThomasBurleson Any explanation for deprecation? Please point me to any available solution for this issue

[ThomasStubbe]

+1! I would like an onClose event in the controller of the mdDialog aswell...
I dislike the solution with the promise and finally: The responsibility should be in the controller of the mdDialog itself.

[IMM0rtalis]

+1 for preventing ESC or outside click or closing in generel if condition is not fullfilled

[ThomasBurleson]

This issue is closed as it falls in the 'deprecated' category. We deprecate issues for one or more of the following reasons:

• Issue has a reasonable workaround
• Issue doesn't have a demo or reproducible case available
• Issue is real, but fixing it is risky for users who depend on existing behavior
• Issue is real, but only affects a very small use case
• Issue is real, but would require significant work to fix, and is less urgent than other needs.

Pull Requests are welcomed to resolve this issue. But note that not all community PRs will be merged into master. Pull Requests with large changes or large scope impacts will probably be rejected [due to stability risks to existing users].