From my page's code-behind I want to access the value of this hidden field. The value is set properly. I confirmed by checking its value.
<div class="hiddenValues">
<input id="HiddenReportId" type="hidden" />
</div>
From my code behind, I'm using the following to access the above input
string id = Request.Form["HiddenReportId"];
When I run the application this line throws a null exception. Any suggestions ? Thanks!
The input needs to be inside of the form tag (which it may be, can't tell from the code snippet). Also, it needs to have a name attribute:
<div class="hiddenValues">
<input id="HiddenReportId" name="HiddenReportId" type="hidden" />
</div>
Its id attribute may be redundant and isn't necessary if you're not using it. But form elements are identified by their name attributes in a POST.
(It feels a bit unintuitive from an ASP.NET perspective to the uninitiated, I know. ASP.NET convention is to identify everything by an ID, but web browsers use name when crafting a POST. And the web browser knows nothing of the server-side technology being used, it follows HTTP standards instead.)
Related
Should I use ASP elements with a runat="server" attribute or an HTML form?
It seems like using ASP tags such as <asp:TextBox> is much more comfortable since I don't have to redirect the user to another page on a form submition, but also from what I've seen, it seemed like HTML forms are the more accepted way. I was starting to wonder if using ASP elements increases server load or has any other disadvantage?
In case I should use ASP elements, how do I validate the input with Javascript before sending it to the server?
In case I should use HTML forms, how do I not redirect the user on submition and also not run the server code on page load?
You can easily use the HTML5 input type in Web Forms by adding the runat="server" attribute, so that it can be accessed on the server-side:
<label for="name">Name:</label>
<input type="text" id="name" name="name" required
minlength="4" maxlength="8" size="10" runat="server">
Note, on the server-side you will access it via the Value property of the input element, not with the Text property of a typical ASP.NET textbox control.
Contrary to what a lot of people think, ViewState only ever becomes a problem when people do silly things like nesting data-bound controls, in which case it can become bloated very quickly.
Not sure what you're asking regarding validation... but you still have options like this on both client and server. If you're working with an existing Web Forms project, I would stick with regular ASP.NET controls and keep it simple. This way, you can have out-of-the-box validation on both client and server.
I know I can eliminate ID mangling in ASP.NET 4.0, but can I also eliminate name mangling? This looks like the best I can do:
<input name="ctl00$body$txtName" type="text" id="txtName" />
Is that correct?
ASP.NET relies on name mangling to route posted form data to input controls in nested naming containers. The ways to avoid name mangling are:
Don't use nested naming containers such as master pages or user controls. Input controls that are placed directly on an .aspx page will have simple names.
Don't use the standard ASP.NET input controls. Instead, you could:
Put <input type="text" name="name" /> (without runat="server") in the .ascx/.aspx and access its value via Request.Form["name"].
Create a custom server control that does the same.
Ok, so here's the deal. I needed to change the values of form elements dynamically (server side), I need to keep the MasterPage, and I have panels on the page as well. There is no way around it.
What I have done instead, is use server side "yellow tags", and public variables:
HTML:
<input type='hidden' name='x_login' id='x_login' value="<%= x_login %>" />
Code:
Public x_login As String = "some value"
And to access the value after a postback:
Request.Form("x_login")
Thanks to Michael Liu's answer for the very last bit there. I've upvoted his answer just for that reason.
According to MSDN and the MCTS self-paced training, asp.net can use Hidden fields for client-side state management. The book material goes on to say view-state is more secure than hidden fields because the data is encrypted.
I must be missing something here. I setup a Label and made it hidden. I can store data in this hidden label and it won't even be sent to the client browser. This not only works like server side state (note the runat=server), but this seems more secure than view-state because there's no need for encryption as the client can't even see the field.
<asp:Label ID="Label1" Visible="false" runat="server">secret info</asp:Label>
Contrast this with an HTML input field. Here, the client state info makes sense.
<input id="Text2" type="text" style="visibility:hidden;" value="secret 99" />
So what's the deal?
When you create a label in .net and set it's visibility to Hidden, it does not render to the client and its data is stored in viewstate.
Therefore, it is not "more" secure than viewstate as it is using viewstate to maintain the data.
Regarding hidden fields, there are four kinds: First up is the regular HTML one which is simply an input of type hidden. This has no visible rendering although it is in the html. It also has no viewstate properties. It is declared as:
<input id="MyId" type='hidden' value='whatever' />
The second one is a regular input with a css property marking it as hidden: If CSS is disabled or otherwise overriden then the control would be visible to the user. Other than that its pretty close to the same thing as a type='hidden'.
<input id='MyId' type='text' value='whatever' style='visibility:hidden' />
The third one is the .Net hidden field. This does has viewstate storage, but it also causes a regular hidden field to be generated in the html.
<asp:HiddenField id='MyId' runat='server' value='whatever' />
And, the fourth one is a regular .net text box that is marked as not-visible.
<asp:TextBox id='MyId' runat='server' Text='whatever' Visible='False' />
The .net ones will cause data to be placed in viewstate. The HTML ones do not. If you set Visible=False on a .Net control then it is not rendered to the client however it's data is typically stored in viewstate.
There are other ways of throwing data into the page, but they are derivations of the above.
Generally speaking if you have a value that your javascript code needs but you don't need to display it to the client then you use a hidden field (html or .net). If you have a secret value then typically you don't want this to go to the client side if at all possible. And that means even keeping it out of viewstate. As a side note, don't depend on viewstate "security' there are tools out there which will easily decrypt it.
A field which is not displayed is not a hidden field (even though it is "hidden").
Hidden fields are <input type="hidden" name="somename" value="somevalue" /> fields. And those can be manipulated by users.
As I understand it, the <input type=email> element in HTML5 will render as a simple text field in browsers that do not support the tag. On other browsers it will render properly, like on the iPhone it will bring up the e-mail keyboard layout.
I’d like to use this in a project but my input fields are <asp:TextBox> controls. How can I use the HTML5 element but still access its data server-side like the rest of my fields?
There is an update for .NET framework 4 which allows you to specify the type attribute
http://support.microsoft.com/kb/2468871.
See feature 3 way down the page
Feature 3
New syntax lets you define a
TextBox control that is HTML5
compatible. For example, the following
code defines a TextBox control that is
HTML5 compatible:
<asp:TextBox runat="server" type="some-HTML5-type" />
you can try adding the attributes manually, like:
TextBox1.Attributes["type"] = "email";
TextBox1.Attributes["type"] = "url";
TextBox1.Attributes["type"] = "number";
Sorry I'm a bit late to the party, though I think that others can benefit from what I did. I have a page which is HTML 5 though we still have .NET 3.5. We wanted to keep the .NET element, though have the type change to email. I've tried several methods (including Milox above) to no avail, though the one which worked for me was the following: I added a JavaScript property to the element itself inline (when I put it in a script tag it wouldn't pick up for some reason...)
Here is what your tag would look like if you use my changes:
<asp:TextBox runat="server" type="email" onfocus="this.type='email'"/>
Eli
Whether or not it is accessible as a server control, you should be able to access the HttpRequest.Form collection and retrieve the value. No matter what the browser does with the tag, it has to submit a string to the server.
in your .aspx file add
<input type="text" required autofocus placeholder="Email Address"
class="txt-input txt-input-username" ID="myTextBox" runat="server"/>
in your Code Behind .cs
myTextBox.Attributes["type"] = "email";
This Worked For Me
You need to create your own custom control and override the Render routines. Feel free to use either the source code or DLLs
I have several elements in my web page generated by JavaScript.
Here's an example of such content:
<input id="uploadfile01" type="file" onchange="change(1);" />
<input id="uploadfile02" type="file" onchange="change(2);" />
My question is:
How can I interact with these elements in the server side, (Asp.net) after a post?
(Since the elements were dynamically generated they do not exist in the original asp.net page)
I dont think that would be possible.....if i am not mistaken you want to give the option to attach multiple files. i think it would be better to place a set number of fileupload controls and set there display to none and you can use javascript to show them.
i know that this is not what you are looking for but after a postback the controls will be lost and even if they are added again they will lose there contents.(had you been generating them through code behind)