Copy values from one form to another

[robertfah]

I've got a form that resides in a tab control. The user can create many of these forms and each time they open a new tab. One ability that we've given the user is the ability to "Dock" and "Undock" the form from the tab control. I am looking for a way to transfer the data from when the form goes from being Docked to Undocked (or vise versa). Basically in code, all I'm doing is creating a new instance of the same form but with a border and some other properties set if they choose undock. I know I can do the standard:

frmUndocked.txtName.Test = frmDocked.txtName.Text
etc.

But I have close to 30 controls that the user could have input on and was looking for a better way. I was thinking of looping through each control on the form but again, there are controls within controls, within controls (a group control houses another tab control which hold a gridview, etc.).

Thoughts/ideas as to how I can do this?

 

[Rhys666]

It depends on your data structures behind the form(s). If you have an (business) object hierarchy this should be a simple task, if you've bind directly to an underlying data source, (such as a SqlDataSource), you're probably going to have to rethink and redesign your 'undocking' implementation to keep as much code re-use as possible.

Rhys

"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it"
Terry Pratchett

 

[jmeckley]

it's not so much about re-use as it is encapsulation and adaptation to change. the more details about an object that are publicly exposed/required the more difficult it will be to change that object when requirements change.

by encapsulating the details of the process into an object it will be easier to alter the system when required to do so.

I like the concept of an event broker for this type of scenario. In it's simplest form
1. there is an event broker object, usually a singleton.
2. objects can (un)register with the event broker to listen for a triggered event. not a .Net event, just an action occurring in the system.
3. when an event is triggered the broker will get all the registered listeners for that particular action and notify them.
3. when the objects get the notification they can act on it however they would like.

with this setup no two objects need to know about each other. the event broker doesn't know the details about how each listener will use the information, it just lets them know an event took place.

here is a simple example I created using Castle Windsor.

http://docs.castleproject.org/Windsor.Extensibility_Sample_App_EventBrokerFacility.ashx

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[Qik3Coder]

Robert,

I'm lazy. I don't know how you're currently populating the form, but I usually have something like LoadData(int i).

Pass the key(s) to the new form and the call it's LoadData(), which you would have called when you initially loaded the form.

If this is a windows based application, database hits are relatively cheap, and you might as well get a clean copy of the data.

Lodlaiden


I haz all the letters: SME, BA, QA, PM, DEV, DBA, UAT, SE, HD

 

[robertfah]

Robert,

I'm lazy. I don't know how you're currently populating the form, but I usually have something like LoadData(int i).

Pass the key(s) to the new form and the call it's LoadData(), which you would have called when you initially loaded the form.

If this is a windows based application, database hits are relatively cheap, and you might as well get a clean copy of the data.

Lodlaiden

This is ideal but here's a scenario where it doesn't work: a user opens a form (a new help desk ticket) and enters some data.....that data is not saved to the DB yet. They click "Undock" and now I need that "unsaved" data to show in the new window.

 

[Qik3Coder]

Here's where code reuse comes into play.
1.) Is the same form on each of these windows?
[tab]This would allow you to pass the existing form to the new window.
2.) Do you use a data class and bind the form controls to the data class to reduce "data loading"?
[tab]This is a slightly cleaner variant on the prior.
3.)Are the controls named the same thing on each of the forms?
[tab]You could do a lazy double for loop, to pupulate the new controls.


Just some random thoughts,
Lodlaiden

You've got questions and source code. We want both!

 

[robertfah]

Here's where code reuse comes into play.
1.) Is the same form on each of these windows?
This would allow you to pass the existing form to the new window.
2.) Do you use a data class and bind the form controls to the data class to reduce "data loading"?
This is a slightly cleaner variant on the prior.
3.)Are the controls named the same thing on each of the forms?
You could do a lazy double for loop, to pupulate the new controls.

1.) Yes, there is 1 form (frmIssue) and everytime a form gets created and added to the tab control, it's just a new instance of this form.
2.) Yes.
3.) Yes, it's the same form.

I was going to create a user control and put the controls in that, then simply add/remove the user control to and from a basic form. But I got to thinking about it and a Form is a type of control so why not just use that? So what I ended up doing was undocking the form from the tab control (making it's parent the main program, not the tab control) and when they dock it, I make the parent the tab control and not the main program (along with w few other things). This keeps the form in the same state regardless of being docked or undocked.