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

Which Paper Bin?

P: 39
The easiest way for me to ask what I want is to show it by example. Once inside any .mdb select FILE -> PAGE SETUP. When the PAGE SETUP window comes up, select the PAGE tab. After you select “USE SPECIFIC PRINTER” the form automatically repopulates the SIZE and SOURCE combo boxes for that specific printer. I don’t care about the SIZE combo box, but how do you know what to put into the SOURCE combo box? This is AcPrintPaperBin, right? Finally, when you click on the OK command button, what are the VB commands that execute? Thanks -Ken.
Apr 20 '08 #1
Share this Question
Share on Google+
40 Replies


NeoPa
Expert Mod 15k+
P: 31,186
I'm guessing from clues in your question that you're trying to control the settings in a report normally controlled by using Page-Setup.

I did some looking but could only find the command to open the Page-Setup dialog-box.
Expand|Select|Wrap|Line Numbers
  1. Call DoCmd.RunCommand(acCmdPageSetup)
Apr 21 '08 #2

NeoPa
Expert Mod 15k+
P: 31,186
I had a further look around for properties of a Report object that could match Paper-Size or Paper-Source and couldn't find anything at all. I'm sorry.

Let's see if anyone else can come up with anything.
Apr 21 '08 #3

P: 39
I had a further look around for properties of a Report object that could match Paper-Size or Paper-Source and couldn't find anything at all. I'm sorry.

Let's see if anyone else can come up with anything.
I love the idea of just using MS's PageSetup routine instead of building a new wheel! I tried it but I can an error 2585, "This action can't be carried out while processing a form or report event" Thats great, where else would you call it from!!! Can we fix the error 2585? Hope we can get this to work, Thanks -Ken.
Apr 21 '08 #4

NeoPa
Expert Mod 15k+
P: 31,186
Fair question (although expecting software always to work logically is perhaps a little naiëve).

I can only think of trying some timer based triggering. I'll let you know how my tests proceed.

** Edit **
No joy I'm afraid. Might work in a form but Reports have no timer based events :(
Apr 21 '08 #5

mshmyob
Expert 100+
P: 903
If you want to select your paper bin

Expand|Select|Wrap|Line Numbers
  1. Me.Printer.Paperbin = acPRBNAuto '(Default) Use paper from the current default bin
  2. Me.Printer.Paperbin = acPRBNCassette 'Use paper from the attached cassette cartridge
  3. Me.Printer.Paperbin = acPRBNEnvelope 'Use envelopes from the envelope feeder
  4. Me.Printer.Paperbin = acPRBNEnvManual ' Use envelopes from the envelope feeder, but wait for manual insertion
  5. Me.Printer.Paperbin = acPRBNFormSource ' Use paper from the forms bin
  6. Me.Printer.Paperbin = acPRBNLargeCapacity ' Use paper from the large capacity feeder
  7. Me.Printer.Paperbin = acPRBNLargeFmt ' Use paper from the large paper bin
  8. Me.Printer.Paperbin = acPRBNLower ' Use paper from the lower bin
  9. Me.Printer.Paperbin = acPRBNManual ' Wait for manual insertion of each sheet of paper
  10. Me.Printer.Paperbin = acPRBNMiddle ' Use paper from the middle bin
  11. Me.Printer.Paperbin = acPRBNSmallFmt ' Use paper from the small paper feeder
  12. Me.Printer.Paperbin = acPRBNTractor ' Use paper from the tractor feeder
  13. Me.Printer.Paperbin = acPRBNUpper ' Use paper from the upper bin
  14.  
I don't know if this is what you were looking for so if it isn't just ignore.

I know it isn't for a report but if you set it before running the report the report will use the tray you set.

Use the Me.Printer.Papersize property to set the papersizes.

cheers,
Apr 21 '08 #6

P: 39
I like that last reply, but how do you know which paperbin choices to limit user to depending on the printer? I guess I'm asking, how do you get the print driver to tell you its paperbin / papersize limitations. Thanks -Ken.
Apr 21 '08 #7

mshmyob
Expert 100+
P: 903
Check out the following Microsoft link to get your printer capabilities including your paper bin sizes.

If you have trouble implementing I will create a simplified code for you.

Retrive Printer Capabilities


cheers,

