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)
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.
In my project I want to run 2 forms in one webpage which is master page one is for contact us and one is for signup user. but multiple server side forms are not allowed. is there any solution for fix it?
You can use postback ability of Asp.net Webforms.
You should create one button for singup and another one for contact. You can catch event in server side and you do what want to do.
You can create regular client side forms created using HTML in the master page, and use the Request.Form to read the posted data. For this to work, all the input elements must have a name, and you can read them using Request.Form["ElementName"].
Take into account that forms cannot be nested.
So, your master page needs to llok like this
...
<body>
<form id="form1" runat="server">
</form>
<form id="contact" action="Contact.aspx" method="post">
<input type="text" name="Message"/>
<input type="submit" value="Contact us!"/>
</form>
</body>
The first <form> is the regular ASP.NET server side form, which supports server side components
The second <form> is a custom HTML form. It doesn't have the runat="server" attribute, and it's outside the server side <form>.
The second form action points to a .aspx page. In its page load event you can use the Request.Form["Name"] to acces the name of the contact form. Note that you also need to include a submit button to send the data to the server, and a method="post" to specify the method to send the page.
This is resorting to "basic" HTML controls, so there is no View State, and the posted values will be lost if they're not reset in the server. I.e. if the form is posted, and there's an error, the previously posted values will be lost when rendering the page again.
If you want to make it more sophisticated you can use Javascript and, optionally AJAX. But that's a more complex solution. See this for an example.
ASP.NET Forms only supports one form. You could use an iFrame and render your second page (second form) inside of the iFrame.
Here is an interesting post about placing some page content after the tag. This may be helpful to you.
http://forums.asp.net/t/1611822.aspx?Dynamically+adding+content+to+page+outside+of+the+aspnet+form+from+within+a+UC
I have a web page where I dynamically generate lots of elements from code behind and inject them into the page, as such:
input type="file" style="width:480px;" id="fileUploadLogo345">
I also have buttons for submitting, like this:
input id="Submit1" type="submit" value="Substituir Logo" onclick="return jsSubmitLogo(345);">
(The javascript function always returns true...)
No matter what I try, I am unable to get any of the uploaded files from code behind.
I tried adding enctype="multipart/form-data" to the form, I tried adding runat="server" to the file upload controls, I have no idea what else I could try. No matter what I do, in code behind Request.Files.Count equals zero.
Any idea what I could be doing wrong?
If it makes any difference, I am using a master page...
Thanks
You are using "id" attributes in your html... you should instead use "name" attributes, and everything will show up fine in code behind.
Situation: I have been creating webpages in HTML5/CSS3 & Javascript using Sublime 2 text editor for a year, however a college course now requires me to use Asp.Net and Visual Studio 2010. I do not use the designer because I am proficient at doing things by hand, however I find that writing asp: inside every element is time consuming and causes syntax errors when applied to some HTML 5 tags and not others.
Example HTML 5: <button id="btn" type="submit" value="Button"/>
Example Asp.net: <asp:Button ID="Button1" runat="server" Text="Button" />
Question: Can the asp: portion be omitted without effecting anything or is it required for IIS or the C# back-end functionality? What about runat="server" can that be omitted?
Google has come up dry regarding my inquiry, so any help is appreciated.
you simply cannot remove either of the two
but hear me out why, because I have a feeling you are not familiar with ASP and therefor are mistaking the meaning of the asp: and the runat="server" syntax.
first: runat="server"
this property on an element, tells the the compiler that this is actually a server side control
so a <button/> is not the same as an <button runat="server"/>
the first one is pure html, while the second one is a control, which can be bound to on the server side. .Net will give it a clientID (not to be mistaken by the ID you have to give it yourself).
second: asp:
this is a prefix, on certain elements, that tells the compiler these are ASP controls (the default controls given by the ASP.net framework). These include Buttons, TextBoxes, DropDownLists, ...
do not mistake 1 of these with a html element.
an <asp:Button id="myAspButton" runat="server"/>
is not the same as a <button id="myHtmlButton"/>
the first, is a server side control, which can be bound to (see it's runat="server" attribute), and this control renders to the browser as a <input type="submit"/> for example.
you could alter the rendering of the asp.net button class to make it return something entirely differnt if you wish.
and you are also not limited to using asp.net classes.
you can create your own controls, and put them in a custom created library
you could give those your own prefix.
if I created such a custom control, I could register a prefix for it in the web.config file,
and thus I could create a custom button extending from the original one (but with a default label in front...
<myc:CustomButton ID="myButton" Text="myButton" Label="myLabel" runat="server"/>
which could render into:
<label>myLabel</label>
<button ID="*******">myButton</button>
the asterisks are symbolizing the Unique ID it will get from the .net framework
if you want to know more on custom controls, or extending default controls
here is a step by step explanation to create custom controls, or extend from a TextBox control.
it also shows how you add a custom prefix for your controls (in the this case 'cc')
you can find more info here
The runat="server" part is required to tell .NET that it will have to render a button there (which will contain .NET specific ID for processing upon POST). Not too familiar with web forms (I started with MVC), but I would assume that the asp: part is to help distinguish between server controls and standard HTML markup.
Why not try removing it and if it breaks something, then you know it's needed. For instance if the button doesn't show up after removing it, then obviously the .NET markup parser needs it to be there in order to know that it is a place holder for a server control.
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.