PaperSize

F

FPS, Romney

Hi all,

Losing paper size (No. 10 envelope) when distributing FE to 2003 users with
other printers. After looking through many postings (and understanding few),
I thought this should work, but it doesn't. Report opens in Preview without
any errors reported, but not on No. 10 envelope -- Report/DesignView/Page
Setup/Page still shows 8-1/2 by 11 Letter.
Any ideas/suggestions?
....
'code attached to OnClick Event of "Print" button:

Dim rptName as string
rptName = "AddressEnvelopes_Client"
DoCmd.OpenReport rptName, acViewDesign, , , acHidden
Reports(rptName).Printer.PaperSize = 20
DoCmd.Close acReport, rptName, acSaveYes
DoCmd.OpenReport rptName, acViewPreview, , , acWindowNormal

Thank you.
Mark
 
G

Graham Mandeno

Hi Mark

Are your users able to modify the design of your FE objects? Most people
deploy FEs as MDEs or at least as user-level secured MDBs to prevent users
from making design changes.

I suggest you try setting the paper size in the Report_Open event procedure:

Me.Printer.PaperSize = 20
 
M

Mark

Thank you, Graham

I neglected to mention a crucial point and I apologize:
I do the design work in 97, which doesn't have the printer object, so the
code won't compile.

I guess I need a '97 version of "Me.Printer.PaperSize = 20" which will
accomplish the same thing and which will also be compatible with 2003.

.... point taken on the value of MDE. I've been fortunate ... haven't had any
users make design changes (yet!)

Mark

Graham Mandeno said:
Hi Mark

Are your users able to modify the design of your FE objects? Most people
deploy FEs as MDEs or at least as user-level secured MDBs to prevent users
from making design changes.

I suggest you try setting the paper size in the Report_Open event procedure:

Me.Printer.PaperSize = 20

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand


FPS said:
Hi all,

Losing paper size (No. 10 envelope) when distributing FE to 2003 users
with
other printers. After looking through many postings (and understanding
few),
I thought this should work, but it doesn't. Report opens in Preview
without
any errors reported, but not on No. 10 envelope -- Report/DesignView/Page
Setup/Page still shows 8-1/2 by 11 Letter.
Any ideas/suggestions?
...
'code attached to OnClick Event of "Print" button:

Dim rptName as string
rptName = "AddressEnvelopes_Client"
DoCmd.OpenReport rptName, acViewDesign, , , acHidden
Reports(rptName).Printer.PaperSize = 20
DoCmd.Close acReport, rptName, acSaveYes
DoCmd.OpenReport rptName, acViewPreview, , , acWindowNormal

Thank you.
Mark
 
J

Jack Leach

Versions before 2002 didn't have the builtin printer object, so you need to
take a different route.

Here is a module from mvps.org/access that has code to programmatically
change printer settings

http://mvps.org/access/reports/rpt0009.htm

also,

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

Albert Kallal has some less extruciating code here, but for changing the
default printer only, rather than paper size, tray, orientation, etc.

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)



Mark said:
Thank you, Graham

I neglected to mention a crucial point and I apologize:
I do the design work in 97, which doesn't have the printer object, so the
code won't compile.

I guess I need a '97 version of "Me.Printer.PaperSize = 20" which will
accomplish the same thing and which will also be compatible with 2003.

.... point taken on the value of MDE. I've been fortunate ... haven't had any
users make design changes (yet!)

Mark

Graham Mandeno said:
Hi Mark

Are your users able to modify the design of your FE objects? Most people
deploy FEs as MDEs or at least as user-level secured MDBs to prevent users
from making design changes.

I suggest you try setting the paper size in the Report_Open event procedure:

Me.Printer.PaperSize = 20

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand


FPS said:
Hi all,

Losing paper size (No. 10 envelope) when distributing FE to 2003 users
with
other printers. After looking through many postings (and understanding
few),
I thought this should work, but it doesn't. Report opens in Preview
without
any errors reported, but not on No. 10 envelope -- Report/DesignView/Page
Setup/Page still shows 8-1/2 by 11 Letter.
Any ideas/suggestions?
...
'code attached to OnClick Event of "Print" button:

Dim rptName as string
rptName = "AddressEnvelopes_Client"
DoCmd.OpenReport rptName, acViewDesign, , , acHidden
Reports(rptName).Printer.PaperSize = 20
DoCmd.Close acReport, rptName, acSaveYes
DoCmd.OpenReport rptName, acViewPreview, , , acWindowNormal

