02/15/2014 10:49 Piet Bouma wrote:

Clarion 9 = FRB 3.33 I have something odd: when I run a report and ask for a preview the progressbar starts. The report preview is fine, but after closing the preview the progressbar stays on screen. I cannot do anything with the app, it block every button. If I waut long eanoudg ( say 20- 30 seconds) the progressbar closes and I can go further

02/15/2014 12:30 Oleg Fomin wrote:

Piet, The essential code structure at the end of ProcessData procedure inside FRB library is as follows. SELF.PrintPreview CLOSE(SELF.Report) SELF.AfterClosingReport FREE(SELF.PrintPreviewQueue) DO ProcedureReturn You can see SELF.PrintPreview and SELF.AfterClosingReport virtual methods here. These methods are being implemented in your application. Please open "Source" embeditor of the RunTimeReport procedure and find AfterClosingReport method implementation. Put MESSAGE('AfterClosingReport') after CODE statement of the AfterClosingReport procedure. Compile and run the app. If you will notice that 20-30 seconds pause before 'AfterClosingReport' message, then the problem is in CLOSE(SELF.Report) statement. Otherwise, if the pause will be encountered after 'AfterClosingReport' message, then something wrong is happening inside ProcedureReturn routine. Please, let me know the result. BTW, Open/Close REPORT structure is very much dependant on default printer driver. So, you can change default(current) printer just for test. Also, you can watch into your TEMP folder to see when temporary files (WMF pages) will be deleted by CLOSE(SELF.Report) statement. Thank you, --- Oleg Fomin <oleg@fomin.info>

02/20/2014 16:20 Piet Bouma wrote:

(Oleg knows this already....) The program does not 'hang' but after closing the preview the progressbar stays on screen. I cannot do anything with the app, it block every button. If I wait long enough ( say 20- 30 seconds) the progressbar closes and I can go further. Am I the only one with this ? I have the same program in C6 and there is does not happen.

08/15/2014 14:45 Mark Lancaster wrote:

I've got exactly the same is using 3.33 and C9. Was this fixed in 3.34?

08/15/2014 16:46 Oleg Fomin wrote:

Mark, As you can see from the my previous post in this thread, this is a CLOSE(SELF.Report) delay. This is more Clarion run-time library code rather tnan my own code. Actually, I have no idea how to reproduce this behaviour on my computeer and how to fix it. As for FRB version 3.34, it supports Clarion 9.1, and there are good chances that this problem has already gone because Clarion run-time library has changed considerably. You have valid FRB subscription and version 3.34 is available for you. If this problem is persistent on your computer, could you please test the same application with FRB v.3.34 and Clarion 9.1 Gold? Thank you, --- Oleg Fomin <oleg@fomin.info>

08/18/2014 12:14 Mark Lancaster wrote:

Oleg, Thanks for the reply - I've got an issue getting up to C9.1 at the moment due to awaiting updates to other 3rd Party Templates. I have a work-around though. The problem only occurs on the first report ran in a session and the duration of the delay is based upon the number of pages. If the first report is a one-page report then this will come back quickly and everything should be fine after that. My work around was to create a standard Clarion report that would only produce one page (being Clarion I could ensure that the report existed). Note: it has to hook onto something that will produce something with data. I call report as soon as the application starts (from the "After Open Files" within the Main procedure). Within the code for the report - I omitted the standard print preview calls to force a GlobalResponse of RequestCancelled ... omit('***My Skip Preview') ! End of "Before Print Preview" IF NOT SkipPreview THEN ReportPreview(PrintPreviewQueue) ELSE GlobalResponse = RequestCompleted END ! Start of "After Print Preview" ! [Priority 5000] !***My Skip Preview GlobalResponse=RequestCancelled This means the one page report runs and then disappears without doing anything, but it seems to sort the runtime in C9 so that further reports runs as expected. A couple of things to note ... The delay doesn't seem anywhere near as bad from a Clarion Report as it does from a Fomin Report. I've no idea why, but this may be why there hasn't been a lot of mention of it within the general Clarion Community. I use the IceTips print-previewer. I know that creates additional wmf files, but everything seems to be tidied up very quickly. I've a very large multi-DLL application. My application is in legacy code not ABC. All of these may contribute to why it's not been generally reported. Thanks, Mark

08/18/2014 16:45 Oleg Fomin wrote:

Mark, Thank you very much for sharing your experience. When you'll be able to upgrade to 9.1, then please let me know whether this issue is relevant to the latest Clarion run-time or not. Best regards, --- Oleg Fomin <oleg@fomin.info>

02/12/2015 10:19 Bjarne Havnen wrote:

I experienced similar things today, but only when I ran report from Reportmanager, any report lead to hang or crash. However, a hit on ESC solved it. I am still on 3.23 and Clarion 8.9304

05/06/2015 15:23 Oleg Fomin wrote:

Finally, this issue has been fixed with FRB v.3.36 (just released). Thanks to Jeroen Rigterink for the application clearly demonstrating the problem.

05/06/2015 16:53 Jeroen wrote:

I have updated to 3.36 and works now. Thanks Oleg.

05/08/2015 16:26 Jeroen wrote:

Hi Oleg, I noticed something strange in 3.36 version. When I move a frame, I don't see the white lines/indicators anymore on horizontal and vertical rulers. I also tried FRB demo with 3.36 version. Same problem there.