|
Which is best website to learn sliver light step by step for new developer?
|
|
|
|
|
There is no one such site - infact there would be multiple sites / tutorials that could help you get started.
http://www.silverlight.net/learn[^] could be one of the better ones.
You might also want to read about Silverlight from a book - nothing like reading a book to help you get started.
|
|
|
|
|
What would be your idea on using MVVM in a master-details project, where the details show on a different window?
|
|
|
|
|
I don't see any problem - let both the master and the detail - have separate views and view models that act as controller for these views.
|
|
|
|
|
The question is a little fuzzy. do you mean the Views as in the ASP master page? In which case we have main page that has the masterpage type info on it and a navigation frame. Each navigatedto view has a VM supporting it.
OR
Do you mean the data Master/Details structure, for this it is exactly like our old winforms, details at the top, gridview of child records and click through to the details of the child.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Yeap, I recognize fussiness!!! What I mean is, kindda, close to the first. Namely, dialogs. But I didn't want to say that word because the obvious answer would be something like "IDialogService" which, to me, is still terra incognita - I don't consider myself stupid but, whatever I do, I just can't get my head around the concept!!!
What I've tried so far is this:
The main view holds a ListView with all the records - bound to an ObservableCollection. Adding is done with a button that pops up a details dialog with an OK and a Cancel. Editing is done in a similar way. But, while adding works fine, editing doesn't. In editing, when I change the data, the ListItem behind is updated in real time, and the OK button seems non-responsive. What I want is the ListView item to be updated onlywhenthe OK button is pressed.
|
|
|
|
|
I always have a list and a selectedobject in my VM, the selected object is used to service the dialog. I use the same VM to service both the list and the dialog.
You need to implement IEditableObject on your model, this basically takes a copy of the object when you BeginEdit and either throws away the copy if you save or copies it back to the original if you cancel.
When the content of a field changes then I set the IsDataChanged and bind that to the Save button
I don't use a dialog service, I also do not do TDD so I don;t have to be pedantic in the MVVM design. I stick my dialog initiator in the code behind.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I've never used IEditableObject and I don't know what to do with it! Could you give an example?
And someone would be so kind to me to explain why, when I add an item, the dialog works fine but, when I edit, hell breaks loose?
modified 12-Mar-12 8:51am.
|
|
|
|
|
To further Mycroft's answer, you might find the helper functionality I wrote about here[^] to be of some use.
|
|
|
|
|
I have a mediaelemnt playing a wmv file. Clicking on the media element I capture and store the corresponding time positions of the wmv playing file.
I then would like to create a new wmv file by merging small pieces of the original wmv file (just few seconds) starting from each time position saved.
I would like to know how to do it. Any suggestions?
A second question is: can I create a wmv file showing a single image for few seconds?
Thanks.
|
|
|
|
|
Hello,
I am using Expender.
I need to assign USerControl (written in another file) to expander's headerTemplate in code.
How can i do it?
|
|
|
|
|
Using a template like below might help you out.
<toolkit:Expander x:Name="ExpanderControl" ExpandDirection="Down" IsExpanded="True" >
<toolkit:Expander.HeaderTemplate>
<DataTemplate>
<UserControl myContrl />
</DataTemplate>
</toolkit:Expander.HeaderTemplate>
</toolkit:Expander>
|
|
|
|
|
A coworker and I were discussion the design for a WPF app. It's being built using MVVM.
We have a series of user control that are going to be added to the main window at runtime. The user controls to be added are determined by the data coming back from the repository. So for model A, add user control A, type B, add user control B, and so on. The main window's VM would call into the repository, get back a collection of models, and then for each mode, determine which user control to add to the grid in the main window.
He was adamant that the VM "should not know anything about views because this breaks the MVVM pattern." He insisted that you can do all this through data templates. he also suggested that I read up on MVVM and I'll see this is true. Now I'v read lots of MVVM artiicles and Josh Smith's book, and blogs galore. I have never hear this notion that the VM can't know about views (add views at runtime).
If you're going to add controls at runtime, then the main window VM is going to need to know about the views. I am working on another WPF app that has a toolbox and design surface (canvas). The user will be able to drag & drop controls off the toolbox onto the design surface. I don't see how this could be templated, and I'm pretty sure that there's no way to do this without the main window VM adding the controls to the main window view.
I'm open to opinions. Documentation would be good.
Everything makes sense in someone's mind
|
|
|
|
|
Opinion only I'm afraid, I'm not as well read as you but from what I can glean he is right although I am wary of being adamant, I prefer a little flexibility.
I would think you would have place holders of some description in the view that are bound back to a set of properties in the VM, the VM sets the properties according to the suppository.
I have gone as far as having all the controls in the view and just fiddling with the visibility of the container element. Note this is always limited to 2 or 3 controls.
How you would do this with templates I do not know.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Yes good point.
Visibility, can however, be controlled via binding.
Other items like collapsing an Accordion just do not work using binding and I have not found a decent way to implement this without accessing view controls in the view model.
|
|
|
|
|
|
This all assumes that you know the controls ahead of time. If the controls being added are determined by the user, then there is no way to do this without the VM adding views.
Everything makes sense in someone's mind
|
|
|
|
|
More to the point it would only be really viable if there are very limited number of controls so the assumptions would kill this idea.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
From a purist's perspective, yes, a view model should not know absolutely anything about the view.
Think of this from a unit testing perspective - if you are going to write some tests for your view model and you have reference to the 'view' in that, its going to be that much harder to get around the view and write a test case.
However, I've noticed that while implementing run-time animations etc, I have sometimes failed to have view 'independent' view models.
Very often, I just use the Tree Helper and parse through view controls from within my view model - not the best implementation from the purist perspective. But with animation and 'hey whatever works' in mind, sometimes a deviation from the pattern works better.
|
|
|
|
|
I have heard it said WPF was designed with MVVM in mind.
Anyone know if this is true? Any documentation to support this?
Thanks
Everything makes sense in someone's mind
|
|
|
|
|
That's not quite right. MVVM was invented by John Gossman to support WPF development, because WPF provided far superior binding capabilities to its predecessors. It's often said that WPF was designed with MVVM in mind, but that is not the case - in fact, John had been working on Avalon for three years before he publicly coined the term Model View ViewModel[^].
|
|
|
|
|
Although, the answer does very much depend on what you understand MVVM to mean. The underlying 'essence' of the pattern is rooted in the Presentation Model pattern which Martin Fowler described before the WPF framework was developed.
http://martinfowler.com/eaaDev/PresentationModel.html[^]
This is something that Gossman openly acknowledges. In my opinion, MVVM is a WPF / Silverlight specific implementation of the Presentation Model, in that the general understanding is that you set your view-model as the DataContext of the view, minimise code-behind and promote design-time data and unit testing. WPF was designed with these concepts very much in mind.
|
|
|
|
|
Ahh, time for the Disciples to go forth bringing knowledge to the masses. 
Indeed, MVVM derives from the Model View Presenter, but it is closely tied to Model View Passive Presenter which Fowler came up with at roughly the same time as John. It was a logical extension of MVP, so there's no real suspicion about the relatively simultaneous independent creation of logically related concepts.
|
|
|
|
|
Indeed. What Pete said! It's all MV-Poo
However, I do get very annoyed when people take the conceptually simple and elegant MVVM pattern and extend it into something that is much harder to comprehend. Does anyone really need the Model-View-Presenter-ViewModel (MVPVM) pattern?
http://msdn.microsoft.com/en-us/magazine/hh580734.aspx[^]
Admittedly, I haven;t read the article - so maybe I am a bit hasty in judging. However, what I really like about MVVM is that I can explain it to any competent developer within about 5 mins and know that they will follow it correctly. The same cannot be said for 'classic' MVC pattern.
|
|
|
|
|
Indeed, you're right. MVVM is a simple concept - granted there are subtleties, but these are implementation subtleties and nothing to do with the underlying pattern. What annoys me is when people heap all sorts of different patterns on top and then say, "this is MVVM".
For instance, although we all use Mediators or Messengers, they are nothing to do with MVVM - they are merely a way to help communicate between separated concerns. Similarly, when people say that MVVM is DI or IoC, again, these are just other techniques to help - they aren't MVVM. Properly applied, they help make better code, but they are not part of the core MVVM concept.
Possibly my biggest bugbear is when people think that MVVM means that you have to remove ALL code behind. That's just plain errant nonsense. If you want to trigger an animation just because your window is closing then, by all means, trigger it from code behind.
Ah well, we're just rehashing old ground here.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