Thank you.
Mark
 
F

FPS, Romney

Thank you, Jack
Yes, I've looked at those references. Still confused. Perhaps this is asking
too much, but could you please explain the overall concept -- just the
highlights -- of what the process is ... i.e., what needs to be accomplished
through code for "No. 10 envelope" (4-1/8 x 9-1/2) to mean the same thing to
two different printers (even though both printers have this listed as a
standard selection)?
"highlights" such as:
1. First the code must ...
2. Then the code ...
etc.

I looked under Help for PrtDevMode and then looked through the example.
This involves (I think) opening the report in Design View through code every
time the report is run. If so, then I'm wondering if it's not more efficient
to simply open the report myself in Design View one time at the office when
I convert from 97 to 2000/2003, select No. 10 envelope (again), saving the
form and then distribute to 2003/2007 users.

Albert Kallal's code has a section in it that worries me (maybe just because
I don't understand it enough):

' Below is optional, and should be done. It updates the existing windows
' so the "default" printer icon changes. If you don't do the below..then
' you will often see more than one printer as the default! The reason *not*
' to do the SendMessage is that many open applications will now sense
' the change in printer. I vote to leave it in..but your case you might not
want this.

Mark


Jack Leach said:
Versions before 2002 didn't have the builtin printer object, so you need to
take a different route.

Here is a module from mvps.org/access that has code to programmatically
change printer settings

http://mvps.org/access/reports/rpt0009.htm

also,

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

Albert Kallal has some less extruciating code here, but for changing the
default printer only, rather than paper size, tray, orientation, etc.

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)



Mark said:
Thank you, Graham

I neglected to mention a crucial point and I apologize:
I do the design work in 97, which doesn't have the printer object, so the
code won't compile.

I guess I need a '97 version of "Me.Printer.PaperSize = 20" which will
accomplish the same thing and which will also be compatible with 2003.

.... point taken on the value of MDE. I've been fortunate ... haven't had any
users make design changes (yet!)

Mark

Graham Mandeno said:
Hi Mark

Are your users able to modify the design of your FE objects? Most people
deploy FEs as MDEs or at least as user-level secured MDBs to prevent users
from making design changes.

I suggest you try setting the paper size in the Report_Open event procedure:

Me.Printer.PaperSize = 20

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand


Hi all,

Losing paper size (No. 10 envelope) when distributing FE to 2003 users
with
other printers. After looking through many postings (and understanding
few),
I thought this should work, but it doesn't. Report opens in Preview
without
any errors reported, but not on No. 10 envelope -- Report/DesignView/Page
Setup/Page still shows 8-1/2 by 11 Letter.
Any ideas/suggestions?
...
'code attached to OnClick Event of "Print" button:

Dim rptName as string
rptName = "AddressEnvelopes_Client"
DoCmd.OpenReport rptName, acViewDesign, , , acHidden
Reports(rptName).Printer.PaperSize = 20
DoCmd.Close acReport, rptName, acSaveYes
DoCmd.OpenReport rptName, acViewPreview, , , acWindowNormal

Thank you.
Mark
 
F

FPS, Romney

Probably stupid question of the day, but I don't suppose there's a way to
"trick" Access97 into compiling code that has a "hidden" non-Access97
command is there?
Something along the lines of:
Dim strCommand As String
strCommand = "Me.Printer.PaperSize = 20"
If SysCmd(acSysCmdAccessVer) <> "8.0" Then
strCommand
Else
'do nothing
End If

Mark
 
J

Jack Leach

Sorry, I've never really worked with these... in fact I've never even looked
at either set of code before, so I won't be much help.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



FPS said:
Thank you, Jack
Yes, I've looked at those references. Still confused. Perhaps this is asking
too much, but could you please explain the overall concept -- just the
highlights -- of what the process is ... i.e., what needs to be accomplished
through code for "No. 10 envelope" (4-1/8 x 9-1/2) to mean the same thing to
two different printers (even though both printers have this listed as a
standard selection)?
"highlights" such as:
1. First the code must ...
2. Then the code ...
etc.

I looked under Help for PrtDevMode and then looked through the example.
This involves (I think) opening the report in Design View through code every
time the report is run. If so, then I'm wondering if it's not more efficient
to simply open the report myself in Design View one time at the office when
I convert from 97 to 2000/2003, select No. 10 envelope (again), saving the
form and then distribute to 2003/2007 users.