I like that last reply, but how do you know which paperbin choices to limit user to depending on the printer? I guess I'm asking, how do you get the print driver to tell you its paperbin / papersize limitations. Thanks -Ken.
Apr 21 '08 #8

NeoPa
Expert Mod 15k+
P: 31,186
If you want to select your paper bin
Expand|Select|Wrap|Line Numbers
  1. Me.Printer.Paperbin = acPRBNAuto '(Default) Use paper from the current default bin
  2. ...
  3. Me.Printer.Paperbin = acPRBNUpper ' Use paper from the upper bin
  4.  
...
This looks good Mshmyob, but I couldn't find a .Printer property in either the Report or the Form objects. Can you say what Me. refers to in this context?
Apr 22 '08 #9

mshmyob
Expert 100+
P: 903
Hello Neo,

As you said there is nothing for the Reports. This has to be done in say a form that calls the report.

Assume you just want to print to the DEFAULT printer and want to print to the MANUAL feeder and change the print size to LEGAL.

Expand|Select|Wrap|Line Numbers
  1. Dim rpt As Report
  2. Dim prtr As Printer
  3.  
  4.    Set Application.Printer = Nothing
  5.    Set prtr = Application.Printer
  6.  
  7.    'Set the default printer's paper bin to manual and paper size to legal
  8.    prtr.PaperBin = acPRBNManual
  9.    prtr.PaperSize = acPRPSLegal
  10.  
  11.  'open your report in hidden view to aplly print settings
  12.     DoCmd.OpenReport "rptName", acViewPreview, , , acHidden
  13.     Set rpt = Reports!rptName
  14.    'Set the Printer property of the report to the
  15.    'Application.Printer object
  16.    Set rpt.Printer = prtr
  17. ' now open the report in normal view to print
  18.      DoCmd.OpenReport "rptName", acViewNormal
  19.     DoCmd.Close acReport, "rptName", acSaveNo
  20. Set Application.Printer = Nothing
  21.  
Note I did not save these settings to the printer - the default printer settings stay in effect after I print.

cheers,

This looks good Mshmyob, but I couldn't find a .Printer property in either the Report or the Form objects. Can you say what Me. refers to in this context?
Apr 22 '08 #10

NeoPa
Expert Mod 15k+
P: 31,186
Line #16, with reference back to lines #1 & #2, indicate that there should be a .Printer property of an Access.Report object. I could find no reference to this in the documentation (even hidden properties) and when I tried the following line (rptTrans was an open (previewed) report at the time) it complained of "An Application-defined or Object-defined error (#2465)".
Expand|Select|Wrap|Line Numbers
  1. ?Reports("rptTrans").Printer.PaperBin
I'm using Access 2000 at work on a Win2000 server PC.
Apr 22 '08 #11

mshmyob
Expert 100+
P: 903
If I recall correctly (keep in mind my memory is not what it used to be and it was never that good to begin with) I believe this became available in Acc2002. I will check and get back to you.

cheers,

Line #16, with reference back to lines #1 & #2, indicate that there should be a .Printer property of an Access.Report object. I could find no reference to this in the documentation (even hidden properties) and when I tried the following line (rptTrans was an open (previewed) report at the time) it complained of "An Application-defined or Object-defined error (#2465)".
Expand|Select|Wrap|Line Numbers
  1. ?Reports("rptTrans").Printer.PaperBin
I'm using Access 2000 at work on a Win2000 server PC.
Apr 22 '08 #12

mshmyob
Expert 100+
P: 903
OK I have scanned the NET and I cannot find any reference in Acc2000 - The first reference I find is for ACC2002. So maybe my memory is still working. Maybe someone else can confirm.

(I'll send you an UPGRADE coupon for Xmas - ;))

cheers,
Apr 22 '08 #13

NeoPa
Expert Mod 15k+
P: 31,186
Ah :)

No worries on the coupon. I have 2003 at home and expect to get a new PC here soon (@work) with 2003 on that too (won't be touching 2007 any time soon ;)).
Apr 22 '08 #14

mshmyob
Expert 100+
P: 903
Actually I have been using 2007 for a year now and done some large apps on it and it seems to work very nicely.

cheers,

Ah :)

