Where I experience the incompatibility is in saving object
data into tables. As I understand it (I never use it) the only way to
save
object data is as a text string via the scripting runtime library.
We don't have any built in serialization of objects in ms-access, and that
double applies to class objects that you create. On the other hand, really
storing the state, or values of a object you crate is VERY much different
then simply storing customer data in a table. You can't really store that
customer information in anything but a standard relational data table.
Often we see a person go hog wild on OO, and start storing data
of a customer in this fashion...the end result is useless, since you
can't use standard reporting tools, or even sql quires on this type
of serialized data.
So, sure...I wish we had some type of serialization to store the all of
the data for a class object we create. This would be great for
saving the state of a object, or even loading/saving them.
So, this is good as long as we throw cold water on this idea
that this class object data should some how store our
customer data in a serialized format that is of NO USE
for reports, or sql quires. Doing this ties the data
to code.
A disappointment is that Access does not provide implementation
inheritance,
so even if I design a class/subclass structure I still have to code each
and
every property and method in each and every subclass. Will this be
corrected
in 2007?
ms-access shares the same code syntax (and in fact the same compiler) as
vb6.
It is not likely that the vba will be modified in this way. What likely will
happen
is that events will be able to be sub-classed out your .net environment in
the future, and thus would then use .net..and not vba. This was done
in office 2003 for word and Excel. However, the ability to use .net code
for ms-access was not changed, and nor is it for access 2007. I
am speculating here..but, since you can now replace your vba code
in word, or excel with .net code, I would expect the same idea in
ms-access. This would thus allow you to keep existing applications
(there is several 100's million copies of ms-access out there...and
we can't break all of that!!!).
Oh there's also a glitch that I notice when opening forms as class
modules.
Open a modal form using OpenForm and the remainder of the code below that
statement does not execute until the form is closed - kind of what I would
expect
the above is incorrect. You are thinking of a dialog form...not a model
form.
Model forms never halted the calling code (or, in your case, when you
instance a form/class object).
I explain the difference here:
http://www.members.shaw.ca/AlbertKallal/Dialog/Index.html
However instantiate a new modal form and code execution continues
until end of procedure. If possible I would like code execution to stop
when
the form is made visible. (2007?)
I don't want to split hairs on semantics. It is clear that you did mean
dialog
forms here!!! And, what you say above is correct.
The general approach/workaround I use is have the new form instance
create a reference to the form that created the new form instance, and
choose a common event name for the new form to execute when it
closes. So the instance of the form will execute code from the calling
form when "ok" is hit, or the form is closed.
This means your calling code will not wait, but you
just transfer control to a whole new routine after the form is done.
This is certainly not very clean..but, it does work, and is what I do now.
I find that my Access applications are never completely procedural or OOP
but a hybrid.
Yes, I agree!...You above analyses is spot on. we do have class objects, but
one does
not have the traditional full OO features that one would expect. Further,
we are not
procedure due to the event driven nature of ms-access.
I make this post to invite others to comment on when, how and
why they use class modules.
For all the readers here is my comments on using objects in ms-access....
http://www.members.shaw.ca/AlbertKallal/Articles/WhyClass.html
have an awesome day