Thanks for being thorough. I did prefer the method of passing parameters to the Constructor but i can also see the benefits of the delegates. Its probably too time consuming now to revert back but we'll see..
There arent any business reasons withheld.
- there is 100% guarantee that only 1 product will be open at a time, its the way we need to operate.
- The application is a plugin to a 3rd party software
- each product is a simple left to right process to each ChildForm with a function at the end to process the data to a dataset
i have had various versions, all working in their own way. At one point, i did have all subs containing their own data properties but as the complexity grew, it became more difficult passing those property values between subforms without creating a bunch of extra handling code (as the process moves left to right, some property values are required in the next subforms etc). In my mind, if
- each subform only had to look at 1 dataclass to get / set property values
- then invoke a ControlChangeEvent in the ParentForm to update
- ParentForm collects all properties from DataClass and makes the graphical update.
I dont want to get into bad coding habits so I might revert to something like this-
- ParentForm contains all ProductProperties (no Shared class, members or new instance)
- ChildForms contain all relevant variable members specific to that ChildForm
- on a control update, invoke a data collector from the ParentForm to update the Properties
- ParentForm graphically updates what it needs to
- On a ChildForm NavigationEvent, collect the required data and pass to the req. ChildForm
- ParentForm processes final data to a dataset
The graphical update on the parent form is a realtime result of the updated data. Is mainly materials & sizes in a representation of the product.
Is this something that would more inline with a typical construction?
Thanks for your help :)