A2010 macro builder and a message box
Salad
because the hsx viewer told me MS Help 2.x runtime wasn't available. So
I had do dl something from Microsoft, in this case VB.Net, to get the
required runtime files.
I didn't explore them much so I may be asking a question that is
contained in the file. How can one display a msgbox from a macro?
I've been real curious about CurrentWebUser and what the values and
parameters were. So I created a couple of statements
messagebox "0 " & CurrentWebUser(0)
messagebox "1 " & CurrentWebUser(1)
messagebox "2 " & CurrentWebUser(2)
messagebox "3 " & CurrentWebUser(3)
saved the macro and form and ran and it displayed
"0 " & CurrentWebUser(0)
"1 " & CurrentWebUser(1)
"2 " & CurrentWebUser(2)
"3 " & CurrentWebUser(3)
So I created a temp variable
SetTempVar One
Value :1 + 1
messagebox "One " & 1 + 1
messagebox One
and the results were
"One " & 1 + 1
One
In older VBA, I could do
msgbox "Today is " & Date()
and it would display
Today is 11/23/2009
I noticed the help had a lot of missing links. In the help file I got
from Albert's link I was informed that data would be provided in the
help file when A2010 was released. I know there's got to be a way to
display a calculated string in a message box. But without a book
detailing some of this stuff, the method to learn the how-to's of A2010
seems to beby trial and error, guessing and by-goshing, and flying by
the seat of one's pants.
If anyone knows how to display a calculation of a messagebox from a
macro and willing the pass that info on that would be appreciated.
Albert D. Kallal
> If anyone knows how to display a calculation of a messagebox from a macro
> and willing the pass that info on that would be appreciated.
I quite sure how this works goes all the way back to access 95, or even
before that....
Think of that message box as how you type in a expression in a property
sheet in ms-access (you have to force the expression service to take care of
this).
so:
Hello
or
"Hello"
Will be taken as an literal
To avoid confusing, I just always use the expression service in macros, and
hence:
=("Hello")
so, you code might go:
SetTempvar (i,1)
messagebox =("Value of I = " & [TempVars]![I])
So, it really the same as using expressions in ms-access...
You need to put =() and you have an expression...
Here is a screen shot of a macro that sets a value, and then runs a loop 5
times display the value 5 times (the message box will appear 5 times).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com
Salad
I will play with it shortly. I'm curious about the
SetTempVar (,1)
line. The why 2 args? Is that due to a for/next loop structure
I was looking for a For/Next loop function. Interesting to see the
RepeatCount line. Hopefully it will be in Help. :)
Let's say you have a Macro with
Action1
Action2
Action3
You then realize you have the need to put an action between 1 and 2. Is
the method to go to the buttom, do an AddNewAction, and then more it up?
Or can one go to Action2 and insert it somehow?
Is Macros the way to start thinking now? VBA old school, new way
Macros? There being so much info in these posts, I forget...if you want
to run an app on the web must you do it all via macros (because the
actions one can perform on the web are defined) or can it also run VBA
code in a web app as well?
David W. Fenton
news:n9qdnXxbVJtV0pDW...@earthlink.com:
> Is Macros the way to start thinking now? VBA old school, new way
> Macros? There being so much info in these posts, I forget...if
> you want to run an app on the web must you do it all via macros
> (because the actions one can perform on the web are defined) or
> can it also run VBA code in a web app as well?
This is the part that bothers me the most. I thought I could ignore
the embedded macros in A2007, since I was never in need of the
"security" level that it seemed to me they were designed to provide
(i.e., a codeless Access application that wouldn't violate paranoid
IT departments' policies about running VBA code), but now it's quite
clear that they've been heavily leveraged.
The table-level data macros are something EVERYONE is going to use,
seems to me, because it means you now have TRIGGERS. That's just
huge.
Also, with macros now having flow control and branching (e.g.,
If/Then/Else), internal variables and error handling, the main
deficiencies of them are no longer there.
That said, I still think they are problematic from a documentation
point of view. Event code attached to a control on a form is
"embedded" in a certain sense, but it's easily accessible from an
external source, simply by browsing in the VBE. Even before A2000
and the VBE, you could always search the whole codebase, and
navigate your project via the object browser. So far as I know,
there are no corresponding tools for "macro management" and
navigation as you have for code management.
I'm very conscious of this right now after having spent my summer on
a major revision of an app that started life in Access 2 and had not
a single line of VBA code (all macros). It was a real tangle and
incredibly difficult to forecast what effect deleting a macro might
have -- yes, I could use search and replace tools, and I certainly
used them extensively, but that's not the same thing as having
immediate access.
Also, after the introduction of A97, I haven't used macros for
anything at all other than the things that require them (AutoExec,
AutoKeys, some menu-based operations, though that, too, is no longer
necessary). So, I'm totally unfamiliar with the basics of how to
construct them, e.g., how to force evaluation of literals in the
example you provided the answer for here.
Thus, there's going to be a learning curve and that's going to be
quite frustrating. For new users, it's going to be very powerful and
useful. But for us old hands, it's going to be quite frustrating, I
fear.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Salad
An autoexec macro is about all I've ever used, VBA being the replacement
so I know what you mean.
>
> Thus, there's going to be a learning curve and that's going to be
> quite frustrating. For new users, it's going to be very powerful and
> useful. But for us old hands, it's going to be quite frustrating, I
> fear.
>
It will be a switch, but the gains seem to be worthwhile.
Albert D. Kallal
> Albert D. Kallal wrote:
>
> I will play with it shortly. I'm curious about the
> SetTempVar (,1)
> line. The why 2 args? Is that due to a for/next loop structure
There is 2 args, the 1st one is the variable you want set, and the 2nd arg
is the value.
so,
SetTempVar (i,1)
SetTmpVar (j,2)
Would set the value of temp var I = 1
And, set the value of temp var j = 2
> Let's say you have a Macro with
> Action1
> Action2
> Action3
> You then realize you have the need to put an action between 1 and 2. Is
> the method to go to the buttom, do an AddNewAction, and then more it up?
> Or can one go to Action2 and insert it somehow?
Well, note that ctrl-up-arrow and ctrl-down arrow does move code blocks up
or down (and I LOVE this feature..and wish the VBA editor could do this).
However, To insert, just drag the command from the action catalog where ever
you want into the code. You can also use drag and drop to move code EXISTING
blocks around, and if you use ctrl+drag, you can copy code by drag + drop.
I wish there was an insert key. However, if you drop in a EditReocrd, or
even an if..then block, then there is a blank "add new action" that appears
inside of this block. So, you can well insert into existing code "blocked"
commands like editrecord or if..then. And, it turns out these are common
places where you insert additional code anyway. So, you have to change your
habit a bit when you want to insert a few lines of code. I find it best to
just drag + drop the command from the action catalog into the middle of the
code wherever you want..
>
> Is Macros the way to start thinking now? VBA old school, new way Macros?
No, not really, I think if you developing a desktop application, I would
stick to VBA.
there are two significant reasons to use macros:
1) data triggers:
2) Web applications.
I really like the new table trigger feature. This gives access developer's
stored procedures and triggers. This feature is something that I wish we had
a long time ago. I can't tell you how these triggers start to "change" the
way you approach some problems. You will learn to THINK differently about
some solutions.
Obviously to use these new table triggers and stored procedures in access,
you'll have to adopt the data macro programming language. So, ONE great
reason to learn the new macro and specifically data macros is to take
advantage of these triggers. I still suggest that the overall application
you build is going to be far better for you to stick to using VBA.
> There being so much info in these posts, I forget...if you want to run an
> app on the web must you do it all via macros (because the actions one can
> perform on the web are defined) or can it also run VBA code in a web app
> as well?
The above question really answers the second reason why you want learn data
macros.
For web based forms, to make your buttons, code etc, it all must be macro
code. NO VBA. In fact it's a real challenge to change designs for web based
application. The reason for this is that MOST of your program logic and data
processing HAS TO go into the stored table procedures.
In fact, you will be in a state the shock the first time you create a web
form. The lack of functions you have sends a cold chill up your back!. You
really have to change how you approach your designs. I think it's GREAT that
one's mind has to go through that mindset change, but it's hard when you
have all this longtime habits you built up an access over the years.
The long time desktop design approach in which MOST of your program logic
goes inside the form has to be changed. You UI and data code has to be
separated. I think it's absolutely wonderful that access gives us this new
Paradyne. This forces a mentality change, and REALLY allows one to learn the
web design approach. The result of this effort is a true multi tier web
based application.
I think the feature limitations (ie: lack of features) is the hardest part
to grasp or get around when you first jump into this web thing.
Access won't tell you to design this separation of user
interface and code. You'll just simply be forced this way. You will find few
features you need in the forms. You then must "come up" with NEW designs
that work different. You will just have to stumble along and find out where
the functionality is you need. The functions and features you need will be
found somewhere else.
A really terrific example of this, is that in one of my web forms, in the
web forms on-load event I wanted to setup 4 listboxes.
Here is a screen shot of that form:
Note the 4 listboxes are simply 4 unbound listboxes that allow the user to
click on time. I did this so the user does not have to jump from the mouse
to the keyboard and back to the mouse. In other words, my goal was 100%
mouse for this web form.
I have used that type of time picker for YEARS in VBA forms.
So, in the forms on-load event I wanted to do the
following:
lstboxStartHour = Hour(startTime)
lstBoxStartMinute = Minute(StartTime)
lstBoxEndHour = Hour([EndTime])
lstBoxEndMintue = Minute([EndTime]).
The problem here in the web forms UI macro we don't have the Hour() etc.
functions. Note the new terminology here. UI macros and data macros
(for example, data macros don't have messagebox commands).
Anyway, Guess what? The UI macro does NOT HAVE the
hour(), minute() commands that I expected in VBA!
So, now what? How do you change your design here?
The simple solution was to base the form on a query. The web query builder
DOES HAVE most VBA functions we come to expect. And, since the form is
still editable if I base the form on a query in which several columns are
function based. So, here is a screen shot of the web Query I built:
So, now, my on-load macro code works, and looks like:
Note that when the above screen shots display, I do believe clicking on the
screen shot again will zoom it in further...
At the end of the day, I so been able to accomplish just about anything I
wanted web wise, but you have to change your approach. For example, setting
up 2 cascading combo boxes takes us a few minutes. An experienced colleague
of mine played around for nearly an afternoon to come up with something that
worked in a web form. So, for some things, you have to prepared for
workarounds. For some, this is fun, for others..it frustrating...
The access web system is really quite simple, but yet is rather capable.
With alpha 5, zoho, and and even FileMaker all staring to offer web stuff,
then access really had no choice but to join this party or face falling
behind in the marketplace...
David W. Fenton
news:hbqPm.37005$ky1....@newsfe14.iad:
> With alpha 5, zoho, and and even FileMaker all staring to offer
> web stuff, then access really had no choice but to join this party
> or face falling behind in the marketplace..
Filemaker has offered it for about 5 years, so it's not just a new
need.
David W. Fenton
news:hbqPm.37005$ky1....@newsfe14.iad:
> For web based forms, to make your buttons, code etc, it all must
> be macro code. NO VBA. In fact it's a real challenge to change
> designs for web based application. The reason for this is that
> MOST of your program logic and data processing HAS TO go into the
> stored table procedures.
You don't have embedded macros in web forms? I can't imagine how you
could put UI navigation logic into table-level data macros.
Also, are shared macros available, i.e., non-embedded macros that
can be called from any web form?
Albert D. Kallal
news:Xns9CCFA35A985C8f9...@74.209.136.82...
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:hbqPm.37005$ky1....@newsfe14.iad:
>
>> For web based forms, to make your buttons, code etc, it all must
>> be macro code. NO VBA. In fact it's a real challenge to change
>> designs for web based application. The reason for this is that
>> MOST of your program logic and data processing HAS TO go into the
>> stored table procedures.
>
> You don't have embedded macros in web forms? I can't imagine how you
> could put UI navigation logic into table-level data macros.
Yes, you have embedded macros. and, you also have general web macros (that
are not part of a form) that can be called by these ui macros.
So, for example, in my calendar booking form, I wanted the code + form
called in ONE place for the 42 text boxes "click event" that makes up the
calendar. So, while I did have to code 42 embedded click events on the
calendar, the code for each click event called the same one non embedded
macro (so I could easily change the click even code in one place for the 42
controls). That code would simply launch the calendar details form with a
date "where" clause and had a bit other code in it..
So, yes, each button and each text box control on a web form has events and
you can (will) embed macro code in that form. Those embedded macros can call
regular web macros (ones not part of a form). These UI macros (UI macros =
terminology for forms embedded macros) can also call data macros (data
macros = terminology for macro code attached to a table). UI macros can pass
parameters to Data macros. Data macros have the ability to do things like
recordset processing (but, they are not called record sets).
>
> Also, are shared macros available, i.e., non-embedded macros that
> can be called from any web form?
Yes, not only are there shared macros (non embedded macros), but there is as
mentioned the table level macros. These table level macros can be called
from table triggers, or called from UI macros. Note that code wise table
trigger macros have the same feature set as table macros. And, regular web
macros are feature wise quite much the same as UI macros, but they just are
not embedded in the form. These UI macros and regular macros can pass
parameters to these data macros.
Note that client only forms can of course have VBA code, or macro code (and,
client side forms macros don't have the limitations that web forms have, so
client side macros very much have most vba functions for example).
So, a forms UI macro can call either data macros (which are associated with
a particular table). or can call macros that are NOT embedded in a form.
Those non UI macros can also call the table macros (or so called data
macros).
Validation macro code at the table level can execute a raiseerror, (with a
custom error number), and that error can be trapped by UI macros.
While this programming model is nothing like being spoiled with VBA, the
whole macro design and setup for web forms is simple, elegant, and IMHO
simply brilliant....
David W. Fenton
> While this programming model is nothing like being spoiled with
> VBA, the whole macro design and setup for web forms is simple,
> elegant, and IMHO simply brilliant....
There does seem to be something of an arithmetic growth problem,
with embedded vs. non-embedded macros TIMES web vs. client.
I'd assume that a client form/report can call a web macro while a
web form/report can't call a client macro?
I'd also assume that table-level data macros are callable by either?
Yes, no, maybe?
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:NNCPm.25289$Sw5....@newsfe16.iad:
>
>> While this programming model is nothing like being spoiled with
>> VBA, the whole macro design and setup for web forms is simple,
>> elegant, and IMHO simply brilliant....
>
> There does seem to be something of an arithmetic growth problem,
> with embedded vs. non-embedded macros TIMES web vs. client.
Well, sure, but it really a question of distinguishing issues here.
I mean, a standard code module, and class object module are not the same as
a forms code module for example. You can use "me" in a standard forms VBA
module, but not in a code module, or an class code module that you create.
So, that's 3 different kind of code modules right there, and we could argue
that reports code modules are a 4th one. As an "general" rule, we don't have
to state what kind of module, but if I asking an question about a report and
why I can't use me.FieldName in a reports code module, then it is clear. As
you know, in a forms code module, you do NOT have to place text boxes on the
form to reference/use fields in vba code, but in a reports code module, you
DO HAVE to place text boxes on the report to reference any field in the
reports data source.
So, the feature set and what you can (and can't do) varies quite a bit
depending on what kind of VBA module you are talking about.
The same issue arises here for macros. In fact it more pronounced since the
feature set change is MORE dramatic from one type of macro to the next, so,
it does become important to distinguish what type of macro one is talking
about, just like it important to talk about what kind of code module we are
talking about -- even how VBA forms code modules work compared to report
code modules is quite different.
>
> I'd assume that a client form/report can call a web macro while a
> web form/report can't call a client macro?
>
yes, since if you looked at the nav pane, you see a list of web and non web
macros in that list. You can launch/run any of them by just clicking on a
macro.
And, the while in theory it would be possible for a web form to call a
client macor **if** we running local and not on the web. However, if running
web, then that form would not have the client macro available. In fact, what
happens where is the macro "drop down" of legal macros is restricted to web
only during coding to prevent you from typing in any non legal name.
Note that web reports do not have any code or events...
> I'd also assume that table-level data macros are callable by either?
>
> Yes, no, maybe?
Yes, either can call the data macros. Since the data macros exist both local
and web, then they again are callable by both client and web forms. In fact,
the real question here does a call to a data macro in the client execute
code local in ACE, or is the call passed to SharePoint? I don't know right
now..
David W. Fenton
> You can use "me" in a standard forms VBA
> module, but not in a code module, or an class code module that you
> create. So, that's 3 different kind of code modules right there
Wrong, Albert. Standalone class modules can use Me just like
form/report class modules. It's because they are both CLASS MODULES.
The fact that one is attached to a form/report and one is not does
not change something as basic as that.
David W. Fenton
> As an "general" rule, we don't have
> to state what kind of module, but if I asking an question about a
> report and why I can't use me.FieldName in a reports code module,
> then it is clear. As you know, in a forms code module, you do NOT
> have to place text boxes on the form to reference/use fields in
> vba code, but in a reports code module, you DO HAVE to place text
> boxes on the report to reference any field in the reports data
> source.
I do *not* know this to be the case.
Access 2000 made forms less robust in that it is unsafe to refer to
underlying fields (such that you have to add hidden controls bound
to them if you need to refer to their values). I haven't stopped
doing it, but it doesn't always work.
I would assume this had something to do with the change of storage
of the VBA project, and so far as I know, reports work exactly the
same way.
David W. Fenton
> So, the feature set and what you can (and can't do) varies quite a
> bit depending on what kind of VBA module you are talking about.
I think that both of your examples are wrong, Albert.
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:FZYPm.36883$ZF3...@newsfe13.iad:
>
>> You can use "me" in a standard forms VBA
>> module, but not in a code module, or an class code module that you
>> create. So, that's 3 different kind of code modules right there
>
> Wrong, Albert. Standalone class modules can use Me just like
> form/report class modules.
Yes, sorry, my bad...
I meant to say me.FieldName, not me. I was not trying to state
that you can't use me in a class module. (I do that all the time).
The "basic" point here was that even a forms
code module behaves different then a reports code module for
example. And, so does a standard class module that is not
attached to any form.
So, a question as to why me.FieldName don't work in a
reports module is a DIFFERENT question then that of
using me.FieldName in a forms module. So, me.fieldName
usually works in a form (regardless if their is a text box
on the form, but in the format events in a reports code module,
me.Fieldname don't work unless a text box is placed on the
report that is bound to the column.
We often see questions in this newsgroup where someone
moved their code from a forms code (class) module into an
standard code module (or even a class code module), and then
wonder why they can't use me.fieldName anymore.
In a nutshell, my "point" here is that while do seem to have "quite a few"
names for macros, it not a whole lot different then that of the several
types of class modules we have (forms, reports, class modules).
I simply just spent some extra time to point out the terminology we have for
macros, and one will often need to distinguish between the different types
when discussing them..
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:FZYPm.36883$ZF3...@newsfe13.iad:
> >> As an "general" rule, we don't have
>> to state what kind of module, but if I asking an question about a
>> report and why I can't use me.FieldName in a reports code module,
>> then it is clear. As you know, in a forms code module, you do NOT
>> have to place text boxes on the form to reference/use fields in
>> vba code, but in a reports code module, you DO HAVE to place text
>> boxes on the report to reference any field in the reports data
>> source.
>
> I do *not* know this to be the case.
>
Sure, just build a report, and try something like:
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Debug.Print Me.City
End Sub
In the above report example, it is based on a table where the city field
exists. In fact, during coding your get intel-sense. But, if your try to run
the above report, you get an error message. Just try it...
Add the text box city..run the report...it works ok. Now, remove the city
text box, the above code fails...
You can't use me.FieldName in the report DESPITE the fact that inteli-sense
gives you that while you code...
It rather a simple example....
So, as I pointed out, the context of a reports class module code works quite
different then that of a forms code module...
Give the above try..it takes less time then to type this response. (base the
report on the base table).
Marshall Barton
>"David W. Fenton" wrote
>> "Albert D. Kallal" wrote
Albert, the way I understand things, that's not a valid
example of a distinction between different "types" of
modules and I believe that report modules and form modules
are the same thing. I'm pretty sure that he difference you
cite is an artifact of MS's implementation of the *form*
object where they create the incomplete, buggy and
artificial AccessField thingy as a substitute for fields not
bound to a control.
Allen Browne has discussed this in several posts and
strongly recommnds that every field referenced in a VBA
procedure be bound to a control.
--
Marsh
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CD1EC8999FC6f9...@74.209.136.90...
>> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
>> news:FZYPm.36883$ZF3...@newsfe13.iad:
>>
>>> You can use "me" in a standard forms VBA
>>> module, but not in a code module, or an class code module that
>>> you create. So, that's 3 different kind of code modules right
>>> there
>>
>> Wrong, Albert. Standalone class modules can use Me just like
>> form/report class modules.
>
> Yes, sorry, my bad...
>
> I meant to say me.FieldName, not me.
Well, of *course* you can't use a field name because a standalone
class module has not fields. A regular module has no field names,
either.
> I was not trying to state
> that you can't use me in a class module. (I do that all the time).
>
> The "basic" point here was that even a forms
> code module behaves different then a reports code module for
> example. And, so does a standard class module that is not
> attached to any form.
To me, there are two types of modules:
1. regular modules
2. class modules
So far as I can tell, they all behave the same, and the differences
is in what they are attached to (or not).
> So, a question as to why me.FieldName don't work in a
> reports module is a DIFFERENT question then that of
> using me.
So far as I know, it *does* work in a report's module.
Ah, just testing, I see this is something that changed with Access
2000. In A97, you can refer to fields in the events that have data
already loading. Basically, that means the OnPage event. That
requires an understanding of how a report is different from a form,
in that at the time most of the report's events happen, there is no
data available to display.
Also, if you use events like OnActivate, you have to understand that
by the time a page is formatted and displayed, the current record is
the *next* one, so if you try to do something with a field from the
underlying recordsource, you're going to get unexpected results. For
that reason, you usually end up getting information out of controls
on the report, since the binding of the visual display to the
underlying data source is quite different from forms.
But I do see that it doesn't work at all in A2000 and A2003 in any
of the situations where it worked just fine in A97. This was a big
surprise to me. It's not that I don't do lots with report events,
but mostly it's these things:
1. in OnOpen, open a dialog to collect values to use in filtering
the report, or assigning its recordsource on the fly.
2. in Format events, draw lines.
3. in Detail events, move and resize controls and change their
ControlSources.
That's all I ever do (except for the NoData event, of course). None
of those require looking at data in the report's Fields collection,
so I've never noticed that something that worked in A97 no longer
works. It also means I never did it in A97, as any number of my apps
got converted to A2000 and the reports did not break.
In poking around with this, I noticed something odd. I thought maybe
that I could use the report's .Recordset property to get a field
value, but that doesn't work -- it gives an error message saying
"this is not available in an MDB." I can't figure out what it *is*
available in -- an ADP? The help file for the .Recordset property
says nothing about limitations of using it in a report, so I'm
pretty mystified.
It's also odd that the report module's Intellisense list includes
the fields in the recordset.
I wonder if this is really an intentional change or not. As I've
noted elsewhere, referring to columns in the Fields collection of a
form is also not 100% reliable and sometimes requires a hidden
control to get around the issue. The fact that it's unreliable
suggests to me that it's not by design. And I've always seen it as a
result of the alteration of the VBA project to be a single BLOB
instead of individual objects, and of the decoupling of the forms
from Jet in order to support recordsets of different types.
> FieldName in a forms module. So, me.fieldName
> usually works in a form (regardless if their is a text box
> on the form, but in the format events in a reports code module,
> me.Fieldname don't work unless a text box is placed on the
> report that is bound to the column.
It used to work (i.e., in A97). I never noticed that it no longer
does.
But I'm not sure that this means that report modules are different
from form modules so much as it is a result of the fact that reports
are very different animals than forms.
> We often see questions in this newsgroup where someone
> moved their code from a forms code (class) module into an
> standard code module (or even a class code module), and then
> wonder why they can't use me.fieldName anymore.
Well, that's just novice ignorance, a failure to understand what
they are doing.
> In a nutshell, my "point" here is that while do seem to have
> "quite a few" names for macros, it not a whole lot different then
> that of the several types of class modules we have (forms,
> reports, class modules).
I disagree.
> I simply just spent some extra time to point out the terminology
> we have for macros, and one will often need to distinguish between
> the different types when discussing them..
Yes, and I think that the problems that come with this are evident
in your exchange with Bob Alston, where it looked to me like you
were giving pretty clear instructions, but he had missed the
web/client distinction on the front end (as well as the Office Live
vs. Office Small Business Live). If an experienced programmer like
him has trouble seeing the distinction, I expect it to be the source
of a lot of frequently-asked questions in the newsgroups.
David W. Fenton
news:ib65h51fpln317cck...@4ax.com:
> Albert, the way I understand things, that's not a valid
> example of a distinction between different "types" of
> modules and I believe that report modules and form modules
> are the same thing. I'm pretty sure that he difference you
> cite is an artifact of MS's implementation of the *form*
> object where they create the incomplete, buggy and
> artificial AccessField thingy as a substitute for fields not
> bound to a control.
>
> Allen Browne has discussed this in several posts and
> strongly recommnds that every field referenced in a VBA
> procedure be bound to a control.
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.
While the whole Fields/Controls mega-collection as default
collection for the Me object in forms is awfully convenient, it has
always bothered me.
The fact is, reports in A97 worked the same as forms do now, with
the exception of events where the recordset didn't yet exist (a
report's OnOpen is not happening in the same data context as a
form's), or where the current record in the recordset is not what
you'd expect (in OnActivate, the record pointer is on the *next*
record, not the one that's being displayed onscreen). Thus, forms
and reports are *different*, not because of distinct types of
attached class modules, but because the relationship between a
report and it's data buffer is not identical.
David W. Fenton
> In the above report example, it is based on a table where the city
> field exists. In fact, during coding your get intel-sense. But, if
> your try to run the above report, you get an error message. Just
> try it...
I did, and it didn't work.
But in A97 it *did* work, so this seems to be something introduced
in A2000 (and I tested in A2000 and it behaves as you say, just as
it does in A2003).
This is not a difference between the form and report class modules,
but in the type of object the class module is bound to. The
relationship between the report or form's display and the data
buffer is different, and because of that, looking at the data from
the report module has different results.
I don't quite understand why the fields collection shows up in a
report's Intellisense list if it's unavailable, though, and this
makes me think that this is not something that was implemented by
design, but some kind of unintended side effect of other changes
introduced in A2000.
Albert D. Kallal
> 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?
David W. Fenton
> 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.