Click here to Skip to main content
15,908,111 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I need to update an employee record on a database and I have 2 forms to do that.
The 1st form shows a grid with a list of some employees, the user has the choice to right click on a record an opt for adding a new employee or changing or deleting an existing employee. If the user opts to create a new employee I am showing a 2nd form with all the empty fields for an employee master. If the user opts for changing or deleting an employee record I will show the same 2nd form with all populated employee fields.
The scenario described above is a very common when you want to update a record on
a table, normally you do not update directly on the grid instead you use a second form where
you will show all fields related to the record you want to update and be able to validate the data before saving the changes to the database.

On Form1 I am passing the Selected Employee Id on the Grid (if any) and the Maintenance Action (Create, Change or Delete) to 2 properties previously defined in Form2
(if Action Create is selected the variable is passed empty, for the others I am passing the Id on the clicked record). Then I am showing Form 2 without closing Form1.

Form 1

VB
Sub ShowChildForm()
   form2.strEmployeeId '<== This is the Employee Id value from the Grid
   form2.strAction '<== Will contain the value "Create, Change or Delete"
   form2.Show()
End Sub

// Activated event
VB
Form1_Activated
if strAction1 = "Done"
   Refresh grid here
endif
End Sub


On form Form2 I will update the Database using a Table Adapter and
pass back to form1 a value "Done" in a property defined in Form1 meaning that I need to refresh the Grid because a record has been added, changed or deleted. If not action was completed I don't need to refresh the grid. Finally I close Form2 and the Focus goes back to Form1 which was left open behind Form2.

Form 2
VB
Private button_Save_Click()
   dtaTable.Update(dtsTable, myTable)
   Form1.strAction1 = "Done"
   me.close
End Sub


Now on the Activated Event of Form1 I am checking if the passed value is equal to "Done"
so I can refresh the Grid. But after doing a debug I noticed that the program goes to the Activated Event a lot of times which is not efficient. I can using a variable to control that, so the refresh is made only once on the Activated event but still the variable checking will be done many times. Is there any other more efficient way to accomplish this or maybe a most modern technique in VS Basic 2012.
The scenario described above is a very common scenario when you want to update a record on
a table, normally you do not update directly on the grid instead you use a second form where
you will show all fields related to the record you want to maintain and be able to validate the data before saving the changes to the database.

Thanks in advance
Posted
Updated 2-Jan-14 12:29pm
v2
Comments
Sergey Alexandrovich Kryukov 2-Jan-14 14:40pm    
Why would you call some form a child? Child-parent relationship between forms is made defunct, unless you mean MDI parent/child, which I would never recommend to use.
I would strongly advise to do all application in only one form (not counting some modal forms, if you need any).
—SA
Nelek 2-Jan-14 18:29pm    
Code blocks added

1 solution

Oh dear...please, don't do it like that!
Instead, create an event in Form2 that indicates "Completed" and signal it when you have updated.
Form1 adds a handler to the event when it creates the Form2 instance and refreshes the grid then.
Nothing needs to look at variables, and nothing needs to know that forms even exist unnecessarily. (Form2 should not know that Form1 even exists! Form1 needs to know about Form2, because it cretaes it and displays it).

Have a look at this: Transferring information between two forms, Part 2: Child to Parent[^] The code is C# rather than VB, but the principle is identical, and the code is pretty obvious.
 
Share this answer
 
Comments
gregoryayca 3-Jan-14 11:27am    
Look this comment that I have received. What do you think?
Why would you call some form a child? Child-parent relationship between forms is made defunct, unless you mean MDI parent/child, which I would never recommend to use.
I would strongly advise to do all application in only one form (not counting some modal forms, if you need any).
—SA
OriginalGriff 3-Jan-14 11:46am    
I use it just to give them designations: the Parent creates the Child so it needs to know it exists. The Child doesn't need to know the parent is any particular type of form, or even that it exists at all.

I would disagree with the "one form fits all" approach - sometimes it's a good idea to have multiple forms, it depends on the application and what you expect the user to do. Keeping the number down to a "sensible" limit is good though.
For an example, look at PaintShopPro: It uses multiple forms so I can have the paint area open on one monitor maximized, with overall preview and tool forms on a second. Works well and uses screen space effectively.
gregoryayca 3-Jan-14 12:23pm    
I understand "PaintShopPro" is an painting application but remember that we are a talking about a very common scenario in the business industry. A typical file maintenance, Clients, Items, Vendors, Contacts, Employees, etc. When you go a bank to open a new account, they go first to a form where they search your name or S.S. # to verify if you have or had an account already even so if you say you don't have it. If they do not find you they click a button to create a new account and a new form is opened, in this new form they have all kind of validations for example they verify the address you provide against a valid address directory and tons of validation for other fields, when everything is Ok they press a confirm button to Create the account where the Account (Checking/Savings) number is assigned and the Database updated. If you decide to open savings account then they press a button to open a new form to Open a savings account with fields maybe different that the one for Checking and so on. Similar procedure repeats for Clients, Vendors, Employees etc. Do you think we can have all these in one form ? What about OOP, modular design is one of the benefits.
I imagine having everything in a large form hiding some fields and making appear others with tons of events and methods and making it more difficult to maintain. The app at the same will use a lot of machine resources.
Thanks
OriginalGriff 3-Jan-14 14:28pm    
As I said: "it depends on the application and what you expect the user to do"
Sometimes multiple forms is the right paradigm, sometimes it isn't. (There are times when I prefer to detach all the panes from VS and run it full screen on one monitor with the tools on another - but that doesn't quite work with tool windows :sigh: )

You can get round the "tons of events and methods" problem quite well by creating UserControls - I use them quite a bit even if I only ever going to have one of them as they abstract code rather nicely and "clean up" my form code pretty well too. Group things logically together on the form, so group 'em together in a UserControl as well...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900