I have got a question about event and bound command.
What happens if I bound a command to my button and also handle the click event in my code behind ?
I mean, I have already tried and everything is ok but I was wondering whether this affects the efficiency or something else ?
Is it a good practice ?
In my case the code behind is just to close a window after it has executed a command.
thank you everybody
This is definitely not a best practice, since they are two different ways of achieving the same outcome. What you may want to do investigate as a solution, is passing a callback as the parameter (or part of the parameter object) of your command and have the command call the method/callback.
If you must, you can also specify, with a flag, whether the callback should be called before of after the command's code block completes.
It's deterministic, but I only think it's "good practice" if:
Your command is providing some business logic AND
The click event is being handled to do something purely view-related, such as begin a storyboard.
You could always trigger the view response from the viewmodel instead if you wanted (in my example you could use a datastatebehavior)
Related
I try to send for the Open event of the window from the event ItemChanged a DataWindow using the: SUPER :: EVENT OPEN () in addition to the open event contains "script ancestor" I also need to run; itself need to restart the window from the event ItemChanged of a DataWindow.
I hope your help.
Thanks in advance.
Regards,
A few things jump out from your question.
SUPER::EVENT OPEN() will try to call the Open event of the DataWindow if called from the ItemChanged, not the Window.
I'm not 100% sure of this, but I'm pretty sure I've run into problems trying to call the ancestor of one script from a completely different script. I can't point to documentation; I'll have to just chalk it up to experienced suspicion.
It's not entirely clear what you're after, but if you want to call the Open of the window (and I'll suggest otherwise below), and if the window's Open script either extends the ancestor script or explicitly calls the ancestor script (as above), explicitly calling the ancestor script is unnecessary, and strikes me as potentially undesirable. Just call the Open script of the window you're writing.
This will depend entirely on your code, but of the dozens of systems I've had to maintain, I'd never assume that running the Open event of a Window would "restart" the window. Most systems I've worked on, that would just create an unexpected mix of previous and new states. Additionally, even if I coded this from scratch to work perfectly in this way, I'd assume that the next guy that came along to maintain my code (after I won the lottery and retired to a small South Pacific island) would code in a way that made perfect sense to him based on other systems he worked on, but would screw up my assumptions. If I needed to "restart" the window, I would either:
close the window and post an Open() (the function, not the event) of the window again
create a ue_ResetWindow event, hopefully coding so that the Open could use it as well, that made it obvious that anything added to the window needed to be maintained in this script as well
(Of the two, the latter would be far better user experience and coding, IMHO.)
Good luck,
Terry.
I have a three level of nested user controls in my Silverlght 4 application.
the most low level control fires an event with some parameter, then second user control takes the parameter and also fires an event sending parameter to up. Third user controls makes same thing passing parameter to the MainPage. Anyway a have got my parameter but the way I did it very boring and confusing. Is there any acceptable and easy understanding way to do same thing shorter.
Thanks a lot!
That is the correct way, mainly because any level is replaceable and so should function the same way.
Boring and simple looking are actually good things for code... makes it easier for others to follow.
If you want excitement... I would suggest a career change :)
It all depends on what the event is and what the parameter you are bubbling up contains. If this is purely user-interaction and the visual parent needs to react to your event, then, as HiTech Magic mentions, this is the best way to do it.
Now, if what you are trying to do is actually related with the business logic of the application, then maybe your user control is not best place to handle this event and you may benefit from binding a view model to your user controls and using some kind of event aggregator to broadcast your events.
It may be good for you to add more context to the event your are firing and the parameter which you are bubbling up to the container for you to get additional information which applies to your context.
I am making an asynchronous call to a web service. Since it might take a few seconds there is a status Label used to let the user know what's going on. But even though the call is async the first call seems to block for a few seconds and the status label takes too long to get updated. In WinForms I could force the label to refresh (using Update() I think) but not in WPF. Any super easy ways to get this working?
Thanks,
Gerry
You could move the entire call logic into a QueueWorkUserItem or BackgroundWorker block. That way the first proxy initialization would not block the UIThread (before the async. Begin/End pattern kicks in). Assuming that you are using databinding the object exposing the property bound to the Label implemented INotifyPropertyChanged everything should happen automagically.
I'd (wildly) guess that the blocking is due to the creation/initialization of the service proxy classes. If so, you could try to create the proxy earlier, or call your asynchronous web service in another thread.
The general answer to your question about refreshing controls... I have always relied on data binding to do this. That won't help though if the main UI thread is stuck doing something. And if the UI thread is stuck, I don't know that there's any way to get it to draw.
There isn't a way to tell the label to refresh that will actually work in your case. If the UI is being blocked, it won't refresh. Basically, when you actually get to the point where you update the label's text, it will show in WPF. The only possible exception that I can think to that would be if you are using a non-WPF control but even then it should work.
My suggestion would be to update the label before you perform the first action (even before variables are initialized, since this might be where the issue actually is). Here is a pseudocode example of what I mean (just in case I wasn't clear):
private void KickOffProcess()
{
label1.Text = "Processing ..."; //This is where you need to move the label update code
AsyncCall();
}
I have a button on a toolbar that has its command set to "MyControl.Print" (for example).
In the control the command is added to the command bindings including both the Execute and CanExecute.
The control is within a window with other controls docked appropriately.
I am finding that for the Print button to be enabled I have to "select" MyControl first which does not provide a good user experience and indeed causes various "bugs" being raised and lots of confusion.
Is there a way that I can ensure that the button is enabled whether or not the control has been "selected"?
Since the CanExecute doesn't fire, I think you might be looking at the major downside to RoutedCommands - the way they tunnel and bubble can leave a highly composed interface unable to have commands arrive anywhere useful. For this reason we ended up moving to DelegateCommands from (I think) the Microsoft CAG. Not any of the other stuff, just the commands. Works a lot better, and isn't tied in to the interface so tightly.
Oh, the other response raises a good point. I assumed you meant that to ever print, your MyControl needed to have keyboard focus. Is it only the first time and after that it works?
I recommend http://msdn.microsoft.com/en-us/library/ff921126(PandP.20).aspx as a pretty good starting point. You don't have to worry too much about the IActiveAware up front, since you're hoping for this command to be available all the time (or at least let its availablity be determined by CanExecute).
CommandManager.InvalidateRequerySuggested will force the command manager to re-call all of your CanExecute methods and should disable the button. Perhaps call that onload?
I have a single RoutedUICommand that can be accessed through various places in the UI. Such as global Keyboardshortcut, Menu, ContextMenu or Button. The code that is to be executed in the RoutedUICommand.CanExecute and RoutedUICommand.Execute methods depends on what UI element was used. How can I achieve this differentiation. I was thinking that I could use the (Can)ExecutedRoutedEventArgs.Source or OrigianlSource but the source is always the same. It is the main Root window. How is this usually achieved? What could I possibly be doing wrong?
If you need different code to run depending on the UI that invoked the command you are probably doing something wrong.
If you have something like a just doing something from a keystroke or opening a dialog asking for more information from a menu you should break this apart into two commands (like MS Office "Print" and "Quick Print" commands).
If you truly have to do different things from each UI element you are not getting any advantage from using commands and should think about using old fashioned event handlers, at least then the element specific code is tied to the element and not stored in a central all encompassing "Execute" code .
And if you choose to ignore my advice above, take a look at the CommandParameter property, you can set a different value fro the parameter for each UI element, at least with it you can keep an illusion of the UI/Logic separation commands are designed to provide.
Normally you could have different CommandBinding implementations for different 'Targets' - having different behavior for each 'Source' is unusual.
Could you give an example of what you are trying to do?