HELP - with X# syntax - Relay Command ...

[wriedmann]

Hi Phil,

me again: MVVM purists would say that you should never call a MessageBox.Show() from a ViewModel.

In my test application I have a central locator class where the view registers itself, and the ViewModel sends the message through the locator:

Code: Select all

method DisplayMessageBox( cCaption as string, cMessage as string ) as System.Windows.MessageBoxResult
  local oMessageDisplay as IMessageDisplay
  local oResult as System.Windows.MessageBoxResult
	
  oMessageDisplay := self:MessageDisplay
  if oMessageDisplay != null
    oResult := oMessageDisplay:DisplayMessageBox( cCaption, cMessage )
  else
    oResult := System.Windows.MessageBoxResult.OK
  endif
	
  return oResult

property MessageDisplay as IMessageDisplay
  get 
    var oMessageDisplay := ServiceContainer.GetInstance():GetService<IMessageDisplay>()
    if oMessageDisplay == null
      Debug.WriteLine( "no IMessageDisplay registered!" )
    endif 
    return oMessageDisplay
  end get
end property

My code is very far from being perfect, and I suspect people like Nick would have much more to say, but I try to do things the best way I'm able to.

Wolfgang

[NickFriend]

Hi Phil,

You could also do your property like this...

Code: Select all

private _doTestCommand as ICommand
property DoTestCommand as ICommand
   get
      if _doTestCommand == null
         _doTestCommand := RelayCommand{Action<Object>{ self, @DoTest() }, null}
      endif
      return _doTestCommand
   end get
end property

With this pattern you don't need a setter, and you don't have to manually create the RelayCommand in your initialisation code.

It's still a fair bit of code, and when you have several commands it starts to add up, so I must admit that in my more recent code I now do this (not sure how auto getters and setters are working in X#, so this is in C#)...

Code: Select all

private override void InitialiseCommands()
{
   DoTestCommand = new RelayCommand(DoTest);
}
public ICommand DoTestCommand {get; private set;}

InitialiseCommands is called automatically in my ViewModelBase class.

Nick

[Frank Maraite]

Hi Phil,

you're saying you have it decoupled. But I see calling messageBox from ViewModel. This implies that you have a reference from your VM app to the PresentationFramework.dll. Is this right? Then you are wrong. That makes your VM dependend from the GUI system.

I avoid RelayCommand and RoutedEvent.

I trigger a method that sends out a message 'This butten is clicked' or whatever. Some module in your app can react on this. Your view should not know about that. With intelligent binding to IsEnabled you can achieve the same what a command does with CanExecute.

Then you make me happy .

Frank

PS: See my example from cologne last year.

[NickFriend]

Come on guys, lighten up, Phil's only put the message box in there so the method does something visible to show it's working!!

Frank, what's wrong with RelayCommand?... does just what's needed, send a notification from the UI to a ViewModel.

Nick

[Frank Maraite]

Hi Nick,

nothing other than I don't like it . Maybe I didn't understood it when I began working on V / VM . Then I found the trigger way, and it worked.

And of course it is only a small example app it does not matter using a messagebox there. In general I would not do it. I think Phil does understand me comments.

Cheers
Frank

[Phil Hepburn]

Quite right Nick,

Lets steady down a bit ........

