|
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
|
|
|
|
|
* are you changing the DataContext?
* are you stomping over _EditAddressCommand?
* when the canExecute "stops working", does the execute still work?
* you can try turn on verbose debugging. Tools | Options | Debugging | Output Window. Set all the WPF traces to "ALL".
|
|
|
|
|
The ICommand interface has 3 Members. Beside the Execute and CanExecute methods, there is also a CanExecuteChanged event. You should raise this event when one of the conditions of CanExecute has changed.
|
|
|
|
|
Uh... no you shouldn't. That event is raised when the value of CanExecute has changed. You don't raise it yourself. There is no need anyways. The framework queries the commands in response to system events like mouse clicks, focus changes, etc.
|
|
|
|
|
I'm starting to doubt now. I have read about it in a book about MVVM pattern (Applied WPF 4 in Context, Raffaelle Garofalo, Apress, 2011, ch.8). The ICommand interface is used to build a custom RelayCommand, which should compensate for some lacks in the standard WPF commands. A part of the implementation is the use of the CanExecuteChanged event.
It works great. The CanExecute changes exactly when my ViewModel wants it to change it and the View reacts to it. I agree that I cases like mouse events and focus changes you just don't want to interfere with the commands. I'm not sure if it will work or should be avoided to take control of the CanExecuteChanges event in other situations.
|
|
|
|
|
RelayCommand and RelayCommand<T> are for the MVVM pattern. The sole purpose is to allow for the execute / canExecute handlers to be held in the command object itself (and thus the VM) rather then requiring a Window with a command pool. As I mentioned in my response to Pete, only ButtonBase and MenuItem even use it (or so it appears). There are other events that cause the commands to be requeried. I have NEVER come across a case where the standard RelayCommand did not work.
|
|
|
|
|
Martijn is correct. Most custom command implementations don't automatically raise the event, preferring the developer raise it at appropriate points. It's only recently that Laurent Bugnion has started to offer this in MVVM Light, for instance.
|
|
|
|
|
Funny  . I have used the standard RelayCommand and RelayCommand<T> implementations which don't raise the event and all my UI's work just fine . The standard implementation overrides the subscription as such:
public event EventHandler CanExecuteChanged
{
add
{
CommandManager.RequerySuggested += value;
}
remove
{
CommandManager.RequerySuggested -= value;
}
}
but it does nothing to raise the event itself.
In fact, if you look at the .Net source... the only object that is even using the CanExecuteChanged event appears to be ButtonBase and MenuItem.
|
|
|
|
|
I have found an example of an ICommand implementation using this same standard implementation (CommandManger.RequerySuggested). At this moment I don't know how the CommandManager works.
This weekend I'll give it a try. It's allways good to look at alternatives.
The custom implementation of the RelayCommand I'm using uses listeners. They listen to the PropertyChanged events of properties of the ViewModel. And when changes are detected the CanExecuteChanged of the Command is triggered.
|
|
|
|
|
Wow... that really sounds like overkill . I did actually think of a scenario where the standard RelayCommand implementation doesn't work as expected. If you have a window with a background worker that goes 0 to 100 or whatever... when it is done, the commands aren't refreshed until the user interacts with the UI. The workaround for that scenario has typically been to add a call to CommandManager.InvalidateRequerySuggested(). I'm not sure how you are wiring everything up with your implementation, but I guess that solves that problem without the CommandManager.InvalidateRequerySuggested() call. Personally, the CommandManager.InvalidateRequerySuggested() seems cleaner to me .
|
|
|
|
|
The CommandManager does work indeed, as you already knew . And would do the trick with probably all viewmodels I have writen.
The CommandManager raises the CanExecuteChanged quite often, probably with every user interaction which might change the data of the viewmodel. Although one might not notice a difference in performance.
The code I'm using is a little more complicated, but declaring the command is only a little more complicated. Although one might forget to add a listener when the CanExecute conditions change.
DummySave = new MvvmCommand(p => DoSave(p), p => (!string.IsNullOrEmpty(LastName) && !string.IsNullOrEmpty(FirstName))).
AddListener<TestViewModel>(this, vm => vm.LastName).
AddListener<TestViewModel>(this, vm => vm.FirstName);
|
|
|
|
|
I've seen more than a few examples that just subscribe to the event, and don't worry about the CommandManager. For instance, if you look at the DelegateCommand that was supplied by the P and P team, you'll see that this doesn't raise it by default. The reason for this is simple - quite often you want to control whether or not the execute change notification is raised because you could be updating several properties in one go and you don't want this to be handled until after you have raised all of the changes.
I use a variation of this to put the control into the developers hand, whereby they can specify on the implementation of the command whether or not they want to automatically subscribe.
|
|
|
|
|
Lets say you change 100 props on object X. Ok, so you'd be able to say "save the updates til later"... So you'd either send 100 property updates now or later. Not much difference in overhead. More of an overhead when you are dealing with collections, then it makes sense to batch updates (sometimes).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
