Changing Label to TextBox on Run-Time

[Claude2005]

Hi there,

First, my code:

<asp:Table>
    <asp:TableRow>
        <asp:TableCell>Name:</asp:TableCell>
        <asp:TableCell><asp:Label>John Doe</asp:Label></asp:TableCell>
    </asp:TableRow>
</asp:Table>

I want to change the Label Control to a Textbox Control once I've triggered a Button.Click event. So my output will be:

<asp:Table>
    <asp:TableRow>
        <asp:TableCell>Name:</asp:TableCell>
        <asp:TableCell><asp:TextBox>John Doe</asp:TextBox></asp:TableCell>
    </asp:TableRow>
</asp:Table>

Is this possible?

EDIT: The label part is for display the information from the database. I'm using a button as a trigger to edit that label by changing it to a textbox and I'll be using another button as a trigger to save the changes made in the textbox and then changing it back to a label.

[gep13]

Hey,

It should as though you are trying to provide the ability to have a ReadOnly version of the data, and then on click on a button, switch into edit mode. Does that sum it up?

Are you familiar with the FormView control? This gives you the ability to have a readonly version of content, and then a edit and insert version. This is handled through the use of Templates, namely the ItemTemplate, EditTemplate, and InsertItemTemplate.

You can find information about this here:

http://msdn.microsoft.com/en-us/libr...w_members.aspx

and an example here:

http://msdn.microsoft.com/en-us/libr...w4(VS.80).aspx

You may also want to think about the DetailsView, which offers similar functionality.

Hope that helps!!

Gary

[Claude2005]

Yep, you got it right

Never heard of these before. I'm thinking of a CSS-approach. On ReadOnly mode, hide the textbox and reveal the label. And on Edit mode, hide the label and reveal the textbox.

I'll still try learning the controls that you have mentioned. Thanks again and I'll see what I can do.

[gep13]

Hey,

In this case, I would say don't re-invent the wheel. These controls have been created for a reason, so unless you have a compelling reason to not use them, I would say give them a try.

Gary

[Claude2005]

Will do, thanks again.

[gep13]

Hey,

Not a problem at all.

Let me know if you have any other specific questions.

Gary

[SeanGrebey]

Why not just make the TextBox readonly?

MyTextBox.ReadOnly = true

and then change it to false when you click the button?

[gep13]

Hey,

A ReadOnly TextBox is essentially a Label, and as such, in my opinion, a label is the correct control to use.

Gary

[SeanGrebey]

Hey,

A ReadOnly TextBox is essentially a Label, and as such, in my opinion, a label is the correct control to use.

Gary

Sure, but he wants to change it to a text box after clicking a button so it is editable, which a label won't do. So I guess I don't understand doing multiple controls for what you can do with one.

[gep13]

Hey,

I think you might be missing the concept that I was trying to suggest.

The FormView has multiple templates, as I mentioned. Let's say in the ItemTemplate, you have two labels, one called NameLabel, and NameValueLabel. At runtime, this would look like:

Name: Gary

Here, the text "Gary" would be taken from a database, for example. Then, you click the Edit button, and you put the FormView into Edit mode, which then displays the EditItemTemplate. This contains one label and one TextBox. At this point, you see the same information, i.e:

Name: Gary

However, in this case, the text "Gary" is contained within a TextBox, that the user can update. At this point, the FormView then displays two new buttons, cancel and update. Cancel puts the FormView back into ItemTemplate mode, however, Update will then take the changes that have been made to the TextBox, and persist them back into the database.

This functionality then gets extended when you have multiple things that you want to edit. The EditItemTemplate can show DropDownLists, FileUpload, RichTextBox or other controls, all of which are used to allow the user to input the data that they want to.

Gary

[Claude2005]

Why not just make the TextBox readonly?

MyTextBox.ReadOnly = true

and then change it to false when you click the button?

Doing that, for me, is not elegant enough. I like my project to be Facebook-like, when you view your profile, there isn't a textbox. When you edit your profile, now you'll see a bunch textboxes.

Hey,

I think you might be missing the concept that I was trying to suggest.

The FormView has multiple templates, as I mentioned. Let's say in the ItemTemplate, you have two labels, one called NameLabel, and NameValueLabel. At runtime, this would look like:

Name: Gary

Here, the text "Gary" would be taken from a database, for example. Then, you click the Edit button, and you put the FormView into Edit mode, which then displays the EditItemTemplate. This contains one label and one TextBox. At this point, you see the same information, i.e:

Name: Gary

However, in this case, the text "Gary" is contained within a TextBox, that the user can update. At this point, the FormView then displays two new buttons, cancel and update. Cancel puts the FormView back into ItemTemplate mode, however, Update will then take the changes that have been made to the TextBox, and persist them back into the database.

This functionality then gets extended when you have multiple things that you want to edit. The EditItemTemplate can show DropDownLists, FileUpload, RichTextBox or other controls, all of which are used to allow the user to input the data that they want to.

Gary

Wow nice, that's pretty sums up the articles, which I have read and still I can't understand...

Thanks again

[Claude2005]

So when are you going to use FormView and DetailsView?

When is FormView more applicable than DetailsView? and vice versa?

EDIT:

Can I connect to multiple databases using only one FormView?

Can I use an external control, let say a button, to manipulate the FormView, changing it from View Mode to Edit Mode and vice versa?

If yes, how?

If no, can I change the LinkButtons to a simple button / image button?

[gep13]

Wow nice, that's pretty sums up the articles, which I have read and still I can't understand...

Thanks again

Not a problem at all.

Gary

[gep13]

So when are you going to use FormView and DetailsView?

When is FormView more applicable than DetailsView? and vice versa?

