I have a asp.net page that has several form elements.
<input type="hidden" id="myID" runat="server"/>
I am running these at the server level because I need to assign values to them.
The Asp.net engine is auto assigning ids and names, overriding my specified ID.
For purposes of my application I have to have specific IDs on these fields. Since this is an older version of .Net <4 I can not use the ClientIDMode=Static value.
Is there anyway that I can force static IDs?
The ability to assign static values is new to .net version 4.0 but you can get the value assigned to controls and pass that to other bits of JavaScript.
Create your own hidden controls with the IDs and Names that you want. Use some simple JavaScript on your form submission to copy values from the server side controls to your controls.
<form id="MyForm">
<asp:TextBox ID=MyTextBox" runat="server" />
<input type="hidden" id="MyFixedID" name="MyFixedName" />
<asp:Button ID="MyButton" runat="server" Text="Go!" />
</form>
function fred() {
$("#<%=MyButton.ClientID %>").Click(function() {
$("#MyFixedID").val($("#<%=MyTextBox.ClientID %>").val());
$("#MyForm").submit()
});
}
I have also used ScriptManager.RegisterStartupScript() or ScriptManager.RegisterClientScriptBlock() to emit JavaScript and pass the server side Control.ClientID as a parameter to a function defined within a <script> block.
Related
I'm new to ASP.NET (building for Sitefinity) and working on a Salesforce form for a client. Some of their inputs looks like this:
<input id="00N1600000Ernn3" maxlength="50" name="00N1600000Ernn3" size="20" type="text" />
So I created an input in asp like this:
<asp:TextBox ID="00N1600000Ernn3" MaxLength="50" runat="server" ClientIDMode="Static" />
When I compile I see this error coming from the designer file:
invalid token '00' in class, struct, or interface member declaration
If I switch the id to a start with a character it fixes the issue. My problem is Salesforce uses that as the name when submitted to update their database and analytics.
The Control ID is used to generate a property in the 'designer' file. Therefore, the ID must conform to the naming rules for identifiers. These rules specify that the identifier must start with a letter:
https://msdn.microsoft.com/en-us/library/aa664670(VS.71).aspx
Sitefinity does have a Salesforce Connector tool but the use of that module is tied to what license your client is using. One approach I've taken is instead of trying to match the ids of the Salesforce form, you can just paste the form html in a user control and then register that user control as a widget in Sitefinity using Thunder.
You may have to add in a button control to specify the postback url for the form:
<asp:Button runat="server" ID="btnSubmit" PostBackUrl="https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8" Text="Submit" />
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" />
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.
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).