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.
Related
Using <FlatButtin> (or any other control for that matter), the click handler (or the redirection) happens only once the visual "ripple" effect has finished.
This makes the UI I'm working on feel sluggish, because once the button effect starts, I have to fetch resources in the backend, and the user must wait again.
I understand the interest of giving feedback on user actions, but the ripple effect feedback actually blocks further processing in my app.
Is there a way to bypass the ripple delay and execute the click handler right away - without hiding the ripple effect?
Use react-tap-plugin along with onTouchTap handlers
When my app has an open dialog e.g. dlg.show(); and the screen turns off by timeout the active and displayed dialog is disappeared after turning on the screen again. I'd like to have the dialog still preset.
Is there a good/recommended way to fix/workaround this behavior?
For a solution, I could imagine one of the following approaches, but could not find further information:
Disabling screen timeout globally for the app.
Disabling screen timeout for dialog specifically.
Using another dialog type (modal, modeless or interaction) that keeps staying.
Maybe there are other ways to fix this?
Use a variable that you store the state of in Preferences. Perhaps a Boolean so when the dialog shows it is true, and if someone exits the app you save it in preferences (you can use exit form action or add something to the lifecycle methods). When the app restarts, get the state from Preferences and display the dialog again if the variable is true.
You could use and integer or string if there are multiple possible dialogs that you might need to show.
I am developing an ADF Fusion Web Application and I want to be able to update and save the changes about entities into my database. Do I always have to drag and drop both Submit and Commit buttons together? I can not unserstand their difference implicitly.
The submit button actually does nothing special, it just does a submit of your form (like in normal HTML). It's the same functionality as every other button (except if you start using the immediate attribute, but not considering this here). The data from your form (or input components) will then be 'saved' in your model (so your entities). But not in the database of course.
When using the commit button, a submit happens (so everything for above happens) and then your data will get committed (saved in your db).
User404 is correct. Lets go one step further. A lot of people do not want separate submit and commit buttons. This may give an example of calling the commit programmatically from the ActionListener event handler of a button.
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,
We have a WPF app (actually a VSTO WPF app). On certain controls there are multiple elements which, when clicked, load data from a web service and update the UI. Right now, we carry out these web requests synchronously, blocking the UI thread until the response comes back. This prevents the user clicking around the app while the data is loading, potentially putting it into an invalid state to handle the data when it is returned.
Of course the app becomes unresponsive if the request takes a long time. Ideally, we'd like to have the cancel button active during this time, but nothing else. Is there a clever way of doing this, or will we have to switch the requests to execute asynchronously using backgroundworker and write something that disables all the controls apart from the cancel button while a request is in progress?
edit: for actions we already expect to be long running (downloading a file etc.) we pop up a progress dialog window. The case in point is when you expect the action to be pretty fast (a couple of seconds at most) but occasionally take longer. In those circumstances, flashing up a whole window for a moment is a bit too distracting.
Your clickable controls should be bound to commands, and the commands should have CanBeExecuted return false when a background task is in progress. If you do this, the controls bound to those commands will automatically disable and enable themselves.
You can avoid duplicating a lot of code by creating a command class that implements the background-task-in-progress check, and then deriving all of your commands (except the cancel command, of course) from this class.
While you make your Asynchronous request on a seperate thread, show a Modal Dialog box with a Cancel button (and maybe a progress bar or some other activity indicator).
That way the user can't interact with the underlying UI and they still get feedback that something is happening...and the ability to cancel it.
One way would be to put a translucent canvas over the parts of the UI which are not accessible while waiting for the response and in the center put a message with a cancel button.
The Silverlight Toolkit has a BusyIndicator control. The toolkit is open source so you might easily be able to port it to WPF.
It disables and greys out everything in the area that it's assigned to when setting its IsBusy property to true either in code or by binding it to a model. Usage is as follows:
<ctl:BusyIndicator>
<StackPanel x:Name="myDataArea">
<Button Content="Load Data" />
<DataGrid x:Name="myDataGrid" />
</StackPanel>
</ctl:BusyIndicator>
I can't think of easy way other than disabling all controls except for "cancel".
Having said that, it might give a better user experienced if you displayed a "working" or progress dialog with just a cancel button.
You could use this dailog to display useful information about the progress of the web requests and any error messages that might come back.