No worries on the coupon. I have 2003 at home and expect to get a new PC here soon (@work) with 2003 on that too (won't be touching 2007 any time soon ;)).
Apr 22 '08 #15

NeoPa
Expert Mod 15k+
P: 31,186
And so it very well should!

The fact that it adds almost nothing and the concentration of effort is to encourage more people to use it by pretending you need to know little or nothing about databases, while at the same time adding very little, irritates me greatly.

In a nutshell, you're being asked to pay extra (buy the upgrade) for them to write code to hoodwink more people into buying the package. It's just a big con that they're getting away with.

Oh, and you get a ribbon too :)

PS. I'm really quite happy with Office 2003. I'm not anti-Microsoft per se. Just when they take advantage of their position to con people.

I'm a little sad too, because I think some small-minded ad-men are directing the company towards losing the marketplace, and I quite like working with MS software over all. We'll have to see what the future teaches us.
Apr 22 '08 #16

mshmyob
Expert 100+
P: 903
Everything M$ does is a big Con. I just wish they would concentrate on making the Operationg System work properly and leave everything else to other companies.

Access has always been touted (sp) to the masses as an easy tool - and you can see the results - no concept of getting the foundation correct (ie: normalization) - just because you can figure out code "does not a database make".

Gotta love that ribbon (lol). I switched because the client wanted it and paid dearly for it ($24,700 for 2 months work - lol).

cheers,

And so it very well should!

The fact that it adds almost nothing and the concentration of effort is to encourage more people to use it by pretending you need to know little or nothing about databases, while at the same time adding very little, irritates me greatly.

In a nutshell, you're being asked to pay extra (buy the upgrade) for them to write code to hoodwink more people into buying the package. It's just a big con that they're getting away with.

Oh, and you get a ribbon too :)
Apr 22 '08 #17

NeoPa
Expert Mod 15k+
P: 31,186
Sounds like you had a good reason :D

BTW I'm home now and I've just checked out the .Printer property here (A2003) and it pops up without any problem... for both forms and reports.

I'm a little surprised that something as fundamental as that was not available before :S Possibly it was just somewhere more complex to access. Who knows (or cares now we're moving past that mostly anyway).
Apr 22 '08 #18

P: 39
Check out the following Microsoft link to get your printer capabilities including your paper bin sizes.

If you have trouble implementing I will create a simplified code for you.

Retrive Printer Capabilities


cheers,
That's exactly what I need. But that code is a little intense for me. I don't want that msgbox in the example but rather a combo box filled with the same, so that my end user can select to his heart desire. Would you simplify? Thanks -Ken.
Apr 24 '08 #19

mshmyob
Expert 100+
P: 903
Hello Ken,

OK I will be away all day today but I will come up with something over the weekend if you can wait.

cheers,

That's exactly what I need. But that code is a little intense for me. I don't want that msgbox in the example but rather a combo box filled with the same, so that my end user can select to his heart desire. Would you simplify? Thanks -Ken.
Apr 25 '08 #20

P: 39
Hello Ken,

OK I will be away all day today but I will come up with something over the weekend if you can wait.

cheers,
That will be great. Thank you very much!!!! -Ken
Apr 25 '08 #21

mshmyob
Expert 100+
P: 903
I have the coding done to populate combo boxes depending on the printer chosen (available bins and paper sizes)

Do you want me to also show you how to set the report to print based on those selections from the combo box or are you confortable with that part?

Let me know and I will send a sample database (just easier to show) than a bunch of code.

cheers,

That will be great. Thank you very much!!!! -Ken
Apr 28 '08 #22

P: 39
I have the coding done to populate combo boxes depending on the printer chosen (available bins and paper sizes)

Do you want me to also show you how to set the report to print based on those selections from the combo box or are you confortable with that part?

Let me know and I will send a sample database (just easier to show) than a bunch of code.

cheers,
Lets go with the (just easier to show) way!!! Thanks -Ken.
Apr 28 '08 #23

mshmyob
Expert 100+
P: 903
Here give this a try. Read the comments under the Print Report button concerning Bins (the select case).

Ask if you have any questions.

cheers,

Lets go with the (just easier to show) way!!! Thanks -Ken.
Attached Files
File Type: zip printer.zip (96.6 KB, 351 views)
Apr 28 '08 #24

P: 39
Here give this a try. Read the comments under the Print Report button concerning Bins (the select case).

Ask if you have any questions.

cheers,
I will study this tonight. It looks exactly like what I need. Thanks in advance -Ken.
Apr 28 '08 #25

