locked
Print options when opening report in acDialog RRS feed

  • Question

  • I have a report where, on the close event, I ask the user if they want to post the records. The user's response is captured to a public variable that is then used to branch logic back on the form from which I open the report.

    Consequently, I think I need to open in acDialog so that the code on the form after the OpenReport line does not continue on to the branched logic until the report is closed and the above response is available.

    However, in dialog view, I do not have access to the standard report ribbon--which is how I intended to allow the user to print/export. Yes, I know I can have the user press Ctrl-P, but that is an extra step an end user should not have to know. And yes, I know I can use right-click options.

    So my question is twofold. #2 will not be necessary if there is an elegant workaround for #1.

    1. Is acDialog the best (or only) way to accomplish the wait-for-response in my code on the form?
    2. How would I get print & export buttons (or the whole default Reports ribbon) available when the report is open acDialog?
    Wednesday, April 1, 2015 3:29 PM

Answers

  • Hi Brian, 

    With regard to #1, you can put the following code in after your OpenReport on your form:

        Do While SysCmd(acSysCmdGetObjectState, acReport, "MyReportName") <> 0
            DoEvents
        Loop

    This would prevent execution of any code following your OpenReport until the report is closed.

    Another alternative might be to prompt the user for output (printer or export) prior to opening the report in dialog view.

    -Bruce

    • Marked as answer by Brian D. Hart Saturday, April 4, 2015 8:27 PM
    Wednesday, April 1, 2015 7:38 PM

All replies

  • Why not just leave the report open on the screen and then open the form. If the user wants to "post records", close the form. If they don't, close both the report and the form. That way, you will have access to the normal print ribbon if they want to "Post".

    Wednesday, April 1, 2015 5:52 PM
  • Hi Brian, 

    With regard to #1, you can put the following code in after your OpenReport on your form:

        Do While SysCmd(acSysCmdGetObjectState, acReport, "MyReportName") <> 0
            DoEvents
        Loop

    This would prevent execution of any code following your OpenReport until the report is closed.

    Another alternative might be to prompt the user for output (printer or export) prior to opening the report in dialog view.

    -Bruce

    • Marked as answer by Brian D. Hart Saturday, April 4, 2015 8:27 PM
    Wednesday, April 1, 2015 7:38 PM
  •     

    Take the code following the line calling the OpenReport method out of the calling procedure and put it in a public procedure in the form's module, e.g.

    Public Sub PostData()

        ' your code goes here

    End Sub

    This exposes the procedure as a method of the class, so you can call it in the report's Close event procedure with:

        Form_YourFormNameGoesHere.PostData

    The report then does not need to be opened in dialogue mode.

    PS: the form must not be closed before the procedure is called of course, but it can be hidden.


    Ken Sheridan, Stafford, England


    • Edited by Ken Sheridan Wednesday, April 1, 2015 9:35 PM Postscript added.
    Wednesday, April 1, 2015 9:33 PM
  • Lawrence,

    The form is where I concatenate the SQL that is the record source of both the report and the subsequent record updates. So the form is always open before the report is opened (that is where the code to open the report resides and is run), and it must remain open while the report is open to maintain the value of the variables, including the WHERE clause of the SQL statement that will be used for the posting process when the user closes the report. That is, the SQL used to open the report MUST match the SQL used when posting the records, or the user could change some selection parameter and post records not on the report.

    And I open both the form and report modally to prevent a user from inadvertently running the report's Close event outside the context of the form, with its variables all set for the posting process.

    I know I could pass all of this to public variables, but I am trying to keep it as clean and as close to the Form -> Report -> back to Form as I can.

    Thursday, April 2, 2015 8:25 AM
  • Bruce,

    I will try DoEvents in conjunction with monitoring the report's object state. In fact, that is kind of what I think I was looking for--as long as I do not discover some unpleasant downside to it.

    I do not want to prompt the user for output prior to opening the report, since users may not know if they want to print or just preview before they open the report.

    In short, this is a pretty normal accounting-style posting process: bring up the report of what will happen, but do nothing unless/until the user confirms. This allows the user to view/print/export the report, then go back and review the data in the report without being forced to post the data immediately. It is easy enough for the user to get to the posting process by going back through the preview when any anomalies in the data have been corrected and the user is truly ready to post.

    Thursday, April 2, 2015 8:30 AM
  • Ken,

    I may try putting the posting code inside a separate procedure; however, it will require some modifications to my code--principally, making some variables available outside the context of the procedure that opens the form so that they remain available to a different procedure. The form does remain open behind the report when the user runs the report anyway. Both are modal in order to prevent any end-run around my intentions for clean data processing.

    Thursday, April 2, 2015 8:34 AM
  • Thank you, Bruce.

    DoEvents was the ticket.

    Saturday, April 4, 2015 8:28 PM