Set report margins in code?

Hi All,

I'm using A2K and need to print a specific pre-printed form. I know that
once I have that report on a particular computer screen I can select "Page
Setup" and change the margins to get the different fields I'm printing where
I need them to print (fine tuning type of changes as all the controls are
basically printing where needed--say on a pre-printed check that's inserted
into the printer). However, if I then have another user try to print that
same check on THIER printer, the margins aren't set correctly and it prints
everything off either high/low and/or left/right by whatever.

I know that I could have a table on each users system with a record for
whatever margin settings would be needed (once set up by the user or me or
whatever). But can I get those margin settings to be used by a report?
Where do I stick them if that's possible.

Yeah, I know I can set it at the time of printing...but I don't want my
USERS to do that. Plus, I see down the road I'll want to compile all this
and use a runtime version...so the user wouldn't have access to that Page
Setup area anyway.

Possible?
ron

Re: Set report margins in code?

"Ron" wrote in message
news:oMkZi.1342$VB6.1261@trnddc06...
> Hi All,
>
> I'm using A2K and need to print a specific pre-printed form. I know that
> once I have that report on a particular computer screen I can select "Page
> Setup" and change the margins to get the different fields I'm printing
> where I need them to print (fine tuning type of changes as all the
> controls are basically printing where needed--say on a pre-printed check
> that's inserted into the printer). However, if I then have another user
> try to print that same check on THIER printer, the margins aren't set
> correctly and it prints everything off either high/low and/or left/right
> by whatever.
>
> I know that I could have a table on each users system with a record for
> whatever margin settings would be needed (once set up by the user or me or
> whatever). But can I get those margin settings to be used by a report?
> Where do I stick them if that's possible.
>
> Yeah, I know I can set it at the time of printing...but I don't want my
> USERS to do that. Plus, I see down the road I'll want to compile all this
> and use a runtime version...so the user wouldn't have access to that Page
> Setup area anyway.
>
> Possible?
> ron

Take a look at the Printer object in help. Does exactly what you want.

You need to use the Printer property of your report.

Re: Set report margins in code?

Don't think there is a printer in A2K

I know it's not much help, but here is some code. Think it set a word
document to the same size as a report. Not sure

Function SetUpPage(Rpt As Report)

Dim PrtMipString As str_PRTMIP
Dim PM As type_PRTMIP
Dim DevString As str_DEVMODE
Dim DM As type_DEVMODE
Dim strDevModeExtra As String

Const CP = 567 / 28.35 ' Twips / mm per cm; 1 cm =
28.35 points

On Error GoTo SetUpPage_Err

PrtMipString.strRGB = Rpt.PrtMip
LSet PM = PrtMipString

With ActiveDocument.PageSetup
.LineNumbering.Active = False
.Orientation = wdOrientPortrait
.LeftMargin = PM.xLeftMargin / CP ' LeftMargin
.RightMargin = PM.xRightMargin / CP ' RightMargin
.TopMargin = PM.yTopMargin / CP ' TopMargin
.BottomMargin = PM.yBotMargin / CP ' BottomMargin
.Gutter = 0
.HeaderDistance = 0
.FooterDistance = 0

If Not IsNull(Rpt.PrtDevMode) Then
strDevModeExtra = Rpt.PrtDevMode
' Gets current DEVMODE structure.
DevString.RGB = strDevModeExtra
LSet DM = DevString
.Orientation = DM.intOrientation - 1 ' 1-Portrait,
2-Landscape
If DM.intOrientation = 1 Then
.PageHeight = DM.intPaperLength * 28.35 / 100
.PageWidth = DM.intPaperWidth * 28.35 / 100
Else
.PageWidth = DM.intPaperLength * 28.35 / 100
.PageHeight = DM.intPaperWidth * 28.35 / 100
End If
LSet DevString = DM ' Update property.
Mid(strDevModeExtra, 1, 94) = DevString.RGB
End If
End With

NextPageAddBookMark ' Add second page

Call OutputReport(Rpt) ' Any Pictures

Exit Function

SetUpPage_Err:
MsgBox Err.Description

End Function

Look up PrtDevMode and PrtMip

Phil
"Stuart McCall" wrote in message
news:fh4ot7$jo8$1$8302bc10@news.demon.co.uk...
> "Ron" wrote in message
> news:oMkZi.1342$VB6.1261@trnddc06...
>> Hi All,
>>
>> I'm using A2K and need to print a specific pre-printed form. I know that
>> once I have that report on a particular computer screen I can select
>> "Page Setup" and change the margins to get the different fields I'm
>> printing where I need them to print (fine tuning type of changes as all
>> the controls are basically printing where needed--say on a pre-printed
>> check that's inserted into the printer). However, if I then have another
>> user try to print that same check on THIER printer, the margins aren't
>> set correctly and it prints everything off either high/low and/or
>> left/right by whatever.
>>
>> I know that I could have a table on each users system with a record for
>> whatever margin settings would be needed (once set up by the user or me
>> or whatever). But can I get those margin settings to be used by a
>> report? Where do I stick them if that's possible.
>>
>> Yeah, I know I can set it at the time of printing...but I don't want my
>> USERS to do that. Plus, I see down the road I'll want to compile all
>> this and use a runtime version...so the user wouldn't have access to that
>> Page Setup area anyway.
>>
>> Possible?
>> ron
>
> Take a look at the Printer object in help. Does exactly what you want.
>
> You need to use the Printer property of your report.
>
>
>
>
>

Re: Set report margins in code?

Actually, what I'm finding is there's no way to change these settings in
Access during run time...so if you have a run-time program, or you're
running an MDE file, you can't change margin settings for the print outs at
run time...even if you need to.

Words in Access 2000 Developer's Handbook Vol 1 (page 772 to be exact),
"Warning: No matter how much you'd like this to work, you will not be able
to make design-time changes to forms or reports if your application is
running as an MDE file." And just before that, "The drawbacks? First of
all, the object must be open in Design view in order to be able to change
it's PrtDevNames property (or the PrtDevMode or PrtMips property as well)."
Am I misunderstanding this?

What do all you talented programmers do when you run into a need for this
type of adjustment? You just walk away from the business? You tell your
client "sorry, I don't do pre-printed forms."

How about a newer version of Access than 2000? Are these types of
adjustments possible with a newer Access program?

Is Access really this crippled? Or, what?
ron

"Phil Stanton" wrote in message
news:13jf2g1ane8fjc9@corp.supernews.com...
> Don't think there is a printer in A2K
>
> I know it's not much help, but here is some code. Think it set a word
> document to the same size as a report. Not sure
>
> Function SetUpPage(Rpt As Report)
>
> Dim PrtMipString As str_PRTMIP
> Dim PM As type_PRTMIP
> Dim DevString As str_DEVMODE
> Dim DM As type_DEVMODE
> Dim strDevModeExtra As String
>
> Const CP = 567 / 28.35 ' Twips / mm per cm; 1 cm =
> 28.35 points
>
> On Error GoTo SetUpPage_Err
>
> PrtMipString.strRGB = Rpt.PrtMip
> LSet PM = PrtMipString
>
> With ActiveDocument.PageSetup
> .LineNumbering.Active = False
> .Orientation = wdOrientPortrait
> .LeftMargin = PM.xLeftMargin / CP ' LeftMargin
> .RightMargin = PM.xRightMargin / CP ' RightMargin
> .TopMargin = PM.yTopMargin / CP ' TopMargin
> .BottomMargin = PM.yBotMargin / CP ' BottomMargin
> .Gutter = 0
> .HeaderDistance = 0
> .FooterDistance = 0
>
> If Not IsNull(Rpt.PrtDevMode) Then
> strDevModeExtra = Rpt.PrtDevMode
> ' Gets current DEVMODE structure.
> DevString.RGB = strDevModeExtra
> LSet DM = DevString
> .Orientation = DM.intOrientation - 1 ' 1-Portrait,
> 2-Landscape
> If DM.intOrientation = 1 Then
> .PageHeight = DM.intPaperLength * 28.35 / 100
> .PageWidth = DM.intPaperWidth * 28.35 / 100
> Else
> .PageWidth = DM.intPaperLength * 28.35 / 100
> .PageHeight = DM.intPaperWidth * 28.35 / 100
> End If
> LSet DevString = DM ' Update property.
> Mid(strDevModeExtra, 1, 94) = DevString.RGB
> End If
> End With
>
> NextPageAddBookMark ' Add second page
>
> Call OutputReport(Rpt) ' Any Pictures
>
> Exit Function
>
> SetUpPage_Err:
> MsgBox Err.Description
>
> End Function
>
> Look up PrtDevMode and PrtMip
>
> Phil
> "Stuart McCall" wrote in message
> news:fh4ot7$jo8$1$8302bc10@news.demon.co.uk...
>> "Ron" wrote in message
>> news:oMkZi.1342$VB6.1261@trnddc06...
>>> Hi All,
>>>
>>> I'm using A2K and need to print a specific pre-printed form. I know
>>> that once I have that report on a particular computer screen I can
>>> select "Page Setup" and change the margins to get the different fields
>>> I'm printing where I need them to print (fine tuning type of changes as
>>> all the controls are basically printing where needed--say on a
>>> pre-printed check that's inserted into the printer). However, if I then
>>> have another user try to print that same check on THIER printer, the
>>> margins aren't set correctly and it prints everything off either
>>> high/low and/or left/right by whatever.
>>>
>>> I know that I could have a table on each users system with a record for
>>> whatever margin settings would be needed (once set up by the user or me
>>> or whatever). But can I get those margin settings to be used by a
>>> report? Where do I stick them if that's possible.
>>>
>>> Yeah, I know I can set it at the time of printing...but I don't want my
>>> USERS to do that. Plus, I see down the road I'll want to compile all
>>> this and use a runtime version...so the user wouldn't have access to
>>> that Page Setup area anyway.
>>>
>>> Possible?
>>> ron
>>
>> Take a look at the Printer object in help. Does exactly what you want.
>>
>> You need to use the Printer property of your report.
>>
>>
>>
>>
>>
>
>

Re: Set report margins in code?

On Nov 12, 11:12 am, "Ron" wrote:
> Actually, what I'm finding is there's no way to change these settings in
> Access during run time...so if you have a run-time program, or you're
> running an MDE file, you can't change margin settings for the print outs at
> run time...even if you need to.
>
> Words in Access 2000 Developer's Handbook Vol 1 (page 772 to be exact),
> "Warning: No matter how much you'd like this to work, you will not be able
> to make design-time changes to forms or reports if your application is
> running as an MDE file." And just before that, "The drawbacks? First of
> all, the object must be open in Design view in order to be able to change
> it's PrtDevNames property (or the PrtDevMode or PrtMips property as well)."
> Am I misunderstanding this?
>
> What do all you talented programmers do when you run into a need for this
> type of adjustment? You just walk away from the business? You tell your
> client "sorry, I don't do pre-printed forms."
>
> How about a newer version of Access than 2000? Are these types of
> adjustments possible with a newer Access program?
>
> Is Access really this crippled? Or, what?
> ron

When I assess a project's needs and ascertain that they are congruent
with Access's abilities, I often use Access as a development platform.
When they are beyond Access's abilities, or incongruent with them, I
use something else.
Within that framework Access is not crippled.

My personal opinion of Access is that it is the best desktop database
and front end ever created and I know of no major claim about Access
that Microsoft makes or has made that is not true.

MDE's and the runtime have major drawbacks and short comings, many of
which are clearly documented. I have experimented with both, but have
not used either in years. I know that some are upset when a
combination of these two devices does not transform them into gifted
and accomplished programmers, but I think the expectation is
unrealistic.

As to your problem, I have written my own printing procedures which
send print-codes to printers, but that was many years ago. Have you
considered porting your reports to a separate mdb, which could be
opened from the mde when needed? It's pretty simple to write code to
design a report on the fly and with your experience with the printer
object I expect that you could include that easily.