It appears that ASP.NET WebForms automatically sets the values of the name and value attributes with the value of the ID attribute for an asp:Button. How dou you set custom values for those attributes? I tried it with
MyButton.Attributes["name"] = "CustomName"
but then i have two name attributes in generated html.
I would like to use custom values to determine which button was clicked during a postback. I don't want to use CommandName or CommandArgument because when a postback occurs I just want to check for name and value. I don't want to care about whether a handwritten input element
(like <input type="submit" name="buttons" value="abc"></input>)
caused the postback or a input element generated by asp.net
You can use ClientIDMode property to static. However, you need to make sure that ID is unique within a page.
ASPX
<asp:Button runat="server" ID="CustomButton" Text="abc" ClientIDMode="Static" />
Render HTML
<input type="submit" name="CustomButton" value="abc" id="CustomButton" />
Related
I am curious: is it possible to read the initial state of a DropDownList control using JavaScript?
Let’s say that when the page is loaded in the browser, the dropdown has ten options. Then, using JavaScript I remove all the options.
Can I read the ASP.NET ViewState to get the initial ten options and restore them?
The short answer is yes you can use JavaScript to read the viewstate values as they are stored in a field called __viewstate, which is rendered in the browser as an input field like this:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
The problem you will run into is the __viewstate value is encrypted.
My suggestion is to use a hidden field to store the values of the dropdown or whatever else you want to store and then access the value like this:
<input type="hidden" id="hiddenField" runat="server" value="" />
Then in your code-behind, since the input has the runat="server" you can set the value to whatever you wish, like this:
hiddenField.Value= ViewState["dropdownvalues"].ToString();
Finally, you can use JavaScript to get the values from the hidden field, like this:
<script type="text/javascript">
function test()
{
var name = document.getElementById('hiddenField').value;
alert(name)
}
</script>
I have a simple ASP.NET page with a MasterPage. Within the MasterPage, I have two login fields:
<input type="text" runat="server" id="txtUserName"/>
<input type="text" runat="server" id="txtPassword"/>
When the controls are rendered to the page, ASP.NET renders the following:
<input type="text" runat="server" id="ctl00_txtUserName" name="ctl00$txtUserName"/>
<input type="text" runat="server" id="ctl00_txtPassword" name="ctl00$txtPassword"/>
If I understand correctly, the name attribute corresponds to the UniqueID property of a control. However, when I'm debugging Page_Load and attempt to view the UniqueID of these fields, they have different values (ctl0$txtUserName and ctl0$txtPassword respectively)!
Note that this does not seem to be an issue on all pages using this MasterPage. Most of them work correctly and use ctl0$txtUserName and ctl0$txtPassword in both rendering and Page_Load.
Any idea what might cause ASP.NET to render a different UniqueID for a control than it uses in Page_Load?
I'm still not sure what was causing the generated UniqueIDs in the MasterPage to be different in Page_Load than when rendered to the page. However, I was able to get around the issue by storing the UniqueIDs of these fields in hidden fields. I was then able to access the values directly in the Request.Form collection.
In other words, I did this:
In the MasterPage -
<input type="text" runat="server" id="txtUserName"/>
<input type="text" runat="server" id="txtPassword"/>
<input type="hidden" id="txtUserNameUID" value="<%=txtUserName.UniqueID%>"/>
<input type="hidden" id="txtPasswordUID" value="<%=txtPassword.UniqueID%>"/>
During Page_Load of the child page -
string username = Request.Form[Request.Form["txtUserNameUID"]];
string password = Request.Form[Request.Form["txtPasswordUID"]];
Hope this helps anyone else struggling with UniqueID weirdness in ASP.NET!
Weird quirk I just became aware of: any wrapping controls that are runat server must also have IDs. For instance, if you have a panel around the control, i.e. whatever "ctl00" is, it must be assigned an ID. If it is not set, it will be allocated one and this can change.
Within an ASP.Net application I have, there is a textbox that gets a date from a CalendarExtender. When the textbox is populated it checks that date with another date on the form and displays a modalpopupextender popup if the dates are wrong. However, I DO NOT want to allow user input into this textbox, so when I set the ReadOnly field to false and tried Enabled to false, it doesn't allow manual entry however it ALSO disabled the postback and will not call the TextChanged event to fire the modalpopupextender.
So is there a way to disable manual entry and not set it to ReadOnly?
I figured it out, simply enter onkeypress="return false;" within the HTML tag
Try this
<asp:textbox id="txt1" onfocus="blur()" runat="server"/>
this worked for me.
Add the below properties in the tag of textbox
onkeydown="return false" onpaste="return false"
ex:
<asp:TextBox ID="TillDate_TextBox" runat="server" onkeydown="return false" onpaste="return false"></asp:TextBox>
the first property block typing in textbox and the second property block pasting in it
I'm not familiar with the exact components you are using, however the usual way to accomplish things like this is the following. Have selecting the date on the calendar modify the value of a hidden form field. This will restrict the user from editing the value directly. Then create another element like a div or a span, and use javascript to update the span/div to the value selected on the calendar.
I want to add a custom attribute to an asp.net RadioButton called Key which I'm using client-side for an ajax request.
What I'm finding is that my aspx markup which is the following:
<asp:RadioButton ID="rdoPost" GroupName=PreferredContactMethod" value="Post" onclick="DoStuff(this)" runat="server" />
gets rendered in the page as
<span Key="ContactMethod">
<input id="rdoPost" type="radio" name="PreferredContactMethod"" value="Post" onclick="DoStuff(this);" />
</span>
whereas I'd expected (and hoped) to get the following
<input id="rdoPost" type="radio" Key="ContactMethod" name="PreferredContactMethod"" value="Post" onclick="DoStuff(this);" />
I've tried the same thing with an asp TextBox control and it works exactly as I'd expect simply adding the Key="myKey" attribute to the <input type="text"/> element.
Is there a way around this with the standard RadioButton control, or will I have to inherit from the standard one to achieve the markup I'm wanting?
Also... (sorry to ask two questions at the same time), is adding non-standard attributes to html markup a bad idea anyway? Currently I'm using these attributes in JavaScript in the following way:
var key = rdoPost.Key;
I've found from the question/answer below that the easiest way to do this is via the code-behind using the InputAttributes property as follows:
rdoPost.InputAttributes.Add("class", "myCheckBoxClass");
Why does ASP.Net RadioButton and CheckBox render inside a Span?
i would like to know what exactly the difference between Html control
and asp.net web control. why do we need these two types of controls?
i have placed one html input text ,html button and asp.net text box AND ASP.NET BUTTON on my web page
<input id="Text1" type="text" />
<input id="Button2" type="button" value="button" />
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Button ID="Button1" runat="server" Text="Button" />
when i take view source, both are rendered similarly
<input id="Text1" type="text" />
<input id="Button2" type="button" value="button" />
<input name="TextBox1" type="text" id="TextBox1" />
<input type="submit" name="Button1" value="Button" id="Button1" />
what is the advantage of web control over html control.
I got some links in the internet,but not clear what exactly
they are used for.
http://www.extremeexperts.com/Net/FAQ/DiffBetweenServerandHTMLControls.aspx.
Could any one please explain the difference between these two controls.
First, if you drag an Html control from the Toolbox onto your design surface as in your example, the tag created does not include runat="server". That means it is native Html tag and not a .NET control. A native Html tag without the runat="server" has no server-side functionality. Thus, you could not set the value of the your "Text1" input tag in the code-behind.
Second, once you add the runat="server" to your Html input tag, you convert it from a native Html tag into a HtmlControl which derives from System.Web.UI.Control. Now the question could morph into the differences between something that derives from System.Web.UI.Control and System.Web.UI.WebControl. However, to specifically address your question, let's compare a standard input type="text" control to the TextBox control:
TextBox control can be access from the code-behind where an input control cannot (not easily) which also means that you can wireup server-side events for a TextBox control whereas you cannot with a standard Html control.
A TextBox control automatically saves its value using ViewState.
A TextBox control can be skinned using a Theme and .skin file whereas a native Html control cannot.
A TextBox can render as either an input type="text" control or a textarea depending on its TextMode property.
A TextBox control can participate in validation using validators.
Last but not least, the TextBox control can use control adapters to render differently in different browsers if required. See http://msdn.microsoft.com/en-us/magazine/cc163543.aspx.
Now, all that said, if you do not need any of WebControl capabilities, then using an native Html control is substantially leaner. In your example, you simply dragged two empty controls onto your design surface. If that is all you needed then using the .NET control would be overkill. However, as you start adding AutoComplete and server-side events and such, the full content, Javascript and all, of what gets to the Browser is much larger.
In short HTML controls don't persist their state while Postbacks. On the other hand ASP.Net control provides you to luxury to have their state saved while several Postbacks automatically. Different while using ASP.Net control instead of HTML element is:
<input type="hidden" name="__VIEWSTATE" value="dDwtNTI0ODU5MDE1Ozs+.................." />
This hidden field is auto generated by ASP.Net and it contains all you controls state in value attribute.
The server controls have a runat="server" attribute which enables you to provide server-side logic for these controls in the code-behind. You can also add this attribute to existing HTML controls to gain this same functionality.
The HTML controls are simple controls that correspond directly to HTML elements.
The ASP.NET Web Controls abstract the HTML elements, and generally provide more control over styling (though some would call this a bad thing).