pdf generation takes time

[Paul Mulroney]

Hi Nick

We had the same challenge - we didn't really want to re-write our print routines to handle the asynchronous nature of the Omnis PDF device.  So, we created a window that has an enter data and a timer object.  The code goes something like this when the window opens.

start timer object
enter data until ibComplete
close window

... and the timer object then fires every 1 second to check the $pdfcomplete status. When the PDF is finished, ibComplete is set to true, enter data terminates, and code executions resumes.

this doesn't lock Omnis in a tight loop, and lets you use the new functionality available to you.

Regards
Paul.



> On 5 May 2025, at 7:38 pm, Nick Renders <omnis1 at arcict.com> wrote:
> 
> Hi Paul,
> 
> I know, worker objects are the way to go. But sometimes you just want a "quick and dirty" solution without having to re-write the whole printing procedure (especially when it's 30 year old Omnis 7 code ;)
> 
> Nick
> 
> 
> On 5 May 2025, at 10:38, Paul Mulroney wrote:
> 
>> Hi Nick
>> 
>> $pdfcomplete works in the fat client too!  We used to do something similar to you, but found the CPU usage goes to 100% while Omnis screams around in loop waiting for the report to finish.  Only downside is that you need to handle the $pdfcomplete() as a callback - Omnis will tell you when it's done, so you need your code to stop at that point, and then re-start when the $pdfcomplete() method fires.
>> 
>> Regards
>> Paul.
>> 
>>> On 5 May 2025, at 3:23 pm, Nick Renders via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
>>> 
>>> Hi Geert,
>>> 
>>> In our fat client, we read the PDF file in a loop. If the binary is the same size as before, the printing is done.
>>> 
>>> Calculate i as #CT
>>> Calculate lBinary as #NULL
>>> Repeat
>>> 	Calculate lBinary2 as lBinary
>>> 	If rFileOps.$doesFileExist(lFilePath)
>>> 		Do rFileOps.$readFile(lFilePath,kTrue) Returns lBinary
>>> 	End If
>>> Until #CT>i+600|(binlength(lBinary)>0&binlength(lBinary)=binlength(lBinary2))    ## 10 seconds
>>> 
>>> 
>>> Nick Renders
>>> 
>>> 
>>> On 4 May 2025, at 16:46, Geert wrote:
>>> 
>>>> Hello,
>>>> 
>>>> I'm generating a product sheet from a js form by requesting several data in an object from a REST api (pictures, text, url's, picture for every possible colour up to 20,...)
>>>> Using a report class printing to O$11 PDF device (Windows 11)
>>>> After the  (4MB to 10MB) file is generated (it takes a few seconds) I show the pdf in another tab page in the browser. (or in the future maybe return a REST response or upload the file to an assets library).
>>>> 
>>>> The problem : things go too fast in Omnis Studio.  The pdf file is not yet created or still open when I want to show the pdf.
>>>> This can be monitored when issuing Do $devices.PDF.$setparam(kDevOmnisPDFParamKeepScriptAndPNGs,kTrue)
>>>> 
>>>> The reason : the PDF file is created by Node.js (which is built-in into Omnis).  Omnis generates the .js file plus the PNGs and Node.js executes the .js file to generate the PDF.  So Omnis code continues while node.js is still writing to the pdf file.
>>>> 
>>>> The possible solution : adding a loop to wait a second, use FileOps to test existence and after that use oFileOps to test if not open anymore.  This does not seem to work.  I still get an error message in the browser that the pdf file couldn't show.  Retrying a few times the pdf is shown anyway but that's not user friendly.
>>>> 
>>>> Do you guys have another workaround to know when node.js is really finished ?
>>>> 
>>>> Kind regards,
>>>> Geert
>>>> 
>>>> _____________________________________________________________
>>>> Manage your list subscriptions at https://lists.omnis-dev.com
>>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
>>> _____________________________________________________________
>>> Manage your list subscriptions at https://lists.omnis-dev.com
>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
>> 
>> 
>> I hate it when people use big words just to make themselves sound perspicacious.
>> -- 
>> Paul W. Mulroney                                            We Don't Do Simple Pty Ltd
>> pmulroney at logicaldevelopments.com.au       Trading as Logical Developments
>> www.logicaldevelopments.com.au                   ACN 161 009 374
>> Ph: +61 8 9458 3889                                       86 Coolgardie Street
>>                                                                         BENTLEY  WA  6102


I hate it when people use big words just to make themselves sound perspicacious.
-- 
Paul W. Mulroney                                            We Don't Do Simple Pty Ltd 
pmulroney at logicaldevelopments.com.au       Trading as Logical Developments
www.logicaldevelopments.com.au                   ACN 161 009 374 
Ph: +61 8 9458 3889                                       86 Coolgardie Street
                                                                         BENTLEY  WA  6102