Running Access97 Pgm. in Access03

[Guest]

A program written years ago in access97 is now required to run on a new
computer which has access2003 installed. Testing it on my machine, alls well
until I select the printer selection routine. A runtime error is triggered
shutting down the program. Only just recently getting my feet wet in
access03, I thought I'd put this out there in hope some one could give me a
head start on what the differences would be with regard to printer selection
requirements.

Thanks.

 

[Albert D.Kallal]

Well, first, you "hope" that the original design did not save the printer
settings with a report.
(the reason for this is simply install a new printer driver, or even a
printer with a SLIGHTLY different name will cause the printer setting to be
lost).

Since printers and printer names can change a bit, about the only solution
that will keep you out of a room with padded walls is to NOT set the printer
in the first place.

In access 2002 and later, there is a built in printer object, and it lets
you switch the printer with ease.

(with access 97, you have to jump super hoops...like a trained seal...).

Now, with later versions...we finally have a nice built in printer object.

So, you can use:
You can use:

Set Application.Printer = Application.Printers("HP LaserJet Series II")

So, to save the current printer...then switch..and then switch back....

you can use:

dim strDefaultPrinter as string

' get current default printer.
strDefaultPrinter = Application.Printer.DeviceName

' switch to printer of your choice:

Set Application.Printer = Application.Printers("HP LaserJet Series II")

do whatever.

Swtich back.

Set Application.Printer = Application.Printers(strDefaultPrinter)

 

[Guest]

Normal operation with access97 this pgm used the Print dialog box to select
the destination printer, using the "ShowPrinter" method. I believe this is
similar to what Win 98 to register the default printer.

 

[aatcbbtccctc]

If you still have the source-code (ie. a normal MDB file, not an MDE
file), you just need to disable any general error trapping, so the
runtime error stops directly on the actual line that has the error.
Then you can post the error message & the lines before & after the
error, and we can say what's causing it.

For example:

sub blah()
on error goto error_trap << COMMENT THIS OUT.
...
...
...
error_trap:
msgbox etc.
end sub

HTH,
TC

 

[Guest]

Yes, I believe I can get my hands on the source code. Soon as I do, I'll post
this portion.

 

[TC]

Make sure you show the actual line that gets the runtime error, and
what the error message is

TC

 

[Guest]

Thanks, I will.

 

[Guest]

Following is all I can find regarding printer selection feature. I believe
this is an active X routine which may not be supported in the new access???

I decided to see what would happen when converting to the new access. As
before, the pgm. works without a hitch until I select (click) the printer
selection routine. Now instead of crashing, this function has been disabled
through the conversion. Guess that's not a bad thingh except I'm back to
needing the ability to select printers.

Private Sub PrinterCommand1_Click()
Dim CommonDialog1 As Object
Set CommonDialog1 = New CommonDialog
CommonDialog1.Flags = &H4
CommonDialog1.Orientation = 2
CommonDialog1.PrinterDefault = True
CommonDialog1.ShowPrinter
End Sub

 

[TC]

What do you mean, the function has been "disabled through the
conversion"? Is the code you show, still there? If so, what stops you
from trying to run it? In what sense has it been "disabled"?

The code seems to be using the "Common Dialogs" control. I think that
is comm???.ocx, or somesuch (I've never used it myself). Open any
module, then see if there is a reference listed as "MISSING" in Tools :
References. If there /is/, that could stop all your VBA code from
executing properly.

HTH,
TC

 

[Guest]

Once converted, the CommandButton to invoke the printer selection routine has
been disabled. This obviously happened during the conversion. I'll dig futher
then get back.

You're assumption is correct regarding the Common Dialog control. What I
have pasted here is all the code available without having the code in the
*.OCX

 

[MacDermott]

Is the Common dialog control even available on your Access 2003 machine?
That's a real troublesome control; many experienced developers prefer not to
use it.
If you only need to run this program on Access 2002-2003 machines, you can
rewrite it to use the Printer object; if it still needs to run under Access
97, you can replace the Common Dialogs control with API calls.
(www.allapi.com is a good source.)

 

[Guest]

I believe you are correct in that the Common dialog control may not be
available on this machine. Running through dbug, I get an runtime error 429
stating that "ActiveX component can't create this object."

No it will not be necessary for this program to run on Access 97 again.
Being real green with Access 2003, can you point me in the direction for a
routine that will replace this control for selecting the default printer?
Thanks.

 

[TC]

Look up the "Printers" object in F1 help.

HTH,
TC

 

[TC]

Sorry, "Printer" object signular.

TC

 

[Guest]

Thanks TC, will do.

 

[Guest]

Before proceeding I have another question. If there would never be but one
printer (default) is it necessary to provide printer selection code? As a
different way to ask: Does Access always print to the default printer. The
user's system is one computer/one printer.

 

[Douglas J. Steele]

It depends.

When you define a report, you have the option of assigning the report to a
specific printer (on the Page tab under File | Page Setup). If you've
assigned a specific printer, Access will try to use it. If the report is set
for Default Printer, though, then that's what Access will use.

 

[Guest]

Thanks, that answers my question. I believe the K.I.S.S. logic keeps me out
of trouble....more times than not.