And just before I went to pay a visit to the dentist ;-0((

Anyway, now I have returned home and done a little more work on the 'ViewModel' we can have all our messages, not in a dialog box, but in a public property on the VM called 'Messages'. This way we don't hog or grab control away from the WPF form thread, and also it is so easy to do with data binding.

Also, remember I am a teacher, and designing stuff for possible conference new guys to a lot of stuff like LINQ, EF6, WPF/XAML, the list goes on - AND SO - I must make my demo apps as correct as possible, but also as simple to follow as possible.

And remember - there is no right way as everyone keeps saying !! Possibly just 'better ways'.

Nick, the 'RelayCommand' example I am following is a standard one from C# Corner. I will look at the changes you suggest for my own use after Cologne, but what is working now seems just fine to me for the purpose.

Also the point of this code for RC is that I then don't need employ an MVVM framework, which is good for newbies to some or all of this stuff.

Here are a few small images to show what I have done, post dentist :-

PearlsBoundMessages_41.jpg (56.57 KiB) Viewed 442 times

PearlsBoundMessages_42.jpg (87.08 KiB) Viewed 442 times

PearlsBoundMessages_43.jpg (89.48 KiB) Viewed 442 times

PearlsBoundMessages_44.jpg (18.36 KiB) Viewed 442 times

PearlsBoundMessages_45.jpg (23.78 KiB) Viewed 442 times

PearlsBoundMessages_46.jpg (27.66 KiB) Viewed 442 times

PearlsBoundMessages_47.jpg (40.73 KiB) Viewed 442 times

Regards to all, and MANY thanks for your suggestions, keep them coming ;-0)
Phil.

[Phil Hepburn]

Thanks Wolfgang,

I will try to apply this later with my Add-New and Save stuff.

I did use it some time ago for session material for Cologne, last year? the year before that ??

If I hit any snags / issues I will come back to you.

Cheers,
Phil.

OOO! Pain killer from the dentist is starting to ware off !!!

[wriedmann]

Hi Phil,

you are welcome!

As you I don't use any external references in my samples, so anyone can use them without problems.
And since I use XIDE for programming, I can create single application export files that make it very easy to import them and delete them when not needed anymore.

Wolfgang

[Phil Hepburn]

Good morning Wolfgang, and all,

What I am about to say was on the top of my head the other day, before I visited the dentist, but did not have time to say it or write it.

As .NET coders / designers we must embrace the world of .NET completely, not just the bits we fancy or like, ignoring the bits we dislike. Particularly if we have a teaching role.

Since 'Frameworks' are quite a big part of .NET then we have to use then sometimes, in the appropriate places, I feel. Personally, I can't do the Entity work without using the EF6 Framework from Microsoft. And there are other examples as well.

There are a couple of points about 'Frameworks' as I can see things, one is why employ a Framework when the task to solve is a small one ? A bit like my use of 'RelayCommand' just to move the Button click event code into the ViewModel? When I can code a class to do this and use it, quite easily?

The other (to my mind) is where does the Framework come from. Who made it, who maintains it? I personally feel less keen on using assemblies created by individuals or small teams, than I do about using Microsoft supported Frameworks.

So if I was to design and create a full blown MVVM app then I am much more likely to try and use Prism (from MS) than the Galasoft MVVMlight, even though I have used this one successfully in the past.

Just my 2 cents worth on a warmish Sunday morning here in Newport. My thoughts on XAML with WPF will be posted in a separate post ;-0)

Best regards,
Phil.
Wales, UK.

[wriedmann]

Hi Phil,

since I have not a teaching role (even if I think I should contribute my code to the guys who need it), I'm a bit more pragmatic about the use of frameworks.

First of all, I have to maintain my software for at least 15 or 20 years (ok, in 20 years I will be 73 years old - but someone other in my company should be able to maintain my code).
Therefore I have to take much more caution when selecting a framework or even 3rd party lib.

Often it is better to not use a 3rd party lib, but write (and understand!) the code itself. Frameworks often have a lot of functionality I don't need and make it harder to understand and maintain code - and since code readability and maintenability is a top priority for me this is another point why I prefer to write code of my own.

But of course it is very important to look at frameworks (and others applications) to see good and bad ideas.....

Of course writing own code is harder and takes more time, but in the long run it is better, I think - at least for me and my small company.
And sometimes it is better to decide things that seem strange to other - specially for us that whe come from VO and heave learned to be more disciplinated when coding than most other programmers (name based data binding in VO was a great thing - and forced us to think about naming instead of binding "Edit1" to the "CustName" field and "Edit2" to the "Address" field like many Delphi and VB programmers have done).

Wolfgang