I have an edit form that that has 2 buttons on it, 'Save' (duh) and 'Return To List' ( which performs a save before actually returning ). The problem is the page also has Side Navigation and Top Navigation. So when the user selects any link in those the page doesn't save. Is there a way to perform a save even when Side or Top Navigation links are selected?
Note, this is an MVC3 C# project.
Have you thought about just alerting the user the page hasn't saved yet? Use the onbeforeunload event, display an alert message (or something similar). If they want to save, have them click cancel to stay on the page and save, otherwise proceed without saving.
Related
I have a custom Dialog with 4 linked screens(which come one by one on click of a Continue button) in my ASP.Net MVC application. On the 2nd screen, the user has an option to click a button which re-directs him to a entirely different screen(but inside the Dialog). Here there is a Save button. I want the user to go back to the 2nd screen when the Save is done but the Dialog is getting closed(redirecting to the landing page from where the Dialog was thrown initially. I'm doing a return Redirect(Request.UrlReferrer.ToString()); on click of the Save button but it clearly doesn't work the way I want it to.
How can I make the user stay on the Dialog? Can you please help me with the fix?
I have a grid view and an edit button in the grid view. On edit button click I am opening a new aspx page that has text fields for input the data. When a user copies the URL of the gridview and opens it in a new tab of any browser then click on the edit button for two different records. If the user changes anything in the first tab and submits it. It changes the info for the record on the second tab. It is happening because I am passing userid in session to the form aspx page and session got updated when user opens the second record in the new tab.
Are there only two ways to passing data to aspx page?
using session
using a query string
I don't want to use the query string.
Please help thank you.
You are writing a ASP.Net application, so at the end of the day there is only that much you can do. You can request some things off the browser, but if he actually does it is entirely up to it.
You can make it unlikely to happen by accident, using the HTML Links target property. This requests the browser to re-use any alread open tabs for this record. But that will not prevent a dedicated person from still opening 2 copies.
A pretty simple way to avoid race conditions in general, is the SQL rowversion column. You retreive the rowversion with the rest. You keep it along in a hidden formular field (that is what they are there for). When writing the update, check if it still matches before the write. If yes, you update. If not, somebody has modified the record since then and you reject the update. Can be the same user in another tab, can be another user at the end of the world. Could be that this tab was opened a year ago, surviving on sleep mode. It does not mater - any change trips this protection.
So what I have is a bunch of dynamically created textboxs that when the user enters some data and either tabs out or clicks out some calculations are done. After the page posts back control focus is lost. What I need is to be able to set focus back to the control that was tabbed to or clicked into not the control that data was entered into.
You'll have to send information about that control in the post. What happens in a postback is the the browser completely discards the current DOM and loads a brand new one, so to keep your place you'll have to tell your server where your place was and have javascript code that runs on page load to put things back.
Other options include doing this either entirely in javascript or using an ajax partial postback.
When a user is using a Detailsview or Formview in Edit mode, and tries to leave the current page, I want to trap this and force any changes to be saved, just as if the user had clicked on the Update LinkButton. How can I do this?
You can't do this reliably. Consider the scenario if their computer crashes altogether, or they kick the power cord out. There's so many ways that a user can leave a page.
However, you could put in a few safeguards. On any link on the page you could hook up events to do the save before they left. You could also try doing a save after every change in control focus perhaps.
Another thing you can do is hook into the window.onbeforeunload event and give them a confirmation message asking if they're sure they want to leave the page, like SO does when you have an unsaved answer. But there's nothing you can do with this event to force a save.
I have a page which the user gets shown when he wants to create a new or edit an existing document. There are two UserControls on the page. One simple DatePicker and a more complex grid. After filling out or editing the data he then can press continue which brings him to the review page where he can decide to really create or update the document or go back and change something. Going back is done in javascript with a history.back()
Now when the user is in "new" mode and decides to go back from the review page the grid partially looses its viewstate and the DatePicker loses it completly.
On the other hand when the user is in "edit" mode and goes back from the review page both controls maintain their viewstate.
I know that the browser just shows the cached version of the "new/edit" page. But why the difference in the state of the controls and what can I do so that it works in both cases?
Viewstate is essentially a hidden field in the form that gets populated with the control values that have been posted back to the server.
If a user enters or selects some values in the form's controls, performs a postback and then presses the browser's back button or does a javascript history.back(), you are viewing the page as it was before the postback took place. Therefore, the choices made by the user prior to the postback will not be present on the page.
The difference between "new" and "edit" is that on "edit" you are retrieving information from the database to populate the controls.
Instead of doing javascript history.back(), you should look into using a Wizard control. The wizard control is designed for this very purpose. If the user enters information in multiple steps, goes to the review page and needs to go back a step or all the way back to the first step everything is maintained in Viewstate.