public override bool CanExecute(object parameter) in DelegateCommand and public virtual bool CanExecute(object parameter) => true; in CommandBase have fixed the red squigglies.
@Hosch250 This is needed because as a DelegateCommand the field property RefreshCommand needs to have something be put-into-it/assigned like how an event handler subscribes to an event?
Ok. I see that nothing happens when text is entered into the TextBox. I pretty much get that the button is doing the update now but don't really understand how.
public DelegateCommand RefreshCommand { get; } grabs what it was assigned as RefreshCommand = new DelegateCommand(Refresh); when the VM was initialized.
OnPropertyChanged(nameof(Text)) which was the original is just feeding in the name of the Text Property into OnPropertyChanged causing whatever is bound to it to be alerted by the event that's raised to update?
I may get something at a high level, but I don't feel good about it till I can use it almost effortlessly.
The button has the command bound to it through Binding RefreshCommand. RefreshCommand has the private void Refresh(object obj) { OnPropertyChanged(nameof(Text)); } assigned to it initially. But the argument isn't being used why is it there?
> #2497 API changed: -> repository.commit() now mandates 'author' and 'commiter' as two distinct parameters. I pass into both the same value by default. -> repository.Stage() passes to the static class 'Commands' taking the repo as a first parameters. -> repository.Pull() undergoes the same change -> repository.Checkout() also -> repository.Remove() also -> repository.Fetch() takes the biggest changes. -It now requires by default a refSpec. As we will usually fetch everything, I hardcoded on...
the code the classic "+refs/heads/*:refs/remotes/origin/*". -It also requires a logMessage, which I hardoced empty ("") -> repository.Branches[branch].Remote changes as well. Now this collection moves to the .Network class member of the repository, as repo.Network.Remotes[branch] Changes to be committed: modified: RetailCoder.VBE/Rubberduck.csproj modified: RetailCoder.VBE/packages.config modified: Rubberduck.SourceControl/GitProvider.cs modified:...
Rubberduck.SourceControl/Rubberduck.SourceControl.csproj new file: Rubberduck.SourceControl/_SourceControlClassDiagram.cd modified: Rubberduck.SourceControl/packages.config modified: RubberduckTests/RubberduckTests.csproj Yeah, sorry for the ClassDiagram. But it's really helping me visualise the whole structure of the project
> So I've just sent you my changes on a pull request. Just a bunch of API differences. To be honest I find the repo.command(parameters) more intuitive than the command(repo,parameters). I'm acting on my repo object actually. But that's basically the main change from the guys at libgit.
Hosch, I just belatedly realized something - we have this: public sealed partial class ReorderParametersDialog : Form, IRefactoringDialog<ReorderParametersViewModel> -- very good. But then we have those.... public ReorderParametersViewModel ViewModel { get; } and public ReorderParametersDialog(ReorderParametersViewModel vm)... shouldn't those be made generic so that we don't have to define the presenter for each dialog?
seems to me we only need one presenter class for all dialogs, since winforms should be really dumb.
Ah. So when you click the button you are Executeing the command. By traipsing back to the source is Refresh(object obj) which is mandated becauseExecute(object parameter). :lightbulb:
I think I've understood why now.
Confirmed it with CommandParameter="Doesn't Matter" and stepping through to private void Refresh(object obj) { OnPropertyChanged(nameof(Text)); }.
@Hosch250 Thank you, a lot. For taking the time to inform me about this. I'd be in a world of hurt if I tried to fly solo and learn this.
I have a side question regarding DelegateCommand.CanExecute. Is this method invoked every time a command is shown? I had a breakpoint set and I'd see it is checked, twice, before the main window is shown. Once the window popped up in F5 mode it'd enter into an infinite loop of checking. Why?
I hypo-the-size that when VS gets focus and runs through the check and the focus is sent back to the window the CanExecute fires causing the loop. Is this so a command can't be run in an invalid state?