Closed pape87 closed 6 years ago
.ok()
/.cancel()
if the VM implements .canDeactivate
, that hook will be called with a DialogCloseResult
. So you can see what intention it is being closed with, and prevent the closing if needed by returning false
.Renderer
implementation. And yes some Renderer
options are mixed in the general ones, this has been since day one.Oh my!! and it is referenced in the docs http://aurelia.io/docs/plugins/dialog#lifecycle-hooks
never knew
Now that I think about it, both canDeactivate
and deactivate
hooks are called with DialogCloseResult
. So you can manipulate the .output
field - ~definitely~probably not intended and feels like a hack but it is doable, since we are not freezing the result object(don't think we'll do it).
@pape87 do you think this satisfies you?
Yes this solved my issue. I've added some info to the docs about the canDeactivate result parameter.
Thank you
@pape87 take a look at this comment about interfaces available for dialog vm https://github.com/aurelia/framework/issues/874#issuecomment-374203146
@pape87 thanks for your help with docs (-:
I'm submitting a feature request
Current behavior: When settings.keyboard is configured to respect keyboard events, upon pressing the key (Enter or Escape), only controller.ok()/controller.cancel() are called respectively. There is no opportunity to verify or pass a result.
Expected/desired behavior: Introduce two new life-cycle hooks to the dialog VM like this: