|
Yes that code could/should live in your entity base, but calling it may be best done either when the edit address dialog is closed, or when you call context.SaveChanges() depending on when you want the update to perform. But typically there should be no need for the UI to ask the model to refresh, it should be the other way around, the data telling the UI that it has changed, this way when you use your address some where else you don't need to have another call to notify from the UI to the Model.
|
|
|
|
|
If you want to update all properties, the easier way to do this is just to call PropertyChanged with no property name in the PropertyChangedEventArgs. That updates all of the properties. BTW, you have a possible race condition in your OnPropertyChanged method. Do this instead:
protected void OnPropertyChanged(string name)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler != null)
{
handler(this, new PropertyChangedEventArgs(name));
}
}
|
|
|
|
|
|
What's a 'race condition'?
If it's not broken, fix it until it is
|
|
|
|
|
Multiple threads potentially hitting the same piece of code around the same time. In the original example, there is a test for a null handler, and if it's not null, the event is raised. The race condition occurs because these are two discrete operations so the second call to the handler could be null because another thread freed the event handler. That's what my code fixes (there are other ways, but this one's a common way).
|
|
|
|
|
Ahh, ok. I get the idea, just never heard the term.
Learnt me somethin 
If it's not broken, fix it until it is
|
|
|
|
|
Very nice, Thanks!
If it's not broken, fix it until it is
|
|
|
|
|
I really like this. It's easy to implement in my EntitytBase class, doesn't require me to change my POCO's, and is triggered by the UI. So if my WPF is later deprecated, I have one piece of code to remove.
Very nice
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
Yes. With everyone's input, a happy ending for all.
|
|
|
|
|
Agreed, thank you all
If it's not broken, fix it until it is
|
|
|
|
|
Silly question, but why would you want to send an update for *every* property in your POCO? That *could* be potentially VERY expensive.
|
|
|
|
|
As opposed to somehoww firing a refresh only for those properties that changed? How would you keep track of that? It's simpler to do it across the board.
If it's not broken, fix it until it is
|
|
|
|
|
Yes, it is definitely simpler. If you are looking for a quick & dirty solution, this is it. I was just pointing out that it could slow down your UI CONSIDERABLY depending on how its set up.
Think about what happens. You raise an INPC for "SomeProp". Some UI element is listening to the INPCs. It has to listen for a specific one for "SomeProp". Say your POCO has 20 properties. You just raised an INPC 20 times and that check for "SomeProp" also happens 20 times (at least). Not a super expensive situation, but just one of many.
A more expensive situation may be where you have 5 bound properties. You update Prop1, but because you went the quick & dirty route, you now send 4 INPCs for stuff that hasn't even changed. Prop4 might be an expensive property to refresh, but Prop1 may be super cheap. You certainly wouldn't want to send an INPC for the expensive Prop4 in this case.
Again, depends on your situation  . Just tossing out that your UI could slow down considerably by going this route .
If you used the dictionary solution I provided earlier, you wouldn't have this problem.
If you are sure all properties are cheap to update then this solution is fine
But you might notice your CPU% going high .
|
|
|
|
|
It sounds like you're saying, just code out each property to call INPC. I'm ok with it, but it does add some to to all my POCO's.
If it's not broken, fix it until it is
|
|
|
|
|
No, I said you have to think about the expense of updates . Obviously though, the better solution is to only send INPCs for the properties that are actually changing. I mentioned a dictionary solution here:
http://www.codeproject.com/Messages/4327542/Re-WPF-Update-UI-When-Collection-Changes.aspx[^]
That will allow you to do a "generic" solution without sending INPCs for every property. Your current poco's would just need a quick search and replace and your base class could easily be modified down the road if you happen to deprecate the INPC / WPF stuff.
If you are certain all your UI updates will be cheap, the loop through all props solution will be easiest... but personally, I think having to call the RaiseAllPropChanges() method from your VM is *very* dirty. You'd have those calls strewn around everywhere.
|
|
|
|
|
how to make progresbar in C#? 
|
|
|
|
|
What UI are you using, winforms, ASP, Silverlight or WPF.
Usually you drag the control onto your form and then increment the progress value.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Drag & Drop from the Visual Studio's Toolbox.
Search in msdn for examples & explanation.
Regards.
Christian Amado
MCITP | MCTS | MOS | MTA
Olimpia ☆ ★★★
Please mark as answer, if it helps.
|
|
|
|
|
How to create Themes in WPF. when we change system themes than change style our WPF controls.
|
|
|
|
|
You need to create a separate Resource Dictionary for each theme that you would like to incorporate into your application. In each theme resource you need to create a style for each control you would like to include in the theme, and then you can change the theme during runtime by using the MergedDictionaries properties of your application like this:-
ResourceDictionary skin = new ResourceDictionary();
skin.Source = new Uri(@"Resources\Themes\yourTheme.xaml", UriKind.Relative);
Application.Current.Resources.MergedDictionaries.Clear();
Application.Current.Resources.MergedDictionaries.Add(skin);
Hope this helps
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
In xaml you can create a Style file, Style.xaml and put there every style that you want to apply on your project.
Add to the ResourceDictionary in App.xaml
Regards.
Christian Amado
MCITP | MCTS | MOS | MTA
Olimpia ☆ ★★★
Please mark as answer, if it helps.
|
|
|
|
|
How to user control open in center alignment of Main Window . This issue related to WPF and c#
|
|
|
|
|
Without any further info it is difficult to say. You could just use VerticalAlignment="Center" and HorizontalAlignment="Center" if there are no other controls on the form.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
Put the usercontrol inside a Grid.
Regards
Christian Amado
MCITP | MCTS | MOS | MTA
Olimpia ☆ ★★★
Please mark as answer, if it helps.
|
|
|
|
|
I have been having this problem lately where when I bind a button to a command, the CanExecute only every fires once - on startup. So the condition is never reevaluated.
Here's my code:
The button
<controls:FlatButton Style="{StaticResource FlatButtonStyle}"
Caption="Edit"
Description="Edit the selected address"
ImageSource="/UI.WPF;component/Media/Images/edit.png"
Command="{Binding Path=EditAddressCommand}"/>
Code behind
private ICommand _EditAddressCommand;
public ICommand EditAddressCommand
{
get
{
if (_EditAddressCommand == null)
_EditAddressCommand = new RelayCommand(editAddress, editAddressCanExecute);
return _EditAddressCommand;
}
}
and
private bool editAddressCanExecute()
{
return SelectedAddress != null;
}
private void editAddress()
{
... code here
}
The SelectedAddress IS being set, I checked it. editAddressCanExecute only ever fires once - on startup.
Seems sort of vague, but I really don't know how to debug this. I get no output errors or other errors of any kind.
If it's not broken, fix it until it is
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
