"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in
Yes as a subdatasheet but not as a continuous subform.
No, the subform of the datasheet is a continuous subform. Try it,
you'll see.
If the
(sub)datasheet format is sufficient for you, then you're OK but if
it's not, then you're out of look.
The main form will be in datasheet format, but the child form will
be the same format as it would be viewed in regular form view.
Try it and see -- you obviously haven't or you'd have discovered
that what I described actually really does work.
I must add that I've thrown these examples only to etablish the
lack of extensibility from the Access interface. The number of
extensions asked by people over the years is astonishing and while
you can do practically all you want with the display of your data
when you are coding with C++ in a Windows environment, it's
incredibly difficult to do the same under Access.
To get the most out of Access you have to do things the way the
Access programmers provided for you. That's good enough for me, to
be honest. The mindset of the programmer who must do things a
particular way is not a mindset for any user of a RAD development
platform. The whole point of RAD is that decisions have been made
for you in the creation of high-level objects for you to use quickly
to build your app.
If you throw a sufficient big chunk of money at it, you can
develop a very complicated ActiveX control that will probably do
what you want under Access but in this process, the simplicity of
Access will be gone forever. (In fact, it's even more complicated
to do an ActiveX control that will run under Access than it is to
do the same thing under VB6).
Those who *must* have things that Access can't provide should not
program in Access. But most of my clients aren't that picky about UI
that they are bothered by being limited to the interfaces MS
provides.
And, of course, there are major changes to what you can do in this
regard with Access 2007.
Of course, you will say that you don't need this but the problem
from MS is that a lot of people are asking for these and they will
all go elsewhere if they don't find it in the MS offering.
My advice to them is that if they *must* have it and their clients
are willing to pay the extra money it costs to abandon RAD
development in Access, then they shouldn't use Access.
My clients aren't that picky. They are perfectly happy with UIs that
accomplish the same tasks, even if they aren't implemented in the
way that Access isn't designed for.
You could say that .NET is not so
good in comparaison of VB6, maybe; but doing a (+/- bad if you
think so) replacement where you are trying to correct things is
much better than doing nothing or trying to patch an old system
who had already to many layers of duct tape on it.
The whole point is using a generalized tool or a tool that is
optimized for a specific task.
In 2007, you have to compete against things like Delphi 2007, SUN
Java or IBM WebSphere, this is the reality of MS; not a bunch of a
few thousands of programmers who would like to live in the past.
I think it's wrong to compare Access to standalone, generalized
development platforms. Of *course* Access can't do everything that a
generalized development package does. The trade-off is that what
Access is optimized for is mostly much, much easier in Access than
it is in a generalized environment.
For any particular application, one chooses the development platform
accordingly.
Blaming Access for lacking capabilities of .NET or VB is just
senseless. It's like asking a light-duty pickup to be a Mack truck.