I think that the issue of best programming practice and how many forms are used
to accomplish a task are two separate issues.
Sharing common code between forms, rather than having multiple instances of
procedures and functions, is always good practice as it makes maintenance and
fault-finding much simpler.
How you divide a task across forms depends largely upon the workflow. However,
there are some factors which really just boil down to the preferences of the
users. Some people like to select records for maintenance from within the
maintenance form itself, while others prefer to select data from a separate
popup. You may not be able to please everybody in your UI design decisions, but
you should seek to satisfy the majority of users.
The tab order of fields can be important. For example highly repetitive tasks,
such as entering client information, will often be performed without the
experienced user actually looking at the screen; just using the tab key to move
between fields. If the tab order doesn't follow the way users naturally work
this can only lead to problems, even if their preferred order may seem
illogical to you as the developer.
In my experience, if your application is only going to have a very small number
of users then you can probably educate them to accept a user interface (both
the layout and the way you decompose the task into forms) which is both logical
and easy for you to maintain. On the other hand, if you have a large number of
non-technical users you would be better advised to give them what they say they
want, within the constraints of the application's functional requirements, and
just make sure that you apply best coding practice and any other approaches to
development which make the maintenance as easy as possible.
If you decompose a task into multiple forms consider very carefully the use of
the form's "modal" property. If formA spawns formB non-modally, and there are
dependencies between them in both directions, the coding required to keep both
in sync can become very complex. However, if formB is modal then you only have
to refresh the data on formA when you save and/or close formB. It makes life
somewhat simpler.
One more thing......
Document the application well, making sure that you highlight the reasons
behind any process flow or task decomposition which you would have implemented
differently given a completely free choice. Otherwise, subsequent developers
may just assume that you are not a very good programmer and implement
"improvements" which only serve to upset the the users.
Nige
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
