a better ResetForm method could be something like: function ResetFormByTagName( tagName, hasValidators ) { var arrTags = document.getElementsByTagName( tagName ); for( var i=0; i »»» KenA
Ken A
Posts
-
javascript form.reset() issue after the postback of an asp.net page -
javascript form.reset() issue after the postback of an asp.net pageok ... but your ResetForm() method is too generic ... it will reset all inputs in my webform, eg: type="submit", type"option", etc ... i just want to reset type="text" ... looping through all the input attributes until i find one with type="text" to clear its value ... hum, is there a better way?
»»» KenA
-
javascript form.reset() issue after the postback of an asp.net pagebadgrs wrote:
Why are you using javascript for the reset in the first place? Why not use ?
hi ... the reason i'm not using the type="reset" is because i also call another js Page_ClientValidate(); in order to clear any eventual error msg previously displayed in case the user has done some bad format input, other than this i would use your idea.
badgrs wrote:
Since the values are 'hard-coded' (in the html) upon a postback, javascript is your only option.
ow, that's what i was afraid of ... but if js is my only option, this leads to the following conclusion: for asp.net pages it's useless to call form.reset or the input type="reset" tag since it will only work before postbacks, plus i will also have to manually track all forms elements i'm eventually using in the webpage, not just input fields, but select fields, option, etc as well what is important to notice is that the built-in form[].reset() goal is really to 'reset' form values to its original values and NOT to clear all form fields, unless the initial values are empty ones!!! but then a doubt raises: isn't asp.net breaking the rules by maintaining form field values after a postback? one of the great things when asp.net brought was keeping form values after a postback, but now i can't use one of the most basic things in html???
»»» KenA
-
javascript form.reset() issue after the postback of an asp.net pagehi. i have a simple page with some textboxes, a submit button and a client-side reset button. 1. for this first scenario, i fill the textboxes and the reset button works fine in case i click on it 2. for the second scenario, after i filled the form, i submit it and after the postback, since it's an aspnet page i have the textboxes filled ... in case i click the reset button the textboxes will not be cleared, but it will be reset to the previous values, because now the reset will 'think' that the original values are not the empty ones, but the ones i have filled the form note: i also set the enableviewstate=false to the textboxes note: if i do a server.transfer then i have the textboxes cleared, but this is no option, since after the submit i show a message in the page, plus i don't want to postback a page just to clear the form elements note: i reset the form elements with the following code: 1 2 function ResetForm() 3 { 4 var formId = <%= "'" + Form.ClientID + "'" %>; 5 document.forms[formId].reset(); 6 } 7 someone may say to use a javascript code to look for the form elements i want to reset and set its values to empty, but again why? since i have a built-in reset method so, as far as my understanding goes, form.reset, reset form fields to its original values, not necessarily empty values ... after the postback, the original form values will be the ones i had filled in, like in the second scenario example. any tips on how to properly reset this form? »»» KenA
-
Masterpage and Content pageHi minhpc_bk, You pointed 2 options: 1st: the one I´m using,eg navigating from current page to another, but with this option as you said, the ViewState of the selected item gets lost. What´s the solution for this option? Considering I want to navigate from one page to another ... Will I have to target the master page menu from each of the pages? That´s not a good solution ... too much coding 2nd: To use a single web page instead of 3, but this way I believe I´ll have to have views/panels hidden and showed according to the selected tab, right? This turn to concentrating too much logic in a single page. Suppose I have 100 tabs!!!
-
Masterpage and Content pageHi. Regarding the relation between a Masterpage and some Content page I believe that sometimes it´s a bit difficult to decide where is the best place (Master or Content page) to put a Control. For example, I have a set of menu items (from a Menu control) that are displayed as Tabs. Suppose I have only 3 menu items that I call AAA,BBB,CCC ... when I click in AAA it should call the A.aspx page, the BBB > B.aspx and CCC > C.aspx ... The Menu control is in the masterpage named Master.master and A.aspx, B.aspx and C.aspx use this master page. I can think of 2 alternatives when building this Menu Items: 1st > I set the url attribute like AAA > url="~/A.aspx" and similar to the other menu items ... so when I click in any of these menu items I´ll be directed to the respective url or 2nd > I don´t use the url attribute and catch the OnMenuItemClick event and then create code to switch to the proper url Since I´m using Tabs, it would be nice to set the 'Active or Selected' Tab after the user clicks it. In the 2nd approach I can set the e.Item.Selected = true; but the Css used to mark the selected item will not work because after the click, the current page will be redirected to the proper page and the selected item will not be selected anymore. So I´ll have to end up creating complex code just to mark the selected item, probably in the current page (A,B or C.aspx) referencing the Menu control in the master page. I believe there is a simple approach to this situation. What is the best way to set the selected/active tab? This is not hard when using plain html pages, but this master/content page relation are a bit confusing ... I already read this interesting article: http://www.dotnetslackers.com/XML/re-27950\_Capture\_Master\_Page\_Events\_in\_Content\_Pages\_ASP\_NET\_2\_0.aspx, but I think there must have a simple approach to this situation which unfortunately I just don´t get.