Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Bullzip - Suppressing Screen messages

Status
Not open for further replies.

AndrewMozley

Programmer
Oct 15, 2005
621
GB
An application is producing several .pdf files, and these are being printed using Bullzip. The files are in fact statements of outstanding customer invoices, so one .pdf file is being produced for each customer.

The application works by creating an object :
oBullzip = CREATEOBJECT("BullZip.PDFPrinterSettings")

. . and then sets various options before starting the process of generating the .pdf

This works up to point; the separate .pdf files are being generated and each one is written to its own filename. However, during the creation process, a message flashes up on the screen saying “Printing Page 1”. This happens for each report, so about once every 2 or 3 seconds when a batch of .pdf files is being generated.

I would like to suppress these messages. Have tried setting various options, including :

oBullzip.SetValue("ShowProgress","No")

But, so far, have not been able to suppress the “Printing Page 1” messages.

If anyone has had experience of this, and been able to suppress them, I would be grateful for guidance.

Thanks. Andrew
 
When I was using Bullzip to create customer-specific PDF files and I did not want ANY interactivity between the application and the user I set up my Bullzip in a pre-configured manner.

I used the Bullzip Connfiguration utility (Bullzip's GUI.EXE) to have it Always write the PDF document to the same directory and to a single consistent file name.

Then my VFP application 'knew' where to find the file and what its original file name will be.
By "knowing" that the application could use COPY FILE to copy the PDF file to another directory and rename it to the customer-specific file name along the way - after which it Deleted the original PDF file.

In that way, there was no interactive screens displayed by Bullzip.

Alternatively you could consider using Bullzip as an API. If you do a Search of this forum for: bullzip you will find where this topic and others related to Bullzip have been discussed.

Good Luck,
JRB-Bldr


 
Thank you very much jrb, for coming back on this.

I take your point about avoiding run-time interactions with Bullzip. However, even though I need to produce several different files (statements for different customers), the application does not require any interactivity with Bullzip.

But, as far as I can see, a message always flashes on the screen to say that Bullzip is generating each .pdf file. When only one file is being generated, that is scarcely noticeable, but if there are (say) 50 statements being produced, a fair number of messages flash by. It is these flashing messages that I would like to suppress. It is not the end of the world (!), but I would like the process of generating statements to seem smooth to the user at run-time.

Thanks again. Andrew
 
I don't see a way to avoid the progress or work of such printer drivers to show. The same goes for PDFCreator, even if you configure it to create files without asking. It can work at a certain default directory/filename with a name pattern and a number sequence suffixed to avoid overwriting (actually better than Bullzip always recreating the same file, you don't have to wait for completion and rename before geneerating next pdf).

PDFCreator also displays its logo to signal it works and as progress indicator. Actually if something takes longer it's a good UI/UX rule to show something indicating the program is not idle, but busy.

Bye, Olaf.
 
Thanks Olaf.

You have confirmed that it does not seem to be possible to suppress the messages from Bullzip, so I will cease to worry! I take your point about keeping the user informed about what is going on; in this case I have a label which displays something like

"Generating statement 12 of 104 . . ."

On this matter I see that the above message is not being updated as often as I would like. The whole process is running from the Click() method of a command button. After firing up Bullzip and waiting for completion, this code executes :

Thisform.lblProgress.caption = "Generating statement <12 of 104 . . .>"
.lblProgress.Refresh()

But I notice that the label is only being updated rather infrequently. I have tried including a few extra statements, such as Thisform.refresh(). Any idea what I am doing wrong?

Thanks. Andrew
 
There's nothing wrong witht that, even thisform.refresh() only triggers an eventual refresh, if VFP gets idle. You may use DOEVENTS FORCE. You may use Thirform.cls() which actually means clear screen, but also causes a redraw of all the controls on the form canvas. DOEVENTS FORCE should be the most important part, typically you don't need it, as you typically don't have long running click evnt code and so event processing happens automatic.

Bye, Olaf.
 
Thanks. DOEVENTS FORCE does indeed keep the label which show progress up-to-date.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top