From: Albert D. Kallal on
"David W. Fenton" <XXXusenet(a)> wrote in message
> Marshall Barton <marshbarton(a)> wrote in
> news:ib65h51fpln317cckhepoipb5qaoh5suva(a)

> Well-said.
> This is exactly the point I tried to make in a reply to Albert that
> I posted a moment ago, that the difference comes not from a distinct
> type of class module, but from the fact that the object the class
> module is bound to is of a different nature. Reports are different
> from Forms and thus, they work differently.

Sure, but the context to state that you using a reports class module
vs. that of a forms class modules **IS** important here. At least if
you care about trying to help someone here.

It quite moot to tell me they are the same type of module, but then
turn around and tell me their features are different. Of course the
features are different because the object they are attached to.
(hey, the sky is blue too!..but, I did not think that needs
pointing out).

However, as I showed identical expressions and functions work differently
in the form vs the report objects.

Telling me that the modules are the same and failing to distinguish between
what features do, or do not work will not help anyone here. Telling me
they are the same will not resolve issues like my me.fieldname example.
(that I assumed everyone was aware of).

So, sure, reports and forms modules are the same, but their features and
what you can do does behave differently. In the context of a discussion,
this Distinction is important.

This is all about the issue of context here. Without context, how can one
communicate instructions in a context to anybody?

I not sure what being suggested here, to not make this distinction anymore

Pointing out the sky is blue, or that report & forms class modules are the
same is really very much a moot point here. That point does little if
anything here for anybody here who will encounter differences in code
behaviors in a form or report module.

You can tell a person that the modules are the same, but try to resolve an
issue without the context of what type of module (form, or reports) makes no
sense at all.

I'm not trying to make the case that they're the same (or not the same). I'm
simply making the case that anybody who is working with these types of
modules needs some type of distinction in the context of the problem that
they're having, and I'm suggesting we do the same with macros regardless if
they really are different or not...

Are you suggesting that we don't make distinctions between forms code
modules and reports code modules here anymore?

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)> wrote in

> It quite moot to tell me they are the same type of module, but
> then turn around and tell me their features are different.

You don't expect to be able to edit controls on a report, and that
doesn't seem to be a hard concept to grasp. Attributing the
difference you adduce (which I had not noticed, something that seems
fairly significant, given that I program in Access every single day)
to a different type of class module is just wrong. It's not a
different class module, but a class module attached to a different

The difference is entirely due to the different context in which you
are using a class module, not to some difference between report
modules and form modules.

David W. Fenton
usenet at dfenton dot com
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Help in A2010
Next: New features of Access 2010