I can use some advice / help on a piece of software developed.
The application is a wizard-style app where users fill out fields on each form before returning to the next form or before returning to the previous form. Fairly simple.
Now calls frmWiz1 (InitialData) in the menu and when related to frmWiz1 dialogue. The OK menu will call frmWiz2 (frmWiz1.Data) (not all, it stores all data from each form, and passes those references in the next context). Each data object is inherited from an illustrable interface which defines the methods of printing, so on the last page of the wizard (print preview / sign), it adds each data object to a custom print document object that is just a data object It only makes it eat, calls them, print functions and pagination etc. Management.
In the beginning, I thought it was a good idea, but now I am thinking that: - The menu form is handling a lot of fluid logic - Data objects (which handle all business logics that have their particular data Applies to the set) must be decoded with print logic (since they are now, they are in the printing namespace - maybe one transition must be set to my mind at least).
I do not know. I am good with language, but I am still a rookie on the design.
Screw "frm" prefix!
In relation to the overall flow of the application, I use or suggest some kind of reasoning to centralize the argument.
As far as UI goes, each wizard step should have a separate user control ("cancel", "end", "next" or whatever button is not) As well as on the root form
No object should be responsible for printing itself - use IPrinterService to do this.
Comments
Post a Comment