P: 39
I will study this tonight. It looks exactly like what I need. Thanks in advance -Ken.
I studied this last night. It is exaclty what I needed. Thank you very much!!!
Last question, in your example, "cmdPrintReport" changes the rpt printer and its setting to whatever you pre-selected, great! Now how would you make those changes permanent to that rptReport so that just a one line docmd.OpenReport rptReport could be issued? Thanks -Ken.
Apr 29 '08 #26

mshmyob
Expert 100+
P: 903
Hello Ken,

Not sure why you would want to do that but do you see the following line in the ON CLICK event of the button to print the form

Expand|Select|Wrap|Line Numbers
  1. DoCmd.Close acReport, "rptProductList", acSaveNo
  2.  
Change it to

Expand|Select|Wrap|Line Numbers
  1. DoCmd.Close acReport, "rptProductList", acSaveYes
  2.  
This will save all your printer settings to that report and you can then have another button that just prints the report with the new printer settings.

Keep in mind if you make any changes to the Print settings using the combo boxes they will override the settings and get resaved. So depending on what you are trying to accomplish you would have to determine where and when you want to execute the acSaveYes switch.

cheers,


I studied this last night. It is exaclty what I needed. Thank you very much!!!
Last question, in your example, "cmdPrintReport" changes the rpt printer and its setting to whatever you pre-selected, great! Now how would you make those changes permanent to that rptReport so that just a one line docmd.OpenReport rptReport could be issued? Thanks -Ken.
Apr 29 '08 #27

P: 39
Hello Ken,

Not sure why you would want to do that but do you see the following line in the ON CLICK event of the button to print the form

Expand|Select|Wrap|Line Numbers
  1. DoCmd.Close acReport, "rptProductList", acSaveNo
  2.  
Change it to

Expand|Select|Wrap|Line Numbers
  1. DoCmd.Close acReport, "rptProductList", acSaveYes
  2.  
This will save all your printer settings to that report and you can then have another button that just prints the report with the new printer settings.

Keep in mind if you make any changes to the Print settings using the combo boxes they will override the settings and get resaved. So depending on what you are trying to accomplish you would have to determine where and when you want to execute the acSaveYes switch.

cheers,
Good morning. I changed acSaveNo to acSaveYes, and added a cmdRePrint that executes a single line of DoCmd.OpenReport. This doesn’t work although it sure looked good. The code still doesn’t SAVE the new report settings. I tried this as an .mdb and .mde
The reason I need this is because I have a customer with 3 printers. One with invoice forms for printing invoices. One with checks for printing checks. And one with plain white paper for everything else. I can manually select a specific printer in design view, but if my next customer doesn’t have the same exact printers, the program will complain. Thanks -Ken.
Apr 30 '08 #28

mshmyob
Expert 100+
P: 903
Ok.

Just a little Access/Report/Printer primer - When you tell access to save the printer settings to a report it is based on the printer that you saved the settings with. If you print the report with a different printer Access will pop up a message. This is why I was curious why you wanted to save the print settings to a report - not good in a multiuser environment or if you need to change printers.

Your original request was for code to allow you to choose a printer and then determine what bins and paper sizes were available. That is working for you as you indicated.

Now you wish to print different reports to different printers and some users have different printers. Therefore saving your settings to the report is not the best idea (as you have noticed and I was wondering why you wanted to do it). You will need to think of a different solution.

I would have to think about the best solution but it would entail either having the user pick one of their printers from the combo box (see code) for the report they want or we can somehow save the settings outside of the report for a user/printer/report scenario.

Let me think about this and get back to you. I have some paperwork I need to finish and get sent out then I will throw something together.

cheers,


Good morning. I changed acSaveNo to acSaveYes, and added a cmdRePrint that executes a single line of DoCmd.OpenReport. This doesn’t work although it sure looked good. The code still doesn’t SAVE the new report settings. I tried this as an .mdb and .mde
The reason I need this is because I have a customer with 3 printers. One with invoice forms for printing invoices. One with checks for printing checks. And one with plain white paper for everything else. I can manually select a specific printer in design view, but if my next customer doesn’t have the same exact printers, the program will complain. Thanks -Ken.
Apr 30 '08 #29

mshmyob
Expert 100+
P: 903
Hello Ken,

