Page 2 of 2

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 2:25 pm
by elvira
Mr. Rao,

Can you please set up by default bInit to be DbGoTop() if DBF is used?.

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 2:33 pm
by nageswaragunupudi
elvira wrote:Mr. Rao,

Can you please set up by default bInit to be DbGoTop() if DBF is used?.


Some programmer may start the report from 100th record and stops at 500th record.

He will complain that report.prg has a bug because export to excel is starting from 1st record.

Report class is very generic and it is highly desirable that the programmer himself sets the Restart point. Its just writing one line of code in the program.

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 2:42 pm
by elvira
And oReport:bInit can be setted globally at the main function?

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 3:12 pm
by nageswaragunupudi
elvira wrote:And oReport:bInit can be setted globally at the main function?

Not possible because it is not a class data. I would even advise it is not desirable.
A project would contain many reports some dealing with dbfs, some arrays, some recordsets, some other kinds of datasources and thinking of one bInit for all is not good.

There will even be many undesirable or even dangerous side effects.

For the sake of dicussion, assume that we made bInit a class var and the programmer set it to :bInit := { || DBGOTOP() }.
Every report will call oRep:Init(), which in turn evaluse bInit ( moving default alias to its top ).

Now let us consider a situation, where a programmer did not yet open any DBF but is reporting an array or recordset. oRep:Init() calls DBGOTOP() and there is not ALIAS active and runtime error occurs,

Consider another situation. 4 DBFs are open. and naturally one of the 4 aliases is default. A report of an array is triggered by the user. Though the report has nothing to do with any of the DBFs running this report will result in bringing the default alias to TOP. The program module dealing with that DBF (can be a browse) does not know that some report in some other module changed the pointer of its DBF. Windows programs basically being non-modal, such situations can easily arise.

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 3:29 pm
by elvira
I see, I was bad myself.

Thank you!!!!!.

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 4:11 pm
by driessen
Mr. Rao,

I tried out your suggestion for debugging by using "MsgInfo".

I got the gpf between MsgInfo("cName") and MsgInfo("cFile").

There is only 1 line in between :
cFile := cFilePath( ::oDevice:aMeta[ 1 ] ) + StrTran( cName, '.', '' ) + ;
Left( HB_TToS( HB_DateTime() ), 14 ) + ".pdf"

Any idea?

Thanks.

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 4:22 pm
by nageswaragunupudi
Please replace that line with
Code: Select all  Expand view
cFile := cFilePath( ::oDevice:aMeta[ 1 ] ) + StrTran( cName, '.', '' ) + ;
DTOS( Date() ) + StrTran( Time(), ':', '' ) + ".pdf"
 

and try please

Re: New FWH 13.07 revised build

PostPosted: Fri Aug 23, 2013 5:54 pm
by driessen
Mr. Rao,

I made the change you suggested.

I still go a gpf but now between MsgInfo("cFile") and MsgInfo(cFile).

What now?

Re: New FWH 13.07 revised build

PostPosted: Sat Aug 24, 2013 3:22 am
by nageswaragunupudi
Between these two msginfo()s the effective code is
FWSavePreviewToPDF( Self, cFile, .f. )

If we press the PDF button ( between SaveAs button and Email button ) also the same function FWSavePreviewToPDF( Self ) is executed.
First please click this button and see if PDF File is created and displayed properly.
If this works correctly, then we shall lookin into other reasons.

Re: New FWH 13.07 revised build

PostPosted: Sat Aug 24, 2013 1:27 pm
by driessen
Mr. Rao,

I did some more test at your advice.

I try to save the report as a PDF, but I also got the gpf in that occasion.

I rebuild my application with FWH 13.06 and tried to save my report as a PDF-file. No problem, everything is running fine.

But I noticed something :

In FWH 13.07, a PDF-file is saved and is named after the name of the report. But if I want to open this PDF-file, I got the message that the file is corrupt. Its size is more than 1.5 MB only for 1 page.

In FWH 13.06, a PDF-file is also saved but I have to name it manually. I can open the PDF without any problem. Its size is only approx. 50 KB for one page.

I just wanted to share this with you.

Thanks a lot for all your efforts to help me.
And sorry if my English is not always as it should be.

Re: New FWH 13.07 revised build

PostPosted: Sat Aug 24, 2013 2:12 pm
by nageswaragunupudi
Thanks for the feedback and for your efforts in testing. I shall get back to you on all the issues a bit later.

I have a feeling that the cFile may be containing blanks.

Please substitute this code in SendEmail() method. Also retain all the traces.
Code: Select all  Expand view
cFile := cFilePath( ::oDevice:aMeta[ 1 ] ) + StrTran( StrTran( cName, '.', '' ), " ", "" ) + ;
DTOS( Date() ) + StrTran( Time(), ':', '' ) + ".pdf"
 


and try running SendEmail option.
Note: I am removing any blanks in the file name.

Re: New FWH 13.07 revised build

PostPosted: Sat Aug 24, 2013 3:50 pm
by nageswaragunupudi
About Size of PDF:

Even in 13.07, if you select SaveAsPDF option in the drop down menu under the SaveAs button, you still get PDF with compact size. This option uses MSWord's functionality to save as PDF if MSWord 2007 with pdf plug-in is installed.

Re: New FWH 13.07 revised build

PostPosted: Mon Aug 26, 2013 3:57 pm
by driessen
Mr. Rao,

I substituted the code you send me (cfile = ...) into my preview class, but I still got the gpf at the same place.

I also put "cfile" in a MsgInfo and there are no spaces in the name.

Re: New FWH 13.07 revised build

PostPosted: Mon Aug 26, 2013 8:36 pm
by nageswaragunupudi
Thanks for your patience.

Please confirm my understanding of the issue.

1. Saving to PDF through MS Word is working well ( 2nd option in the dropdown menu of SaveAs Button on the Bar).
Yes/No ?

2. Saving to PDF by pressing the PDF button directly on the Bar: This uses the built-in FW function. Is this working ( though file size is large ) or not?
working / not working.

3. Send to email is failing with GPF at the SavetoPDF stage in the function. This uses the built in fw function.
Yes/No.

I am aware of one issue with the built-in function that it tries to grap large chunks of memory with _xgrab() and this occasionally, though rarely, fails with run-time error.

While this is working with Harbour or xHarbour problem seems to be with xHb. We need time to locate the issue with xHb. We shall get back soon. Meanwhile please confirm 1,2 and 3 above.