How to know user clicked on which button on print dialog box?

[Former Member]

Hi,

From PowerBuilder application  I am trying to print the pdf.

After my print code ,the print dialog box is showing.

In the dialog box we have Print and cancel button.

How can i know user have click on Print or cancel button?

Print dialog box screen shot.

Thanks,

Rashmi R Giri

[Former Member]

Interpreting your question slightly differently: I assume you are wanting to know from where ever you are calling your dialog box from if the user clicked cancel or not and that your dialog box is in fact a modal/response window.

In your Print command button:

CloseWithReturn ( dw_xyz.print ( true, true ))

where you opened your response window from:

Open ( w_print_r )
if message.DoubleParm = 1 then
     // probably printed
else
     // probably cancelled
end if

[Former Member]

its window print dialog box , not a powerbuilder window

[Former Member]

Hi Rashmi,

Since you are dealing with a pdf document, I think it would help if you could post some code snippet on how you are interacting with the pdf document in your application.

For datawindow print method, one workaround might be to set a boolean instance variable to TRUE in the PrintStart event of the datawindow/datastore that you are printing.

For example:

In a ue_print event of a uo_dw

     ib_printed = FALSE

     This.Print(TRUE,TRUE)

     if ib_printed = TRUE Then //you can assume that the user clicked on Print button

          // some code

     else     //since the dw did not print, you can assume that the user clicked on Cancel button.

          // some code

     end if

In the PrintStart event of the uo_dw

    ib_printed = TRUE

[Former Member]

I am using a Microsoft ole browser to print the PDF.

not a datawindow.

[Former Member]

Hi Rashmi;

  If you use the default DataWindow Print ( /*boolean d*/, /*boolean showprintdlg */ ) method and set the 2nd argument to TRUE, you are invoking the MS-Windows internal Print Dialogue. The only thing you can then monitor from your PB application is whether its still open via the FindWindowW() SDK function. When it closes though, you won;t have any idea s to how that was accomplished.

  For DW printing you can use the DW or DataStore control's PrintStart and PrintEnd events to monitor the printing action. So for example if the FindWindowW( ) SDK call indicates that the MS-Windows print dialogue has closed but the DC/DS's PrintStart event did not fire - then the action taken was a CANCEL. Conversely, if the PrintStart fires after the print system dialogue closes - then the obvious action was PRINT.

  My alternate suggestion is to replace the MS-Windows dialogue with your own like my STD Framework or the PFC framework does. Then being a dialogue that you have control over - you can easily determine the PRINT vs CANCEL action that was taken.

HTH

Regards ... Chris

[Former Member]

I am using microsoft web browser OLE  to display pdf from a location.

Then I have used ole function to print.

is there any way to know , which button user clicked.

[Former Member]

Hi Rashmi;

   AFAIK the IE browser does not expose the results of the print functionality to the OLE container. 

Regards ... Chris

[Former Member]

Hello Chris,

I have placed Microsoft web browser ole in my window.

PB code

ole_1.object.navigate(pdf path , 0 , "","","")

ole_1.object.execwb(6,2,0,0)

3

after above code this print dialog box is opening.

now how can i know,  user clicked on which button (Print , cancel)

Please suggest.

[Former Member]

Hi Rashmi;

1) Unfortunately, the OLE container does not expose the processing option chosen on the Printing dialog as a specific event like the DataWindow does (ie: ButtonClicked event). Due to this limitation, the OLE container can not help you to determine the print action.

2) You might be able to use low level SDK calls like FindWindow ( ) and HitTest ( ) to help locate the if the dialog is being displayed and which CommandButton is pressed. However, this will not be a trivial task to program. Also, the long term maintenance of this tricky code could be an issue in the longer term as well.

Regards ... Chris