• WSrrdavis

    WSrrdavis

    @wsrrdavis

    Viewing 15 replies - 76 through 90 (of 160 total)
    Author
    Replies
    • in reply to: PDF995 (Access 2002) #800565

      I have made some slow progress with this problem. I no longer get the Save As dialog box, but I’m getting some pretty weird behavior.

      If I bypass the Save As dialog box, I will get a pdf file saved as the name I intended, but the data will be wrong. Usually it is the data from the most previous running of the report. (I can specify which client to report on at runtime). It is like there is a old temp file somewhere that is being read into the “new” file–or something. The really strange this is that if I change the report page setup dialog box and specify an actual physical printer (and that is the only change I make), the report run fine and returns the expected data.

      Another strange behavior: Set the PDF writer to show the SaveAs dialog box in order to type in my own filename. As the dialog box is on the screen, I can see the report running in the status bar in the background. I have yet to be able to get a PDF file saved to disk using the Save As dialog box. Entering a filename and clicking OK makes the dialog box go away and the report continues to run, but a file is not saved. If I do nothing with the dialog box, it disappears on its own once the report is nearing the end of its run. Again, no file is saved to disk.

      So I set a breakpoint at the beginning of the report being run just to check to see what is happening when. When I get to the line to actually open the report object, I immediately get the Save As dialog box and the rest of the code continues, instead of line by line like it should. Any thoughts on all this. I am about to give up on PDF995.

    • in reply to: PDF995 (Access 2002) #800566

      I have made some slow progress with this problem. I no longer get the Save As dialog box, but I’m getting some pretty weird behavior.

      If I bypass the Save As dialog box, I will get a pdf file saved as the name I intended, but the data will be wrong. Usually it is the data from the most previous running of the report. (I can specify which client to report on at runtime). It is like there is a old temp file somewhere that is being read into the “new” file–or something. The really strange this is that if I change the report page setup dialog box and specify an actual physical printer (and that is the only change I make), the report run fine and returns the expected data.

      Another strange behavior: Set the PDF writer to show the SaveAs dialog box in order to type in my own filename. As the dialog box is on the screen, I can see the report running in the status bar in the background. I have yet to be able to get a PDF file saved to disk using the Save As dialog box. Entering a filename and clicking OK makes the dialog box go away and the report continues to run, but a file is not saved. If I do nothing with the dialog box, it disappears on its own once the report is nearing the end of its run. Again, no file is saved to disk.

      So I set a breakpoint at the beginning of the report being run just to check to see what is happening when. When I get to the line to actually open the report object, I immediately get the Save As dialog box and the rest of the code continues, instead of line by line like it should. Any thoughts on all this. I am about to give up on PDF995.

    • in reply to: PDF995 (Access 2002) #800000

      I am needing to control the name of the PDF file and where it will be saved to, based upon some variables that are not set until runtime. My boss wants to bypass the Save As dialog box. Therefore, I need to programatically pass the filename and the path to PDF995. As far as I know, the INI file is the only way to do this. If you have any other ideas, I would be grateful.

      Randy

    • in reply to: PDF995 (Access 2002) #800001

      I am needing to control the name of the PDF file and where it will be saved to, based upon some variables that are not set until runtime. My boss wants to bypass the Save As dialog box. Therefore, I need to programatically pass the filename and the path to PDF995. As far as I know, the INI file is the only way to do this. If you have any other ideas, I would be grateful.

      Randy

    • Hans, you’re a lifesaver. I’ll try this first thing in the morning. As I’ve said in the past, I need to start paying you by the hour. Thanks for all your help.

    • Hans, you’re a lifesaver. I’ll try this first thing in the morning. As I’ve said in the past, I need to start paying you by the hour. Thanks for all your help.

    • in reply to: Print Report Behavior (Access 2002) #789409

      Thanks, Patricia, Hans and Charlotte, for your input.

      I was aware of the reason Access recalculates before printing and agree with it, but some reports, like mine, have no need for that since I am reporting from data that has already been summarized and won’t be changing. I was just hoping there was a setting that could be changed.

      Hans and Charlotte (along with a few others), you are the best. You’ve help me out many times in the Lounge. I know your hard work is appreciated by many.

    • in reply to: Print Report Behavior (Access 2002) #789410

      Thanks, Patricia, Hans and Charlotte, for your input.

      I was aware of the reason Access recalculates before printing and agree with it, but some reports, like mine, have no need for that since I am reporting from data that has already been summarized and won’t be changing. I was just hoping there was a setting that could be changed.

      Hans and Charlotte (along with a few others), you are the best. You’ve help me out many times in the Lounge. I know your hard work is appreciated by many.

    • in reply to: MSChrt20 Reference (Access 2002 sp1) #782578

      Charlotte–

      Thanks for the information. I’m not using this ActiveX control that I know of, so I just deleted the reference. We’ll see iff there are any problems with it.

    • in reply to: MSChrt20 Reference (Access 2002 sp1) #782579

      Charlotte–

      Thanks for the information. I’m not using this ActiveX control that I know of, so I just deleted the reference. We’ll see iff there are any problems with it.

    • in reply to: subform linking (Access 2002) #781573

      Charlotte, thanks for your assistance.

      In complying with your request I stumbled upon a partial workaround to the problem I was having. I am posting the stripped-down database as you requested. Run the frmReport form and you get the simplified version of the form I was having problems with. It works, now: change the dropdown value and the values in the subform change like I wanted them to. The values in the datasheet will later be used in another query to process the report. I realize they don’t need to be visible in order to use them later, but I want my end users to see what values are going to be used in the report. However, like you said, datasheets pose their own problems.

      The embedded object isn’t really a form, but rather just a query’s datasheet. This will work to view the values, except that I cannot make changes to the values in the datasheet directly. I thought this was only a small nuisance since I could create and open another form to make changes to the values listed. To this end, open qryReportItems subform. I thought you could update data in a table through a form based on a query. brickwall

      Just to be complete: frmReport will have textboxes for dates to limit the report and a command button to run the report, which will trigger a whole series of queries.

    • in reply to: subform linking (Access 2002) #781574

      Charlotte, thanks for your assistance.

      In complying with your request I stumbled upon a partial workaround to the problem I was having. I am posting the stripped-down database as you requested. Run the frmReport form and you get the simplified version of the form I was having problems with. It works, now: change the dropdown value and the values in the subform change like I wanted them to. The values in the datasheet will later be used in another query to process the report. I realize they don’t need to be visible in order to use them later, but I want my end users to see what values are going to be used in the report. However, like you said, datasheets pose their own problems.

      The embedded object isn’t really a form, but rather just a query’s datasheet. This will work to view the values, except that I cannot make changes to the values in the datasheet directly. I thought this was only a small nuisance since I could create and open another form to make changes to the values listed. To this end, open qryReportItems subform. I thought you could update data in a table through a form based on a query. brickwall

      Just to be complete: frmReport will have textboxes for dates to limit the report and a command button to run the report, which will trigger a whole series of queries.

    • in reply to: subform linking (Access 2002) #780133

      Thanks for your help, Charlotte.

      A continuous form is probably a better way to go.

      As to my parent form, I really have no other data on that form than what is present in the combo box. It is a form used to run a report. There are two other text boxes in the parent form used to limit the date range for the report. The combo box selects which report is to be run. The sub form lists the different groups and subgroups that will be included in that report. Other than that, no data actually appears in the forms.

      I’m sure that there is probably a better way to approach this, but this is the way I came up with. Does anyone else have a different idea?? Charlotte, this is why I like getting direction from you and others here because you have so much more experience as this than I do. I haven’t done this enough to know that continous forms behave better than datasheets do.

    • in reply to: subform linking (Access 2002) #780134

      Thanks for your help, Charlotte.

      A continuous form is probably a better way to go.

      As to my parent form, I really have no other data on that form than what is present in the combo box. It is a form used to run a report. There are two other text boxes in the parent form used to limit the date range for the report. The combo box selects which report is to be run. The sub form lists the different groups and subgroups that will be included in that report. Other than that, no data actually appears in the forms.

      I’m sure that there is probably a better way to approach this, but this is the way I came up with. Does anyone else have a different idea?? Charlotte, this is why I like getting direction from you and others here because you have so much more experience as this than I do. I haven’t done this enough to know that continous forms behave better than datasheets do.

    • in reply to: subform linking (Access 2002) #780072

      Yes, you are correct. it is a one-to-many relationship.

    Viewing 15 replies - 76 through 90 (of 160 total)