I thought about it and can't come up with a simple solution. The problem is that if people have different printers for the same report I can't determine a way to pass that info along. Also bins would be different. The only paramater that could be passed is the paper size for a report. If they all had the same types of printers and bin configuration it could be done easily.

Maybe someone else reading this post can come up with a viable solution. If you don't get a response in the next day or two start a new post.

I think you may have to stick with having the user select a printer and bin. I'll keep an eye on this thread.

cheers,
May 1 '08 #30

NeoPa
Expert Mod 15k+
P: 31,186
Essentially, if you have no logic that you want to follow, there is going to be difficulty in reflecting that in code.

Including checks for which printer (rather than which printer capabilities) are available is fundamentally dodgy to include in code as it is almost certainly not static (It's liable to change).

If this is your situation then the MOST logical approach to take is to allow the operator to select their choice of printer and bin.
May 1 '08 #31

P: 39
Essentially, if you have no logic that you want to follow, there is going to be difficulty in reflecting that in code.

Including checks for which printer (rather than which printer capabilities) are available is fundamentally dodgy to include in code as it is almost certainly not static (It's liable to change).

If this is your situation then the MOST logical approach to take is to allow the operator to select their choice of printer and bin.

Good morning,
I believe that the solution to multiple printers I was designing is a good one. First I built a table(tblPrinterParametersbyTerminal) that stored the specific Printer, PaperSize, and PaperBin requirements for each computer terminal. Then I build a form bound to that table that had 3 combo boxes(cboPrinter/cboPaperSize/cboPaperBin) for each rptReport(Invoices/Checks) that needed a specific printer. Each end user at his terminal would perform a ONE TIME setup of Printer, PaperSize, and PaperBin needs and then cmdSetReport those combo parameters to that rptReport. This same form would also allow the end user to review his printer setting anytime in the future he needed. Then whenever/wherever the program needed to print Invoices/Checks it could just do so with a simple one line of DoCmd.OpenReport because the rptReport(Invoices/Checks) parameters had already been locked in. Every terminal could have different printer requirements, and physical printers could be changed out easily. The only last problem I have is that the acSaveYes is not SAVEing. Thanks -Ken.
May 1 '08 #32

mshmyob
Expert 100+
P: 903
That is a good solution Ken. I did think of that but rejected because of changing printers or bin configs they would have to remember to go and change settings again. But if it works for you then that is fine.

You don't want to save the settings to the Report (acSaveYes) this would mess everyone up since they are using the same report but different print settings.

cheers,


Good morning,
I believe that the solution to multiple printers I was designing is a good one. First I built a table(tblPrinterParametersbyTerminal) that stored the specific Printer, PaperSize, and PaperBin requirements for each computer terminal. Then I build a form bound to that table that had 3 combo boxes(cboPrinter/cboPaperSize/cboPaperBin) for each rptReport(Invoices/Checks) that needed a specific printer. Each end user at his terminal would perform a ONE TIME setup of Printer, PaperSize, and PaperBin needs and then cmdSetReport those combo parameters to that rptReport. This same form would also allow the end user to review his printer setting anytime in the future he needed. Then whenever/wherever the program needed to print Invoices/Checks it could just do so with a simple one line of DoCmd.OpenReport because the rptReport(Invoices/Checks) parameters had already been locked in. Every terminal could have different printer requirements, and physical printers could be changed out easily. The only last problem I have is that the acSaveYes is not SAVEing. Thanks -Ken.
May 1 '08 #33

NeoPa
Expert Mod 15k+
P: 31,186
Essentially, if you have no logic that you want to follow, there is going to be difficulty in reflecting that in code.
...
Clearly this doesn't apply as you DO have good logic to follow here :)

It's a bit tortuous, but this is only because no better facility is provided by Access (Windows really).

I'm sorry I can't direct you towards saving the settings in the report. My best guess would be to get the code to open the report in design view when the operator makes a change and save it from there.

Let us know how you get on with this as it's an interesting issue.
May 1 '08 #34

P: 39
Clearly this doesn't apply as you DO have good logic to follow here :)

It's a bit tortuous, but this is only because no better facility is provided by Access (Windows really).

I'm sorry I can't direct you towards saving the settings in the report. My best guess would be to get the code to open the report in design view when the operator makes a change and save it from there.

Let us know how you get on with this as it's an interesting issue.

Good morning,

I am still beating this dead horse!!! Believe it or not I found another way, much much easier way of doing it, but it has the most stupid limitation.

Step one: DoCmd.OpenReport "rptReport", acViewPreview
Step two: Have end user use FILE -> PAGE SETUP and let microsoft do the work
Step three: DoCmd.Save acReport, "rptReport"
DoCmd.Close acReport, "rptReport"

Reports can have there printer selection, papersize, and paperbins changed this way. This works in .mdb and .mde The only stupid limitation is in .mde, the rptReport can not have a module. Whats the deal with that? Thanks -Ken.
May 3 '08 #35

mshmyob
Expert 100+
P: 903
Depends what code is being run. An MDE stops any modifications to code and modulues. If your module is trying to referene Design mode you may get a problem.

Also try going into your source code and Choosing Debug/Compile and then save your MDB and then create your MDE see if that helps any.

cheers,

Good morning,

I am still beating this dead horse!!! Believe it or not I found another way, much much easier way of doing it, but it has the most stupid limitation.

Step one: DoCmd.OpenReport "rptReport", acViewPreview
Step two: Have end user use FILE -> PAGE SETUP and let microsoft do the work
Step three: DoCmd.Save acReport, "rptReport"
DoCmd.Close acReport, "rptReport"

Reports can have there printer selection, papersize, and paperbins changed this way. This works in .mdb and .mde The only stupid limitation is in .mde, the rptReport can not have a module. Whats the deal with that? Thanks -Ken.
May 4 '08 #36

P: 39
Depends what code is being run. An MDE stops any modifications to code and modulues. If your module is trying to referene Design mode you may get a problem.

Also try going into your source code and Choosing Debug/Compile and then save your MDB and then create your MDE see if that helps any.

cheers,

Good morning,

This is the copy/paste of the module to rptReport. There are no errors with it. The .mdb complies to a .mde The problem is that this report_open prevents the report from being modified thu FILE->PAGE SETUP in .mde, but not .mdb If I remove this Report_Open(NO Module) the rptReport can be modified with FILE->PAGE SETUP within .mde as well as .mdb Let me be more exact, if I remove Report_Open its still doesn't work, I MUST answer NO to module for it to work. Thanks -Ken.
Expand|Select|Wrap|Line Numbers
  1. Private Sub Report_Open(Cancel As Integer)
  2.    Dim strGroup As String
  3.    strGroup = Nz(Me.OpenArgs, "NoDate")
  4.    If strGroup = "NoDate" Then strGroup = modMain.GetDateOnly()
  5.    Me.LabelPrintDate.Caption = strGroup
  6. End Sub
May 4 '08 #37

NeoPa
Expert Mod 15k+
P: 31,186
Ken, I have no experience in this area (MDEs etc) so I'll flag this up in case anyone else can help.

PS. Please remember always to use the [ CODE ] tags provided. I've addded them in for you this time, but they're required when posting code.
May 5 '08 #38

MMcCarthy
Expert Mod 10K+
P: 14,534
Ken have you tried opening the report in design view in the code?
May 5 '08 #39

P: 39
Ken have you tried opening the report in design view in the code?
I tried openning the report in design view within the code as a .mde As expected, Access said "You can't do that!!!" I don't understand this because Access/Windows will stop the program when you try to print to a non-existing specific printer, and then allow you to select another printer EVEN IF the report has a module. Why can't you do it within a program? Thanks for the idea -Ken.
May 5 '08 #40

MMcCarthy
Expert Mod 10K+
P: 14,534
I tried openning the report in design view within the code as a .mde As expected, Access said "You can't do that!!!" I don't understand this because Access/Windows will stop the program when you try to print to a non-existing specific printer, and then allow you to select another printer EVEN IF the report has a module. Why can't you do it within a program? Thanks for the idea -Ken.
I haven't had time to fully examine the question Ken but I'll try to take a look at it later. The basic problem you have is an mde is designed to essentially execute the code and therefore hide and protect it from the user.

I don't know if this will help you out because as I said I haven't fully examined the question but I used this solution by Ken Getz on a problem I had recently printing to pdf and found it very effective. You would probably have to play around with it a bit but it should give you a good direction, and I know it works on an mde.
May 5 '08 #41

Post your reply

Sign in to post your reply or Sign up for a free account.