Prchoice Problem

[omni]

Roger,

Just looking for a potential solution on this.
We use your prchoice, with some changes, but none related to this.
Example of problem:

User will select a menu option to print a report. Select options, system creates report info, and the prchoice comes up (modal) and gives user his options.

User selects option (for example preview with acrobat). Whether we give a please wait or not, the prchoice window goes away, the original window is in the background, and in a few seconds the prchoice window reappears and the user also has his acrobat file. During this time delay the user clicks the ok button again on the original window, which causes an error. (impatient users to this).

We are looking for an easy method to stop this from happening. Rather not have to add 'when' or similar to the ok/cancel button while the prchoice is up, only because it could be 500 programs..Anything we can add to stop them from clicking or seeing (hide?) the original window (other than adding when/logic to 500 programs).
It does not happen a lot, but a few times a week. We ignore the errors.

Thanks

Fred
Omni

[rdonnay]

I don't understand what you mean when you say the PrChoice window goes away and then reappears.
Do you have it in some kind of loop?

[omni]

Yes, all calling programs have a loop so users can reprint. They may preview, then export to excel, or whatever.

While it is printing is when the user can click the original window and cause the error.

Here is the basic calling code, if you need it. I think you helped us with this many,many years ago (or we just used your examples). The parameters and printjob name may change, but the logic is the same in all programs.

********************************************************************
Static Function PrintReady
do while .t.

IF !Print_Choice( 'A/R AGING REPORT', 2, ' ', .f. )
RETURN nil
ENDIF


do printjobar

enddo

RETURN nil
***************************************************

Fred

[omni]

Roger,

Another note, the calling program has a dialog destory command AFTER the call to the print job. If I move it before the call, then there is no window for the user to see at that point, or click by mistake. Tested and that works, its just a lot of programs to update. That is probably what i will need to do, and have a please wait for ALL options so that they know what it is doing, which it does now for the most part only on our preview.
Is there a wait command for all the other options (excel, pdf, file), or is cancelenable the only way.

[rdonnay]

If you had one routine you call all the time, I could make some suggestions on how to disable the main dialog window in that routine, but it appears that you would need to make 500 changes for your 500 print jobs.

[bwolfsohn]

Fred, Roger,

How about a search and replace

IF !Print_Choice( 'A/R AGING REPORT', 2, ' ', .f. )

to:

IF !Print_Choice_mine( 'A/R AGING REPORT', 2, ' ', .f. )

and then make the one change there, and provide a default value for an additional parameter in those cases where it's needed..

function !Print_Choice_mine( cMode,nSomthing, cComething, lSomething, lNewParameter )

default lNewParamter to old behavior..

return(Brian)

[skiman]

Hi,

This can be done by an include file.

[omni]

Roger,

I am having a programmer move the dialog destroy, which is just a cut/paste, so no big deal.

Another question related to all this. Now that I have enabled the cancelenable the user can cancel the print job. If its a file save, or especially an email with a pdf attachment, we need to stop any further messages or the sending of the email, all part of prchoice.
Is there a system var of some sort that will tell the program the the user clicked cancel in the middle of the print job?

Thanks

Fred

[Koverhage]

Fred,

maybe with oPrinter:lTerminated

If true then the user aborted the print job.

[omni]

That worked. Did not know about that one...

thanks.

Fred
omni