I'm currently designing a workflow that displays user controls on a winforms form then waits for the user to click a button on the user control just displayed so that it can capture data the user entered. I'm having difficulty finding an activity? (is that the right word?) that sits and waits for a click event to occur on the button of the item.
Does anybody have an idea about how to do this?
Thanks,
Related
if in salesforce we make changes in one screen and without saving them moves to another screen, a popup message is shown.
how to implement that in another screens.About this Popup
I've started using the XCEED MessageBox recently, which uses custom chromes (<-I think that's their name) for the title bar, and it seems that there is no handling for the case when a dialog window (or modal dialog in Win32 terms) needs to flash in response to the user trying to click on the (disabled) parent window.
The flashing border animation is usefull to notify a user that he must respond to a dialog before continuing and to give a hint on which dialog window is that.
Is there a way to get notified when a window needs to perform the flash animation in WPF or set XAML triggers for it?
I'm building a touch screen application in WPF and I'm wanting to show a change in UI when the user presses a button with their finger/stylus. Currently you only get a flicker of UI change once the finger is released but nothing before that.
I've been trying to hook up triggers and/or eventtriggers in the button template to things like stylusdown and touchdown but to no avail.
I've hooked up some console writes on events attached to a button and they appear in the following order:
StylusDown
StylusButtonDown
TouchDown
StylusUp
StylusButtonUp
Click
All of which firing at the same time when the finger is lifted from the screen. (TouchUp doesn't seem to fire at all).
Any ideas on how I could begin to capture a finger pressing onto a button in the template so I can give the user some idea that they are actually pressing a button?
After blogging in more detail about this issue I had a comment recommending using a SurfaceWindow and then SurfaceButtons from the Surface Toolkit (currently in Beta) and now all is working as I would expect.
Update: The link is now dead. Here's the link to that page from Wayback Machine.
I have a winform dashboard which hosts some WPF dialogs. When I select a row in the winform ListView and hit Enter key, OnItemActivate is called which launches a WPF dialog. However, the WPF dialog appears and then disappears immediately because the default button “cancel” is hit. It seems that the Enter key is triggered twice, one for launching the WPF dialog, the other for hitting cancel button. We don’t want the WPF dialog to be canceled by the Enter key hitting.
According to the stack trace, it looks like that WPF and Winform handle the enter key separately. The WPF does not know that the enter key has been handled by the Winform ListView. Is this by design in Winform and WPF interop?
To make the enter key not close the WPF dialog, we have to change the focus from the cancel button to another control (e.g. a textblock). Is there a better way to fix/around this issue?
As Rick suggested in the comments, try calling Application.DoEvents() before opening the WPF dialog.
is there a best way to manage a form in WPF application which has asynchronous execution commands?
1) Suppose you have a form where user
enters all his data and clicks on Ok
button to save changes.
2) Your WPF app starts an asynchronous
method to record those data.
3) Now suppose the database server is
down, and the operation is taking
about 15 seconds to get finished. At
this time, user has already closed the
WPF form (he did not wait for the
transaction to be finished).
So that's my question: how could you control when to let user close or not the form?
thank you
Easy answer...don't let the user close the form until the operation is complete.
You can accomplish this with a Modal infinitely scrolling progress bar. It provides feedback to the user that your application is doing something...but doesn't let the user close the window they were working in.
This allows you to run your code outside the UI thread and then when your code completes (either finishes or errors out) you can provide feedback to the user about what happened (either success or something happened and they need to save again).
I would suggest that you disable the controls in the form when the asyncrhonous operation is started. This provides immediate feedback that the state of the form has changed. However, if the operation can be cancelled you should still allow the user to cancel/close the form. Closing the form should then cancel the operation.
If you expect the operation to take longer than a few seconds you should display some sort of feedback like a progress bar. Cancelling the operation should then be on a control visually associated with the progress bar.
Please don't show useless modal message boxes when the operation completes successfully. It is really annoying to not only have to wait for the operation but to have to click on "OK" when the operation is complete.
David Poll has created an Activity control for Silverlight that you might get some inspiration from.