|
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
|
|
|
|
|
* 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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
