Things to watch
for in code
Pick
code (so called data basic, or mv-basic) is easy to write, and it is easy to
manipulate data with. Trying to manipulate a "piece" data in VB takes
considerably more effort then it does in mv-basic.
In fact, difficult
might not be the best choice of words.
In VB a different approach is
required
VB has an
advantage over Pick in that you can use SQL in code to update records. Notice I
used the word "records" here. I did not say a record! In VB we don't have an
equivalent dynamic structure that Pick has. Collections in VB come close. I use
collections in VB quite a bit, but they still don't cut it when compared to
Mv-Basic (nor can you easily save a collection to disk). When you have a minute,
look at my object example in Appendix 3
The event driven model
Pick code is not a event driven
environment like ms-access (the front end for a Pick system can be however).
Hence, while in ms-access you build screens, those screens have a lower re-use
then when compared to Pick code. If you DESIGN ms-access screens with
re-usability in mind, then a lot of productivity can be recovered. If you do NOT
design the screens and code with re-use in mind, then development time for
ms-access will increase dramatically.
On the right you see a typical
event System in Ms-Access.
The form Search Tour asks the user
for a Tour Name, and then displays the
matches in some "hit list".
When the user clicks on a "hit list",
a Form to book the tour is displayed.
Now, let us assume we want a form
to
maintain these Tours. Hence we
create a form to search for tours
When the user clicks on the "hit list",
the form to maintain the tour is displayed
Notice how we cannot use our first form
"Search Tour" Again. The reason for this is
that when we click on a entry in the "hit list",
we need a *different* form to load.
Hence we would probably just
"copy" the original Search Form and use it. About the only thing that changes in
this case is the "next" form loaded when we click on the hit list.