For sure this issue of bound forms VS unbound forms can always conjure up
quite a heated discussion.
The major problem here is that most developers coming from other
environments are used to an unbound type of design model.
Furthermore when you need richer or more complicated interfaces in MS
access, you really only have two choices:
apporach #1) Reduce the complex user interface and design your application
with the MS access interface in mind.
I can't stress how critical the concept this is that you *make* your desings
fit access. For example, we don't have the ability to put a continuous form
inside of a continuous form. However often we need this type of many to many
UI. A great example of this is the classical distribution of funds from a
given check amount. That is you enter a check value of amount into one
column, and then must distribute the total check amount into other expense
accounts. I can't say every person who's done a lot of business software has
encountered this type of interface, but pretty much every one had to do this
type of code once in their life.
We really don't have a drill down control in MS access to accomplish this.
So the solution was rather simple, but the simplicity is a result of
sticking to what WORKS in the MS access interface.
The interface design I used as a screen shot is posted here:
http://www.members.shaw.ca/AlbertKal...icles/Grid.htm
(just quickly scroll down to the very last screen shot, you'll see the list
of people and check amounts on the left side of the screen. On the right
side I'm able to distribute the funds of the check out to "many" separate
accounts, but they both must balance.
So the solution I came up with was to simply placed two sub forms into a
main form, and the result works really wonderful. Again I can't stress that
the lesson we learned here is that you must design for the MS access
interface, not the other way around.
approach # 2) consider unbound forms to get the contorl or interface we
need, or better yet simply dump the use of MS access.
The main problem with using unbound forms in MS access is that you give up
the complex forms object model. Of course the access forms object model is a
labyrinth of events. It most certainly can be confusing and catch you with
your pants down often (That's your comments about making this confusing
often makes sense). However, it is this complex object model that also gives
us the wonderful power and speed of development that MS access has.
The instant you break outside of this bound design model, you give up all
the tools and wizards and everything that is built in to give you high
productivity that access is famous for.
A great example is all the extra events we have when you use bound forms,
for example just think of what occurs when you load up a form:
compared to VB, we have TWO significant and two distinct events that occur
when a form loads (Compared to vb's 1 event).
we have:
1) on-open event
The on open event is a really cool event because allows you to have code
test for conditions that will actually prevent the form from a actually
loading (and becoming visible). Furthermore this event is too soon to
actually modify data on form's controls (but you can inspect values in
contorls). The beauty of this event is thus that you can actually build
things like record locking code, and if you fail to get a record lock on
your data, then you can prvent the form from loading.
It is only after all of your so-called test code, or criteria code passes
that the form can then continue to the on-load.
2) on-load event
The on load event is were all of your forms setup code, variable
initialization code etc goes (in fact it's just wonderful to have two events
to force developers to distinguish and palce different kinds of start up
code in two different places for that form -- as the develop or I know
exactly where to look for the initialization setup code, and I also know
where exactly to look for for code that will canceled and prevent the form
from loading -- in vb land this distinction is never made nor is it
formalized in such a nice way). furthermore what's really nice is if you're
all on open event cancels, then your setup and in its place nation code in
on load will never run.
My point here is that if you start using unbound forms then you essentically
give up the wonderful two separate features and events. For a unbound form
to use the on open event to cancel a form load, then you'll have to put in
all of your setup code, and all of your data binding code into that on open
event, and that's gonna get a bit messy (and if you move all the code to be
on load event, then you'll actually see the form appear). I sure wish the vb
environment had a really nice event that you could cancel the form load (and
have a wonderful place holder for the cancel code *in* the form like access
does). In the VB environment you're calling code gonna have to set this up,
and it's messy to cancel a form load without the form being viewed at all.
Furthermore bound forms have a ton of events such as before update, after
update, before del confirm, after dell confirm.....the list goes on and
on...its huge.
We can have a user selects several records on a form or continuous form, and
then hit the delete key, and the appropriate delete code will repeatedly run
for you automatically. To duplicate this type of behavior is in un bound
form is going to take a lot of code writing.
Furthermore there's just tons of little things like for example
if me.newrecord then
hey, this is a new record, let's do something different ...
or
if me.dirty = true then
hey, the user has modified some data on some control, let's do something
else
So we have the use of all kinds of little flags and form settings to tell us
if this is a new reocrd, or the form is dirty. And, we don't just have one
event like the reocrd being updated, but we have before update, an after
update, on insert new record, and the list goes on and on again.
Each one of these events when used in the correct specific manner, yields
incredible productivity from a developer's point of view. The trick as I
stressed is you must design your applications around the correct use of
these events.
The instant you use unbound forms, you give up all of these events, and you
give up all of the settings like dirty, new record, etc and they cannot be
used.
In these other environments they have a very rich host of tools built around
an unbound forms object model. Therefore these other environments provide
truckloads of special data connectors, data binding options, and all kinds
of things that are built around forms that are not data bound. In fact you
have years of tools desinged around a unbound object model.
The problem is when you move an unbound design approach to MS access, you're
getting the worst of both worlds, because you can't use the massive amount
of built in data features that a form has, and you also have no support and
no bunch of wizards built to help you do all that data connecting that these
other un bound platforms have.
In effect you'll be writing code at a slower pace than those other
development platforms because they have all the super duper wizard and data
connection stuff build around their model. We have no such rich feature set
and tools to do that data binding in MS access, and therefore you give up
all the wizards and support.
There's certainly times when you want to use unbound forms for a lot of user
interface prompt type stuff. However if you've reached the point where you
find that the interface requirements you have need un-bound forms a lot,
then you starting to fit a square peg in a round hole.
You'll likely be more productive in an environment that's designed for
unbound forms, and gives you the kind of "fine" control and interface that
you need in your applications.
Unfortunately access is not really designed around that unbound concept, and
you certainly do have to give up a lot of features and things when you go
the bound road. as always on these issues and matters your mileage may
certainly vary, but I just think the price is too high to pay for un bound
forms, and perhaps for your situation you don't consider the price versus
the benefits too high of a cost.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
Similar Threads
