Bug 53921 - Assigning iCommand in VM is also executing the command, and shouldn't
Summary: Assigning iCommand in VM is also executing the command, and shouldn't
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.4
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2017-03-24 15:50 UTC by Clint
Modified: 2017-03-24 17:54 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Breakpoints hitting in VM screenshot (135.97 KB, image/png)
2017-03-24 15:50 UTC, Clint

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Clint 2017-03-24 15:50:40 UTC
Created attachment 20810 [details]
Breakpoints hitting in VM screenshot

We have a [Back] button for navigation in our full-screen app.
We want to make sure the user doesn't jackhammer it and cause multiple NavBack commands because the UI is slow to update and the [back] button remains visible even after being pressed the first time.

Attempted logic:
As soon as the NavBackCommand is executed it sets the command to null.
When a page is pushed, the OnAppear assigns the NavBackCommand a value again, basically making it legal/possible to execute the NavBack command

Here's the rub... Assigning the NavBack command a handler method is also EXECUTING the handler method.  It shouldn't do that.  Think of it like filling out a form... Just because I've entered all the required data and its legal to submit the form doesn't mean I want to automatically submit it: I just want to assign the command and have the buttom become enabled.

This issue doesn't seem to happen anywhere else in our app because the command assignments happen in the constructor of the ViewModel.  Why that makes a difference I'm not sure. Maybe the methods don't quite exist yet since the class is still being constructed.

But... if I nullify and assign commands from within methods in the ViewModel... the handlers are executed when the assignment is made.

        internal void NavPresent(ContentView view, bool allowBack = true, bool keepInHistory = true)
           //Logic for deciding which ContentView redacted for brevity

           //Once a view is assigned we say the navBackCommand has a value with a handler
            AppVM.navBackCommand = new Command(NavStepBack()); //So user can't hammer the back button

        internal Action<object> NavStepBack(bool rememberIndex = false)
            AppVM.navBackCommand = null;//Breakpoint hit immediately upon command assignment
            // trimmed for brevity
Comment 1 Clint 2017-03-24 17:54:10 UTC
Update... Looks like letting Visual Studio auto-complete through intellisense may have tripped me up.

It filled in
new Command(NavStepBack());
instead of
new Command(NavStepBack); //Notice the lack of method parenthesis

This seems to make the difference between the handler method "NavStepBack" getting executed when assigned to the iCommand - and not.  

In hindsight... It makes sense.  The method has to run in order to return a resulting object that is used as the target of the assignment.

So.... My goof.  One pair of easily overlooked () makes a world of difference.