A2010 macro builder and a message box
in [Help]
|
Prev: Help in A2010
Next: New features of Access 2010
From: Albert D. Kallal on 30 Nov 2009 00:59 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CD2B2FE237D0f99a49ed1d0c49c5bbb2(a)74.209.136.98... > Marshall Barton <marshbarton(a)wowway.com> wrote in > news:ib65h51fpln317cckhepoipb5qaoh5suva(a)4ax.com: > 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 pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 30 Nov 2009 17:23
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:abJQm.35420$tz6.21447(a)newsfe02.iad: > 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 object. 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 http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |