Possible Bug in DefaultCloseStrategy


From Marcel:

I think there’s a bug in the default closing strategy for a conductor. If I override CanClose in the conductor and call callback(true). The conductor closes even if the active item calls callback(false).

My understanding would be that the conductor and all active items have to say callback(true), before the conductor closes. If any, including the conductor itself says callback(false). It shouldn’t close, no?
Closed Sep 16, 2013 at 1:06 AM by EisenbergEffect
User error.


Charleh wrote Mar 13, 2013 at 1:02 PM

I've also found an obscure bug (might be to do with the way I am using it) but I have a conductor for a dialog stack (a Collection.OneActive with each successive dialog overlaying the previous)

I try to close the first dialog - this means the CanClose guard fires which opens a successive dialog (a confirmation one).

When the user clicks a button on the confirmation to signal they DO want to close the first dialog, obviously the dialog VM closes, then I fire the CanClose callback on the original dialog - it's at this point that the DefaultCloseStragegy hits me with a nullref exception

I've traced it down to the closable List in DefaultCloseStrategy:
            if (guard != null)
                guard.CanClose(canClose =>
                    if (canClose)
                        if (closable != null) // Added this null check as for some reason the collection is null when I do it in the way I described, this seems to fix the issue (I'm not exactly sure why the List is null...scratching my head a bit due to all the callbacks flying about!)

                    Evaluate(canClose, enumerator, callback);
when adding the null check everything appears to work ok - I've not run any of the included unit tests but in my application (which has plenty of CanClose implementations) this seems to fix the issue.

tibel wrote Sep 13, 2013 at 7:01 PM

When you override CanClose in the conductor and call callback(true); there is no issue in DefaultCloseStrategy as you have overridden the behavior.

When overiding CanClose() makre sure to call base.CanClose() if you want to have the default handling.
For me this seems more like an usage error than a CM issue...please correct me if you think different.