Albert Kallal's code has a section in it that worries me (maybe just because
I don't understand it enough):

' Below is optional, and should be done. It updates the existing windows
' so the "default" printer icon changes. If you don't do the below..then
' you will often see more than one printer as the default! The reason *not*
' to do the SendMessage is that many open applications will now sense
' the change in printer. I vote to leave it in..but your case you might not
want this.

Mark


Jack Leach said:
Versions before 2002 didn't have the builtin printer object, so you need to
take a different route.

Here is a module from mvps.org/access that has code to programmatically
change printer settings

http://mvps.org/access/reports/rpt0009.htm

also,

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

Albert Kallal has some less extruciating code here, but for changing the
default printer only, rather than paper size, tray, orientation, etc.

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)



Mark said:
Thank you, Graham

I neglected to mention a crucial point and I apologize:
I do the design work in 97, which doesn't have the printer object, so the
code won't compile.

I guess I need a '97 version of "Me.Printer.PaperSize = 20" which will
accomplish the same thing and which will also be compatible with 2003.

.... point taken on the value of MDE. I've been fortunate ... haven't had any
users make design changes (yet!)

Mark

Hi Mark

Are your users able to modify the design of your FE objects? Most people
deploy FEs as MDEs or at least as user-level secured MDBs to prevent users
from making design changes.

I suggest you try setting the paper size in the Report_Open event
procedure:

Me.Printer.PaperSize = 20

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand


Hi all,

Losing paper size (No. 10 envelope) when distributing FE to 2003 users
with
other printers. After looking through many postings (and understanding
few),
I thought this should work, but it doesn't. Report opens in Preview
without
any errors reported, but not on No. 10 envelope --
Report/DesignView/Page
Setup/Page still shows 8-1/2 by 11 Letter.
Any ideas/suggestions?
...
'code attached to OnClick Event of "Print" button:

Dim rptName as string
rptName = "AddressEnvelopes_Client"
DoCmd.OpenReport rptName, acViewDesign, , , acHidden
Reports(rptName).Printer.PaperSize = 20
DoCmd.Close acReport, rptName, acSaveYes
DoCmd.OpenReport rptName, acViewPreview, , , acWindowNormal

Thank you.
Mark
 
F

FPS, Romney

Understood. Thank you, though, for the references.
Mark

Jack Leach said:
Sorry, I've never really worked with these... in fact I've never even looked
at either set of code before, so I won't be much help.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



FPS said:
Thank you, Jack
Yes, I've looked at those references. Still confused. Perhaps this is asking
too much, but could you please explain the overall concept -- just the
highlights -- of what the process is ... i.e., what needs to be accomplished
through code for "No. 10 envelope" (4-1/8 x 9-1/2) to mean the same thing to
two different printers (even though both printers have this listed as a
standard selection)?
"highlights" such as:
1. First the code must ...
2. Then the code ...
etc.

I looked under Help for PrtDevMode and then looked through the example.
This involves (I think) opening the report in Design View through code every
time the report is run. If so, then I'm wondering if it's not more efficient
to simply open the report myself in Design View one time at the office when
I convert from 97 to 2000/2003, select No. 10 envelope (again), saving the
form and then distribute to 2003/2007 users.

Albert Kallal's code has a section in it that worries me (maybe just because
I don't understand it enough):

' Below is optional, and should be done. It updates the existing windows
' so the "default" printer icon changes. If you don't do the below..then
' you will often see more than one printer as the default! The reason *not*
' to do the SendMessage is that many open applications will now sense
' the change in printer. I vote to leave it in..but your case you might not
want this.

Mark


Jack Leach said:
Versions before 2002 didn't have the builtin printer object, so you
need
to
take a different route.

Here is a module from mvps.org/access that has code to programmatically
change printer settings

http://mvps.org/access/reports/rpt0009.htm

also,

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

Albert Kallal has some less extruciating code here, but for changing the
default printer only, rather than paper size, tray, orientation, etc.

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)



:

Thank you, Graham

I neglected to mention a crucial point and I apologize:
I do the design work in 97, which doesn't have the printer object,
so
the
code won't compile.

I guess I need a '97 version of "Me.Printer.PaperSize = 20" which will
accomplish the same thing and which will also be compatible with 2003.

.... point taken on the value of MDE. I've been fortunate ...
haven't
had any
users make design changes (yet!)