EDIT:

Can I connect to multiple databases using only one FormView?

Can I use an external control, let say a button, to manipulate the FormView, changing it from View Mode to Edit Mode and vice versa?

If yes, how?

If no, can I change the LinkButtons to a simple button / image button?

Hey,

DetailsView is normally used in conjunction with a GridView, and it is used to show more details about a row within the GridView, however, there is nothing to stop you using it stand alone.

Ok, I have to ask, why would you need it to be used to target multiple databases? Normally, you data is stored in one database, and written back to another. You could have it connect to different databases, what you would have to take more manual control over it.

If you add an ImageButton to one of the templates, you can set the CommandName property of the Button to either Update, Edit, Cancel etc. This will then alter the current mode of the FormView. You can see an example of this here:

http://weblogs.asp.net/anasghanem/ar...te-markup.aspx

Gary

[Claude2005]

Ok, I have to ask, why would you need it to be used to target multiple databases? Normally, you data is stored in one database, and written back to another. You could have it connect to different databases, what you would have to take more manual control over it.

The previous project I have that has its own database, which holds the employee's ID and employee's name for example. The current project also has its own database. They have both different application, the previous one is for holding personnel information of each employees and the current one process the leave credits of the employees.

The only field that is linking the two databases is the Employee's ID field. I don't want to copy the employee's name from the first database because I'm avoiding redundancy to save space.

Or is it a better idea to combine the two databases into one? Doesn't that make traffic? Does it make a difference, in traffic, if I'm using two databases instead of one?

[gep13]

Hey,

Logically, it would make sense to have just one database. This would make more sense going forward in terms of maintenance and scalability.

Gary

[Claude2005]

It seems I've being taught in a wrong way...

[savior14]

an alternative solution i think is put a

textbox (which is hidden style="visibility:hidden; display:none")

beside the

label (which at the first is visible style="visibility:visible;")

Then on button click set the

label's property to style="visibility:hidden; display:none"

then set the

textbox to style="visibility:visible;"

[Claude2005]

an alternative solution i think is put a

textbox (which is hidden style="visibility:hidden; display:none")

beside the

label (which at the first is visible style="visibility:visible;")

Then on button click set the

label's property to style="visibility:hidden; display:none"

then set the

textbox to style="visibility:visible;"

Ah ok, you just expanded what I have said...

I'm thinking of a CSS-approach. On ReadOnly mode, hide the textbox and reveal the label. And on Edit mode, hide the label and reveal the textbox.

[gep13]

Hey,

Does that mean you are not going down the route of using the built in controls for this purpose?

Gary

[Claude2005]

Hi there,

Uh don't get me wrong... I'm still in the middle of understanding what FormView is...

I'm just stating that he's just expanding what I've said earlier in my previous post

Cheers!

[gep13]

Ah, ok, my bad.

Gary

[mendhak]

Or is it a better idea to combine the two databases into one? Doesn't that make traffic? Does it make a difference, in traffic, if I'm using two databases instead of one?

It's not that simple. If they're for separate applications, I'd keep them separate. You don't want to pollute app1's database with your app2 information, do you? Are app1 and app2 strongly tied together? If they're not, then keep them separate because if you start adding your app2's database objects to app1's database, then you run the risk of breaking something if you don't understand the first database.

If they're strongly tied together and are 'practically' the same app, then you could combine them but study app1's database well first.

Data duplication across the databases isn't a very big deal here - you could set up an SSIS package that regularly pulls data from the employee table and into app2's own table with the same information. This reduces the risk of failure because in the current scenario if they decide to revamp the database, your code breaks and the app stops working. If you duplicate the data and keep it with you in app2's database, even if they revamp app1's database, you still have records up to a certain point which gives you time to sort the issues out, but still lets users use the app.

Ideally, if this information is important, I'd make app1 expose a web service that app2 uses to get the information needed out.

[Claude2005]

It's not that simple. If they're for separate applications, I'd keep them separate. You don't want to pollute app1's database with your app2 information, do you? Are app1 and app2 strongly tied together? If they're not, then keep them separate because if you start adding your app2's database objects to app1's database, then you run the risk of breaking something if you don't understand the first database.

If they're strongly tied together and are 'practically' the same app, then you could combine them but study app1's database well first.

Data duplication across the databases isn't a very big deal here - you could set up an SSIS package that regularly pulls data from the employee table and into app2's own table with the same information. This reduces the risk of failure because in the current scenario if they decide to revamp the database, your code breaks and the app stops working. If you duplicate the data and keep it with you in app2's database, even if they revamp app1's database, you still have records up to a certain point which gives you time to sort the issues out, but still lets users use the app.

Ideally, if this information is important, I'd make app1 expose a web service that app2 uses to get the information needed out.

My app1 database holds personnel information. It's kinda long, for me the average time to fill-up all information is approximately 20 minutes. If you put it in paper, seven pages legal size coupon bonds of nothing but personnel information.

My app2 database holds leave credits for personnel/employees. They can use this to get a paid day-off. I'm just using app1 database to retrieve the Last Name, First Name and Middle Name, Salary fields. The only field that is linking the two database is the employee ID number field. I don't want to repeat those fields on my app2 database to save space.

A web page (edit.aspx running on app2) is made so that you can edit the salary field from the app1 database and the leave credits on the app2 database. I've made it like this for convenience sake on the part of my users in our HR office. They don't have to use my app1 to make changes on just one field.

By the way, it's not just leave credits on app2, there's a lot more function to be added here so I kept them separated.

I've got the hang of using and designing the FormView control, but only using one database. I'm having problems in using more than one database for it seems, FormView is limited to only one database.