By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,519 Members | 2,332 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,519 IT Pros & Developers. It's quick & easy.

DoCmd.PrintOut acSelection = false advertising?

P: n/a
EJO
TIA,

There is already a form (Access 2k) with the selected record and a
button with this code behind it:

DoCmd.PrintOut acSelection

Except that Access does not print the acSelection, it prints the entire
query result behind the form. How does one do what VB says it will
do:
Print the acSelection on the form?
(without doing something so antithetical to engineering as duplicating
work by creating a report, indicated by so many other articles)

Is there a patch for this bug?

Apr 20 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
did you try using a report and passing the current record's unique ID
in the Open event? Forms aren't really designed for printing out, but
for data entry.

Apr 21 '06 #2

P: n/a
"EJO" <My****@gmail.com> wrote in news:1145557535.825523.137390
@i40g2000cwc.googlegroups.com:
TIA,

There is already a form (Access 2k) with the selected record and a
button with this code behind it:

DoCmd.PrintOut acSelection

Except that Access does not print the acSelection, it prints the entire
query result behind the form. How does one do what VB says it will
do:
Print the acSelection on the form?
(without doing something so antithetical to engineering as duplicating
work by creating a report, indicated by so many other articles)

Is there a patch for this bug?


I think this is not a bug. There's no reason to think that the DoCmd Object
will be aware of what one has selected with the mouse or keys.

This prints one record for me.

Private Sub cmdPrintRecord_Click()
With DoCmd
.RunCommand acCmdSelectRecord
.PrintOut acSelection
End With
End Sub

--
Lyle Fairfield
Apr 21 '06 #3

P: n/a
EJO
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!

Apr 21 '06 #4

P: n/a
EJO
Hi, Lyle, and thanks! I tried it, but am still getting the entire
query record set. The reason I am calling this a bug is because the
code did not ask for acPrintAll, yet that is exactly what acSelection
is doing. I don't understand "There's no reason to think that the
DoCmd Object will be aware of what one has selected with the mouse or
keys." According to vb help, the PrintOut action doesn't care if I
have a form or report; but perhaps my understanding of acSelection is
not in the proper scope? When i think of acSelection, the 'record
selectors' on a form come to mind indicating the selected record (not
saying the two are related, but that is what comes to mind). Further
consider that the PrintOut action offers ranges of selection
(acPrintAll or acPages), and it re-inforces the perception that
acSelection refers to what ever record is the current record, whether
in a form or report, not the entire range of records behind the form or
report--which is what vb help says those other two actions are to
perform.

Even tried setting the 'cycle' property to 'current record'; using the
record selector to 'select' the record prior to print, and modified
just about any other setting that might even hint at how or what is
printed.

Apr 21 '06 #5

P: n/a
"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.
Apr 22 '06 #6

P: n/a
EJO
Thank you, Bob. You have put this in the proper perspective for me,
regardless of how much I may not like it ;)

Apr 24 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.