I'm trying to implement some sort of solution to the 'double submit' problem that occurs when there is a submit button that fires a code routine that takes some time to run.
Unfortunately, with a good number of users still using old internet browsers and some running no-script addons. I cannot use javascript.
Is there a way to disable a button after clicking a button in asp.net?
Since you want to disable the button after the user has clicked (and while your page is still loading) it has to be done on client side. JavaScript is the only client-side language you can use for this.
So make sure that if the user has Javascript disabled (highly unlikely these days), that your end-page can deal with "double submitted" data.
Short story, no.
In your situation, you would need to make some server side code to detect a double post, and then discard the duplicate request.
You can start timer on server after each button click and put it in session. On next click you can check timer and apply or decline next user click.
So it will be impossible to disable the button without some kinda of client side scripting. If you assume that it will be disabled, no matter what kinda of client side script it is, then that's an impossible task.
What you can do is ensure that the operation they're trying to perform won't ever be run more than once per page load.
When loading the page create a hidden field; populate that field with a GUID.
At the start of the server side click handler enter a Lock block.
Check for the existence of a session key based on that GUID. (Give it a prefix so it won't collide with any other GUID based session key.)
If the key existed, exit the lock block and do nothing, or display an error message of some sort.
If they key didn't exist, then add a new value to that session key, exit the lock block, and do your operation. Give the session key an appropriate expiration time; it shouldn't need to be more than a handful of minutes. You could even remove the relevant session key at the end of the operation, if it makes sense for it to be repeated at that point.
in button click event just write the code
{
//Some Code
button1.Enabled = false;
}
Related
CommandManager.InvalidateRequerySuggested() is called automatically every time a key has been pressed, when the focus has changed etc. I'd like to prevent this from happening under certain conditions (for example only call it when keys pressed are not Up or Down) and do my own handling of RoutedCommands, because InvalidateRequerySuggested() always processes all commands and is a bit slow.
I can see in the reference source where InvalidateRequerySuggested is called, but I don't see a way to intervene there. There is a PreProcessInput event, but the necessary information you'd need from it is hidden in internal classes like InputReportEventArgs.
Is there a way?
I have an ASP.NET web app that uses a single page, but makes some controls invisible and others visible throughout the workflow. It's a fairly simple application, which is why it just uses one page.
I'm not sure though how to reload the page when a user clicks a cancel button, or when they complete the workflow. Here's some details about the application workflow...
The page loads and displays a LoginTable control with a dropdown list with employee names, and a pinpad where a pin number is entered for the selected employee, and a login button.
On clicking the login button, a postback occurs where the pin is validated, and if valid, the Table control that holds most of the page contents (except the header) gets made invisible, and a new Table control gets made visible depending on the current status (clocked in or out).
At this point, either the ClockInTable or ClockOutTable control are visible, and the LoginTable control is invisible. The user can either click a Cancel button, or a Clock In / Out button (with some other things to select if clocking in, like work site and job).
What I want is, when the user either clicks the Cancel, Clock In or Clock Out buttons (after any other processing on postback), for the page to load again with a new session and showing the main LoginTable again just as if the user had restarted the browser and opened the page for the first time.
I've tried using Session.Abandon(), and then in the Global.asax Session_End event, I do
Response.Redirect("Login.aspx");
This doesn't work though; it still just reloads the same view of the page.
How do you reload the page (not refresh the page) as if it were the first access (i.e. not a postback)?
Also, I'm new to ASP.NET, so if I'm misunderstanding how a session works, please let me know.
Have you tried Response.Redirect()-ing the user to the same page? That should load the page as if it were a new one. It won't lose the session data though.
I'm not exactly sure you can do that the way you describe. However, what you can do is have a flag as a session variable. Call it say IsFirstComer. I'm not sure how the workflow of your system goes, but you can have it reset to true every time a new user logs in (hasn't started a workflow yet), or has exited a workflow (needs to start all over again), but as soon as te user has started the workflow you set it to false. Your controls behaviour can then be controlled through the value of IsFirstComer.
Have you write: if(!this.IsPostback) in the Page_Load method, after that try "Response.Redirect(page.aspx)" again.
I have a TextBox. Basically it is a search box in which user is entering keyword and then the search appears.
I have a button now for this, but I want to do on EnterPress Event. How can I achieve this?
Thanks!
Since this is ASP.NET, the textbox should fire off a postback when the Enter button is pressed automatically. That's just what happens with forms in a browser.
Edit
You don't need to do anything special to trigger a postback. The way I read your question, you want to know how to perform the search on the code-behind when the postback is triggered by an Enter keypress in the textbox. If this is incorrect, let me know and I'll delete this answer.
End Edit
The server-side code does not support a "TextboxEnterPressed" event. The closest you can get is the TextChanged event.
If you haven't already done so, move any code necessary for performing the search outside of the Button_Clicked event handler into it's own function. Then change the Button_Clicked event handler and the Text_Changed event handler to call the same function.
OR you can write something in JavaScript to handle the Enter keypress, but as I said - in a web page, pressing enter in a textbox within a form triggers a postback anyway, so you should not need to bother
Exception - if this is a TextBox with the TextMode set to "Multiline", which actually produces Textarea in the html output. If that's the case, you will need a JavaScript solution.
Put both into Panel and set DefaultButton.
Try this:
$('#input_text').keyup(function(e) {
if(e.keyCode == 13) {
alert('Enter key was pressed.');// do your stuff here
}
});
If it were me, I would go for JavaScript, there might be a way to do this in .NET itself, but this will submit the whole form, in the usual .NET way.
There are two major JavaScript frameworks, my personal preference is MooTools, however it's the harder of the two to learn, but it's benefit is that it's got a nice OOP design to it, so if you know OOP and you want to learn to do a lot more with Js then this in my opinion is the better. The alternative is JQuery, a good framework, easier to learn (though could be negligible depending on your experience and knowledge).
MooTools
JQuery
Once you have the JavaScript setup you then need to decide how you want to get the data, the simplest method would be just to use a _PostBack call which would call a standard .Net postback method, I've also heard that there is a _ICallBack method, which can be used to call a .NET method without a postback, but I personally haven't used this yet.
But my preference would be to use a WebService and a javascript call which would allow you a lot more flexibility and return quick results, either on enter or even 'as you type' search, like google - straight to the page, asynchronously, without page reload.
If you give me more data on exactly what kind of feedback you want to give the user I can advise better.
Is it a simple replacement for pressing a button, or something more advanced?
I have a requirement to check for a certain condition on postback before redirecting (Response.Redirect) to another page.
Note... I cannot use JavaScript to detect whether or not to confirm (this is also a requirement) :s
Pseudo:
protected void lbtnRedirect_OnClick(object sender, EventArgs e)
{
if (showConfirm)
{
// Set flag for client side
this.ShowConfirm = true;
// Track this event for next postback.
}
else
{
Response.Redirect("somepage.aspx");
}
}
If the showConfrim flag == true, then the client will be show a modal dialog box asking them if they are sure they want to redirect. If the user clicks on "Yes", then the page posts back and the desired effect is that the lbtnRedirect_OnClick event is fired. How would I about tracking the lbtnRedirect event?
Edit:
I have no problem tracking the flag to show the modal (yes JS must be used to show the modal... somethings you just cannot get rid of :)). I should have been more clear.
It is when the user clicks "Yes" to continue the redirect. The page will postback again but needs to know which event to go through.
i.e. Suppose there are 3 onclick events, 1) lbtnRedirect1_Onclick 2) lbtnRedirect2_OnClick 3) lbtnRedirect3_OnClick... each of which does the confirm check.
Each onclick event does the check. So when the user clicks on "Yes" on the modal, how does the page know which event to drop back into?
You can use ViewState if you're in WebForms.
Implement a ShowConfirm property encapsulating ViewState["ShowConfirm"].
In the first postback you'll set ShowConfirm 'true', and this will activate that modal during the render (if ShowConfirm is true, that's setting as visible 'true' some control).
In the next postback, you'll set ShowConfirm 'false' because is 'true', and finally you'll do the whole redirect!
You can use an ajax call from javascript to set the required values.
Since the postback will happen before even the execution reaches to your button click event we need a workaround here, And if you don't need JS as your requirement, so take a look at
Implementing Client Callbacks Programmatically without Postbacks in ASP.NET
This is much like a wrapper for XMLHttp Ajax call IMHO.
You cannot easily create a model form, without javascipt.
One suggestion I would make is to have panels in your page.
Panel one is visible.
On submit one; panel one hides and panel two is visible asking for a confirmation.
On panel two is a confirm button, clicking this button your redirection is performed.
Are the two events the same or are there differences that we should take note when coding the keyboard presses?
My answer here is just based on experimenting with different applications, not programming per se.
Handle the keydown. Let that be the trigger for your logic. That's what the user would expect based on interacting with other applications.
For example, try a key down in Notepad, and you'll see that the DOWN triggers the reaction in Notepad. It doesn't wait for the UP.
It doesn't matter if it's .Net or not, it matters what the user expects. Keydown is a good time to respond to the four arrow keys. Character input is a good time to respond to input of visible characters. Keyup is usually a good time to respond to any action that is going to have an effect on a document, but keydown would be better if it's a game where the user wants immediate effect.
It's not really "which is a better choice for .NET."
You really have to think about how you want to respond to key presses. If you want to what someone is typing in a text box it's usually best to wait until they've released before trying to decide what they're doing. But if it's something like a game where you want to respond the instant it's pressed, than you would use KeyDown.
KeyDown is the moment the key is pushed down.
KeyUp is after the key has been released.
One thing to consider that I've had a problem with before:
If you handle something on key down that changes the window or changes UI component focus, then the new UI element may sometimes get the key up event.
This happened to me at my last job. We had a control on a form that, on key down, would load a new form. If the new form loaded fast enough, then the new form would get focus before the user released the key, and the new form would get the key up event. We had a UI control on that 2nd form that reacted to key up, and it would sometimes get triggered unintentionally.
The moral of the story is; keep it consistent. Pick one or the other and stick to it :)
The key down event happens as soon as the user presses a key, the key up event happens when they release the key after pressing it.
So if you use the key up event, and the user presses a key and holds it for 5 seconds, nothing will happen until they let go of it.
(Note: I know nothing about .net, I've just used 'key up' and 'key down' events in other libraries.)
I allmost allways use KeyDown, because then I can use e.Handled=True and stop the keyevent to travel from textbox to container and down in the eventque if I want. You can use e.Handled in KeyUp also, but then its "to late" because the key the user entered will be seen in the textbox and you have to take it away manually if you for example want to stop the user to enter digits in the textbox.
Another thing to take into account: When holding modifiers, it's important to use keydown. I generally use keydown to set a variable like ctrlPressed=true; then use keyup to unset that variable ctrlPressed=false;
I generally use keyPressed for all alphanumeric characters.
This sort of system allows you to enable things like CTRL+K+C ala Visual Studio