"EJO" <My****@gmail.com> wrote in
news:11**********************@j33g2000cwa.googlegr oups.com:
thanks, for the reply; please don't be offended, but the
suggestion of using a report was exactly the suggestion I was
trying to avoid.
As an engineer, I view having to build a report in order to
print the record displayed in the form as being duplicate work
and worse, having to maintain two documents is entirely
inefficient. Both are antithetical to eveything I learned
about being an engineer! Unfortunately, being a programmer by
circumstance rather than by trade, these minor differences are
frustrating and seem more a 'patch' than a fix. Kudos to you
pros who can keep up with all of it and help us
not-so-understanding folks!
I consider myself an engineer too, (so does my boss), but I
interpret your view of creating a report being duplication of
work in the vein of "I have a tool! I don't need another tool."
My reply to this is "you have a hammer. you also need a
screwdriver."
Forms I design have all sorts of things that I need like command
buttons, record selectors, areas of colour, controls used to
enter filter criteria that simply get in the way of presenting
data to the end user. a separate report lets me reorganize the
data layout for efficiency of understanding, whereas the form is
built for data entry, or data location, or updating.
Each is a separate task, and each has an optimized layout for
that one purpose.
As to your original question, the issue is again one of
interpretation, in this case of AcSelection. To me the Ac prefix
indicates that the selection is at the Access level, which
contains the object form, or query or report... Had the constant
been called frmSelection, then it would refer to the control or
record selected on the form.
--
Bob Quintal
PA is y I've altered my email address.