Adding a datarow to another form's dataset.

[jswota]

Hi,

I have a VB.Net application. In it i have a Contacts form that has a Contacts grid that is bound to a DataSet on the same form. What i am trying to do is display a 'New Contact Wizard' when the user clicks the 'New Contact' menu item. The wizard is a separate form that will allow the user to add all of the new contact info. When the user clicks OK i want the wizard to return a new contact datarow to the Contacts table on the Contacts form. I am doing this by using a property in the wizard called Contact. This property returns a Contact data row with the new info. If the user clicks OK in the wizard then the Contact should be added to the Contacts datatable. The problem that i am having is that however i code the wizard to create the new contact datarow, i always get an error that the row already belongs to another table.

I need the wizard, so i need to either have the wizard create the new contact row from scratch or i could also pass the new row to the wizard from the Contacts form. I would then need to add databinding to my wizard's editors.

Could someone please shed some let on this? How would you guys do it - using a wizard please?

Thanks,
Joel

 

[jmcilhinney]

Why does the wizard have to return a DataRow? Why does the wizard have to care where the data is going to go? All the wizard has to do is make the data entered by the user available. The form that contains the grid can then create the DataRow, populate its fields and add the row to the table. That is how inter-form communication should pretty much always be done: only one form should have to know about the other. This relates to the "single responsibility principle": the wizard's single responsibility should be to accept the information from the user. The responsibility of knowing how to make use of that data should lie elsewhere. A further advantage is then that you could use that same dialogue elsewhere and the fact that the data might be used in a different way would not matter to the dialogue, i.e. the gathering of the data is decoupled from the usage of the data.

 

[GoldDust]

Hi, i perhaps wouldn't go about it in the same way, but if you cloned the row and passed the new object back it might work.

This link has an example on cloning and preserving values:
DataGridViewRow.Clone Method (System.Windows.Forms)

 

[jswota]

Thanks for the replies. I made a small change to the wizard's constructor that accepts the datatable. This way the wizard can simply manage the new or modified data accordingly. The wizards i have are specific for the data they modify and i am not concerned about reusibililty in other apps. This is why i decided to keep all of my add and update code in the wizard itself.

Thanks again for the help.

 

[jmcilhinney]

There are many, many occasions where things turn out differently to what we expect. If you use a good architecture to begin with then changes later on have less impact. We all start out doing the sort of thing that you just did because we don't know any better, but it is not the best way to construct an application.

 

[jswota]

The wizard is specifically designed to work with my Contacts data. I don't need to create a dynamic wizard that presents all of the necessary fields to retrieve user input for any datarow that i might need to add in the future. This is a rare situation. Most of my data is managed in grid controls and other bound controls. I am only using a wizard to provide some additional features that will assist the user when adding contact information. At the end of the day I need a new row added to the Contacts datatable. Instead of adding the necessary properties to the wizard to store the information about the contact, I have opted to simply use the strongly typed datarow to hold the values for me. This way I can pass the row back and fourth. Since the Contact form already has the data, this works great when I want to use the wizard to make changes to the info. I simply pass the current datarow to the wizard and the info is immediately available for updating. I don't have to set each datafield's corresponding wizard property with the current value. Whether adding or updating, the wizard executes the necessary action when the Finish button is clicked or does nothing if Cancel is selected.

I have considered several options on handling this and it just seems to me that if a contact is what I need, then a contact is what the wizard should provide. No point reinventing the strongly typed Contact datarow.

I don't want to sound stubborn but i've yet to be persuaded that I "don't know any better" or that I don't "know how to construct an application." - Thanks for that by the way. You should consider motivational speaking.

I am still really interested to see how some other people would handle this. If you have suggestions, then please keep them coming.

Thanks for the feedback,
Joel

 

[jmcilhinney]

You don't know what you don't know. I have a fair idea because I've been doing this for quite a while, and I now know what I didn't know when I was at a similar stage to you.

Here's an example of why an architecture like the one you're using is flawed. You are currently using a typed DataSet in your application. If you decide to switch to using the Entity Framework at some point, you will have to change code in your wizard form to handle that. If you design the app the way I'm suggesting, your wizard form would be unaffected by such a change.

I'm not saying that what you're doing now won't work, but there is a reason that design patterns exist and are used by lots of professional developers. The first time you make a change that requires you to trawl throughout a project editing code you will see the value of designing a project based on a sound architecture. The more often you do it, the easier it becomes. One school of thought says that you can wait until you need it to implement it. Another says that by the time you realise you need it, it's too late.

 

[jswota]

I have planned this out. As much as i can anyway. I am often instructed to quit planning so much and "just do it." Pitfall of contract work i guess. I am probably working on a much smaller scale than you and don't have as many factors to consider. I don't anticipate any changes in the future that tell me to code this differently. The issues that i DO anticipate are database changes. This is a very simple fix in the wizard. I just need to add the appropriate editors and set their databinding. All of my code is within the Wizard itself which makes debugging very simple. The only thing my Contacts form has to do is Wizard.ShowDialog.

You mentioned earlier that only one form should have to know about the other. Well that is pretty much what is happening here. It's just that my Wizard form knows about the Contacts form. This approach just seems so simple to me. Let's just say that there won't be changes in the future that preclude me from doing it this way (i don't want it to come across as "my way" but rather the most straightforward way i have come up with so far); would you still say that this way is not better than copying the datarows properties to the wizard? Doing it outside of the wizard is not difficult, it just seems to add unnecessary code to both the wizard and the contact form. Right?

Thanks for the info. It's nice to get feedback so quickly.