Sorry for the newbie post, but i am from a PHP world. Im now learning ASP.NET.
Im having a bit of problem figuring out how to get/post a variable on an input field. All i want to do is, get the value from an input form and display it again on the page.
Here's my code..
<form id="form1" runat="server" acceptcharset="utf-8">
Your name:<input id="name" name="name" type="text" /> <asp:Button ID="Button1" runat="server" Text="Button" PostBackUrl="Default.aspx" />
All i want is to get the value of name and display it on the page it self. How can i do that?
On PHP, i would normally do is..
$name = $_POST["name"];
Please help, thanks.
I am a PHP Developer, Now learning ASP.NET. I want to be an ASP.NET Developer soon!
Either replace the Input with an ASP:Texbox whihc generates an HTML Input Element or add the runat attribute to the existing input element to instantiat an HTMLServer control.
<input id="name" name="name" type="text" runat="server"/>
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox></div>
then access in your coed behind with the ID
Response.Write("Textbox text is " & Me.TextBox1.Text)
For the benefit of all users please mark any post answers as appropriate.
You would use Request.Form["name"] or even Request["name"] to get the field, assuming that you're working in C# (use () for indexers in Visual Basic).
You might also want to consider replacing your HTML only <input> element with an <asp:TextBox>, as this will
a. Enable the control to remember its value between postbacks, and
b. Mean that you can access the content of the TextBox simply by using it's Text property (e.g.) name.Text.
Finally, the equivalent to echo $name is Response.Write() in ASP.NET. However, this is a really, really bad thing to do, due to the nature of the page event cycle that happens on the server. In ASP.NET, pages prepare themselves for rendering (by handling events such as Init, Load, button Click events, and so on), and then the page is rendered in the Render event, which occurs towards the end of the event cycle.
The page maintains a tree of controls, and calls there Render methods in turn.
Thus, using Response.Write() in, say, a Page's Load event handler will cause the output to be generated before the page really renders itself, which means that your output will appear before such exciting items as the DOCTYPE declaration. And that's bad.
Therefore, it would be much better to use a Label or other display control to display the output (in the case of the Label, you could simply set its Text property to the Text property of an ASP.NET TextBox.
Understanding the Page event cycle is absolutely critical to being able to write ASP.NET pages. In fact, it's arguably the number one thing to get your head around, so if your moving from PHP, I'd be tempted to read Fritz Onion's excellent ASP.NET books (either for ASP.NET 1 or ASP.NET 2, depending on which version you're using), because it covers how ASP.NET processes requests better than any other book I've seen.
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox><br />
<asp:Button ID="Button1" runat="server" Text="Button1" OnClick="Button1_Click" PostBackUrl="~/Default2.aspx" />
add <%@ PreviousPageType VirtualPath ="~/Default.aspx" %> to Default2
public partial class Default2 : System.Web.UI.Page
protected void Page_Load(object sender, EventArgs e)
I think that implementing a cross page postback is more than over the top for simply displaying the value of an input text on a page, and wouldn't recommend it at all in this case. The earlier posts already cover how to post back and read the value within a form, and that should more than suffice.
Secondly, using FindControl is very poor programming practice and should be avoided wherever possible. It introduces a level of coupling between the classes (or pages, if you must) which really should not be allowed to propagate in code. To be honest, the <%@ PreviousPageType %> directive, when used with a VirtualPath attribute, is also a pretty ropey idea, and again should be avoided where possible.
thank you so much for your kind advice, it does make sense