Can't Enter Special Characters

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am trying to send "<esc>p" as part of a report to open a Cash Drawer
attached to a POS Docket Printer. I know I should be able to enter the <esc>
character by holding down the <Alt> Key and typing "027", but whenever I try
this within the VBA editor so that I can assign it as the value of an unbound
text control, or even enter it as the caption of a label on the Report, my
machine won't accept it. It just produces a dull "error tone" and nothing
happens.

Anyone got any idea what's going on? I'm using Windows SP2 with Access 2002.
 
Brian said:
I am trying to send "<esc>p" as part of a report to open a Cash Drawer
attached to a POS Docket Printer. I know I should be able to enter the <esc>
character by holding down the <Alt> Key and typing "027", but whenever I try
this within the VBA editor so that I can assign it as the value of an unbound
text control, or even enter it as the caption of a label on the Report, my
machine won't accept it. It just produces a dull "error tone" and nothing
happens.

Anyone got any idea what's going on? I'm using Windows SP2 with Access 2002.
Click to expand...

I think you could enter that as a text box expression:

=Chr(27)

But, while I've never tried it, I don't think it will do
what you want. Aren't you supposed to talk to the device
using the serial port?
 
In the good old days Docket Printes used to hang off COM Ports and any time
you sent any characters to the Printer the Cash Drawer would open.

These days they use USB and appear as ordinary Widows Printers. There is
then a connection from the printer to the Cash Drawer, which when you send
the appropriate esc sequence to opens the Cash Drawer. This now means you
can open the Drawer only when you want to.

The CHR(27) idea had already occured to me before I got your Post and I had
altered my Report. I've yet to try it out. I'll let you know when I have.
 
In general, Access reports are graphics images that make no
sense to a text only device. I suppose Access may (ir may
not?) be smart enough to deal with a text only device if you
can figure out how to tell it what's going on.

Why not use File I/O to talk to the device?
 
Access uses Windows for reports.

Windows uses Printer Drivers for reports.

Some Printer Drivers represent 'Text' Printers.

These Printer Drivers take the text part of the
printer commands. They also sometimes convert some
of the graphics to equivalent text characters (for
example, lines can sometimes be converted to text
lines).

This is how Access sends the text and a line graphic
from a report to windows using the gdi32 api:
x& = StartPage(hDC&)
X& = Rectangle(hDC&, 10, 10, 1000, 150)
x& = TextOut(hDC&, 30, 20, MyString$, Len(MyString$))
x& = EndPage(hDC&)

This is also more or less the way the printer driver
receives it, although it is commonly spooled to a
file first.

That is, a raw printer file is actually a script
for an Access report, not a bitmap of an Access
report.

The part of the graphic script definition which
allowed you to do callbacks to windows was the
subject of a recent security patch.

(david)


Marshall Barton said:
In general, Access reports are graphics images that make no
sense to a text only device. I suppose Access may (ir may
not?) be smart enough to deal with a text only device if you
can figure out how to tell it what's going on.

Why not use File I/O to talk to the device?
--
Marsh
MVP [MS Access]


Brian said:
In the good old days Docket Printes used to hang off COM Ports and any
time
you sent any characters to the Printer the Cash Drawer would open.

These days they use USB and appear as ordinary Widows Printers. There is
then a connection from the printer to the Cash Drawer, which when you send
the appropriate esc sequence to opens the Cash Drawer. This now means you
can open the Drawer only when you want to.

The CHR(27) idea had already occured to me before I got your Post and I
had
altered my Report. I've yet to try it out. I'll let you know when I
have.
Click to expand...
Click to expand...
 
Back
Top