Mark

Hi Mark

Are your users able to modify the design of your FE objects? Most people
deploy FEs as MDEs or at least as user-level secured MDBs to
prevent
users
from making design changes.

I suggest you try setting the paper size in the Report_Open event
procedure:

Me.Printer.PaperSize = 20

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand


Hi all,

Losing paper size (No. 10 envelope) when distributing FE to 2003 users
with
other printers. After looking through many postings (and understanding
few),
I thought this should work, but it doesn't. Report opens in Preview
without
any errors reported, but not on No. 10 envelope --
Report/DesignView/Page
Setup/Page still shows 8-1/2 by 11 Letter.
Any ideas/suggestions?
...
'code attached to OnClick Event of "Print" button:

Dim rptName as string
rptName = "AddressEnvelopes_Client"
DoCmd.OpenReport rptName, acViewDesign, , , acHidden
Reports(rptName).Printer.PaperSize = 20
DoCmd.Close acReport, rptName, acSaveYes
DoCmd.OpenReport rptName, acViewPreview, , , acWindowNormal

Thank you.
Mark
 
G

Graham Mandeno

Hi Mark

Not a stupid question at all!

I haven't tried this, but it ought to work. If a variable is declared "As
Object" then no compile-time checks can be made against its methods and
properties. So, you should be able to do this:

If Val(SysCmd(acSysCmdAccessVer)) > 8 Then

Dim AnonymousMe as Object
Set AnonymousMe = Me
AnonymousMe.Printer.PaperSize = 20
Set AnonymousMe = Nothing
End If
 
G

Graham Mandeno

Hi Mark

I just remembered that there is a built-in compiler constant, "VBA6", that
was introduced in Access 2000. While the method I suggested below is a
useful one for bypassing compile-time object model checks, you could also
use conditional compilation:

#If VBA6 Then
Me.Printer.PaperSize = 20
#End If

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand

Graham Mandeno said:
Hi Mark

Not a stupid question at all!

I haven't tried this, but it ought to work. If a variable is declared "As
Object" then no compile-time checks can be made against its methods and
properties. So, you should be able to do this:

If Val(SysCmd(acSysCmdAccessVer)) > 8 Then

Dim AnonymousMe as Object
Set AnonymousMe = Me
AnonymousMe.Printer.PaperSize = 20
Set AnonymousMe = Nothing
End If

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand

FPS said:
Probably stupid question of the day, but I don't suppose there's a way to
"trick" Access97 into compiling code that has a "hidden" non-Access97
command is there?
Something along the lines of:
Dim strCommand As String
strCommand = "Me.Printer.PaperSize = 20"
If SysCmd(acSysCmdAccessVer) <> "8.0" Then
strCommand
Else
'do nothing
End If

Mark
 
F

FPS, Romney

Terrific! Thank you, Graham
Mark

Graham Mandeno said:
Hi Mark

I just remembered that there is a built-in compiler constant, "VBA6", that
was introduced in Access 2000. While the method I suggested below is a
useful one for bypassing compile-time object model checks, you could also
use conditional compilation:

#If VBA6 Then
Me.Printer.PaperSize = 20
#End If

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand

Graham Mandeno said:
Hi Mark

Not a stupid question at all!

I haven't tried this, but it ought to work. If a variable is declared "As
Object" then no compile-time checks can be made against its methods and
properties. So, you should be able to do this:

If Val(SysCmd(acSysCmdAccessVer)) > 8 Then

Dim AnonymousMe as Object
Set AnonymousMe = Me
AnonymousMe.Printer.PaperSize = 20
Set AnonymousMe = Nothing
End If

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand

FPS said:
Probably stupid question of the day, but I don't suppose there's a way to
"trick" Access97 into compiling code that has a "hidden" non-Access97
command is there?
Something along the lines of:
Dim strCommand As String
strCommand = "Me.Printer.PaperSize = 20"
If SysCmd(acSysCmdAccessVer) <> "8.0" Then
strCommand
Else
'do nothing
End If

Mark

Hi all,

Losing paper size (No. 10 envelope) when distributing FE to 2003 users
with
other printers. After looking through many postings (and understanding
few),
I thought this should work, but it doesn't. Report opens in Preview
without
any errors reported, but not on No. 10 envelope --
Report/DesignView/Page
Setup/Page still shows 8-1/2 by 11 Letter.
Any ideas/suggestions?
...
'code attached to OnClick Event of "Print" button:

Dim rptName as string
rptName = "AddressEnvelopes_Client"
DoCmd.OpenReport rptName, acViewDesign, , , acHidden
Reports(rptName).Printer.PaperSize = 20
DoCmd.Close acReport, rptName, acSaveYes
DoCmd.OpenReport rptName, acViewPreview, , , acWindowNormal

Thank you.
Mark
 
J

Jack Leach

you could also
use conditional compilation:

#If VBA6 Then
Me.Printer.PaperSize = 20
#End If

Graham,

I've never seen the like before. Could I bother you to explain how this
works? Just curious...

Thanks,

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



Graham Mandeno said:
Hi Mark

I just remembered that there is a built-in compiler constant, "VBA6", that
was introduced in Access 2000. While the method I suggested below is a
useful one for bypassing compile-time object model checks, you could also
use conditional compilation:

#If VBA6 Then
Me.Printer.PaperSize = 20
#End If

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand

Graham Mandeno said:
Hi Mark

Not a stupid question at all!

I haven't tried this, but it ought to work. If a variable is declared "As
Object" then no compile-time checks can be made against its methods and
properties. So, you should be able to do this:

If Val(SysCmd(acSysCmdAccessVer)) > 8 Then

Dim AnonymousMe as Object
Set AnonymousMe = Me
AnonymousMe.Printer.PaperSize = 20
Set AnonymousMe = Nothing
End If

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand
 
G

Graham Mandeno

Hi Jack

In addition to the info Doug has pointed you to, it's worth noting that if
you declare CC constants in the project properties sheet then they will
disappear if you create an MDE. However, constants declared in the code
with #Const survive. Beware that constants declared in code are local only
to that module and cannot be global.

I find CC particularly useful for switching between early and late binding.
You will be aware of the advantages of using late binding when deploying an
app because of problems with missing references and version differences.
However, there are advantages in using early binding when developing, such
as intellisense, full compile-time checking of properties and methods on the
objects, and context-sensitive help.

With CC you can have the best of both worlds:

#Const EarlyBinding = 1
....
Public Function DoSomethingWithExcel()
#If EarlyBinding Then
Dim xlApp as Excel.Application
Dim xlWkb as Excel.Workbook
Debug.Assert xlCenter = -4108
Debug.Assert xlCSV = 6
#Else
Dim xlApp as Object
Dim xlWkb as Object
Const xlCenter = -4108
Const xlCSV = 6
#End If
....
End Function

With EarlyBinding turned on (set to 1) and a reference set to the Excel
object library, the first section is compiled. This gives the development
advantages mentioned above, and also verifies with Debug.Assert that our
constant values are correct.

When the project is to be deployed, all that is necessary is to remove the
referrence(s) and set EarlyBinding to 0.
 
J

Jack Leach

Thanks Graham. This certainly seems like handy information to have tucked
away in case I happen across a use for it. Nothing as of yet, but you never
know.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



Graham Mandeno said:
Hi Jack

In addition to the info Doug has pointed you to, it's worth noting that if
you declare CC constants in the project properties sheet then they will
disappear if you create an MDE. However, constants declared in the code
with #Const survive. Beware that constants declared in code are local only
to that module and cannot be global.

I find CC particularly useful for switching between early and late binding.
You will be aware of the advantages of using late binding when deploying an
app because of problems with missing references and version differences.
However, there are advantages in using early binding when developing, such
as intellisense, full compile-time checking of properties and methods on the
objects, and context-sensitive help.

With CC you can have the best of both worlds:

#Const EarlyBinding = 1
....
Public Function DoSomethingWithExcel()
#If EarlyBinding Then
Dim xlApp as Excel.Application
Dim xlWkb as Excel.Workbook
Debug.Assert xlCenter = -4108
Debug.Assert xlCSV = 6
#Else
Dim xlApp as Object
Dim xlWkb as Object
Const xlCenter = -4108
Const xlCSV = 6
#End If
....
End Function

With EarlyBinding turned on (set to 1) and a reference set to the Excel
object library, the first section is compiled. This gives the development
advantages mentioned above, and also verifies with Debug.Assert that our
constant values are correct.

When the project is to be deployed, all that is necessary is to remove the
referrence(s) and set EarlyBinding to 0.

--
Good Luck :)

Graham Mandeno [Access MVP]
Auckland, New Zealand


Jack Leach said:
Interesting.

Thanks Doug.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top