views:

60

answers:

1

I am just getting into the Silverlight world, and wish I didn't learn WPF first so I wouldn't be so frustrated with the little things that are missing.

In WPF I was using commands (RoutedUICommand) for my view/UI to handle "events" (by event I mean something the user did) and passing them to the viewmodel.

Now in silverlight I find that I can't do it that way and on top of that there doesn't seem to be a consensus. I dislike putting code in my codebehind for my views but I keep finding myself having to do so, unless I am willing to subclass damn near every usercontrol I use. Or write a million lines of xaml for a one line codebehind statement.

And even then, I don't konw If I should use events, commands, or what seems like the best fit for me the LocalMessageSender/LocalMessageReceiver.

bottom line, is there a generally accepted approach for what must be a very common situation: telling the viewmodel what the user did?

Oh im using SL 4 if that matters.

+1  A: 

is there a generally accepted approach for what must be a very common situation: telling the viewmodel what the user did?

Yes its called binding.

When it comes to button clicks in Silverlight 4 you should be looking at exposing a property on your ViewModel that has the type ICommand, you can then use a standard Binding on things like Button Command property.

AnthonyWJones
Thanks,That is what I was afraid of:here is the problem when I took that approach.Say the button was inside a listbox, the button click worked fine and the command fired correctly, but it intercepted the click so the item would not get selected in the list. also I have a ton of controls that are basically geometries that act like buttons and I need to respond to clicks ....damn my brain is stuck in WPF world. Guess there goes code reuse unless I think up a clever subclassing/or attached property scheme
Dimestore Cowboy