Page 2 of 3

Re: Crash from FWSavePreviewToPDF UPDATED!

PostPosted: Fri Jul 08, 2011 2:47 pm
by byte-one
Antonio, the computer (laptop) with the problems in the moment is not reachable! Is it possible, that the computer has to low memory? He has only 1 Gb.

Or the problem comes from cTempfile() ????
Without a path-parameter .\ is default and in this path no rights existing in win7 in circumstances. This temp-file should be in temp-directory as default. I have also problems with timage:saveimage(). In this method cTempfile() is calling.

A possible code:

Code: Select all  Expand view
function temp_path()
local cPath := ".\"
do case
    case !empty(getenv("
TEMP"))
        cPath := getenv("
TEMP")+"\"
    case !empty(getenv("
TMP"))
        cPath := getenv("
TMP")+"\"
    endcase
return cPath

Re: Crash from FWSavePreviewToPDF

PostPosted: Fri Jul 08, 2011 5:34 pm
by TimStone
I just created a build with 11.06 and tried the tPreview class. ( I usually use my own which supports PDF and email, plus has larger icons ).

I can get a preview, but when using the Word or PDF options, the program gets a Windows error ( the .exe has stopped ). I am logged in as the Administrator, and I tried Run as Administrator also. I get the same results.

Win 7 Ultimate 32
FWH 11.6
xBuilder compiler ( xcc )

I used the download from this morning ( built 7/7 at 9:30 PM )

Tim

Re: Crash from FWSavePreviewToPDF

PostPosted: Fri Jul 08, 2011 5:38 pm
by TimStone
I should add that all of my reports are manually constructed with the PRINTER commands:

PRINT oPrn NAME "Daily Totals" PREVIEW

Re: Crash from FWSavePreviewToPDF

PostPosted: Fri Jul 08, 2011 6:34 pm
by Antonio Linares
Tim,

Have you tested the small example provided by Rao ?

Please test it, thanks :-)

Re: Crash from FWSavePreviewToPDF

PostPosted: Sat Jul 09, 2011 3:48 am
by nageswaragunupudi
Mr. Antonio

Please see Mr. Tim's posting:
I can get a preview, but when using the Word or PDF options, the program gets a Windows error ( the .exe has stopped ).


You are aware that this happens with xHarbour commercial (also with some specific versions of xHarbour), while executing GetActiveObject() function in "olefuncs.prg". This was reported by some users and solution provided in these forums as well as personally by email by you.

Please see the header of \fwh\source\function\olefuncs.prg:
Code: Select all  Expand view
#include "fivewin.ch"

// xHarbour Commerical users may uncomment the next line
// #define ___XHB___
 

If olefuncs.prg is compiled uncommenting this define and linked, it works well.
Can you consider releasing FiveHCM.lib and FiveHMX.lib with this change?

Re: Crash from FWSavePreviewToPDF

PostPosted: Sat Jul 09, 2011 4:15 am
by nageswaragunupudi
Or the problem comes from cTempfile() ????

SaveToPDF function saves any temporary files to the folder where the meta files were already created by TPreview. If we are able to see preview, it means the meta files were already created successfully in some temporary folder and creating other temporary files in the same folder should not result in any problems.

Nonetheless, the problems that might arise due to the present use of cTempFile() need to be looked into.

Re: Crash from FWSavePreviewToPDF

PostPosted: Sat Jul 09, 2011 10:39 am
by Antonio Linares
Rao,

If olefuncs.prg is compiled uncommenting this define and linked, it works well.
Can you consider releasing FiveHCM.lib and FiveHMX.lib with this change?


We need to find a way to distinguish between xHarbour and xHarbour commercial based on a compiler define

Does exist such define ?

Re: Crash from FWSavePreviewToPDF

PostPosted: Sat Jul 09, 2011 5:49 pm
by Antonio Linares
It seems as we could use:

#ifdef __XCC__ // Just exist for xHarbour commercial
#define ___XHB___
#endif

but it seems as Rao has already solved it without the need for this define :-)

Re: Crash from FWSavePreviewToPDF

PostPosted: Sat Jul 09, 2011 5:57 pm
by Antonio Linares
For those using xHarbour commercial, please try this lib and try again the preview example:

http://fivewin.googlecode.com/files/Fivehcm.lib

Re: Crash from FWSavePreviewToPDF

PostPosted: Sun Jul 10, 2011 10:46 pm
by byte-one
Now I have do other tests and I found, that the error only come with greater previews with some pages! One or two pages are functioning best. Some memory-request are not released from page to page??
Its very important to correct the ctempfile() and all other paths in the exe-directory (c:\program files, etc.) as soon as possible. In WIN7 there are no rights to write in this directory as default! This problem are also with ther "error.log". The standard should be also the temp-directory.

Re: Crash from FWSavePreviewToPDF

PostPosted: Mon Jul 11, 2011 2:09 pm
by gkuhnert
Just tested a print preview with 1621 pages to save it with the button in the preview and it was no problem (it took about 2 minutes). However, my system is a Win7 with 8GB memory.

Re: Crash from FWSavePreviewToPDF

PostPosted: Mon Jul 11, 2011 3:26 pm
by Gale FORd
I had this problem also. Uncommented #define ___XHB___ in olefuncs.prg and it works.

Also what icon does the preview use for word and pdf option? My preview just has an empty spot on the toolbar.

Re: Crash from FWSavePreviewToPDF

PostPosted: Mon Jul 11, 2011 4:34 pm
by nageswaragunupudi
Gale FORd wrote:I had this problem also. Uncommented #define ___XHB___ in olefuncs.prg and it works.

Also what icon does the preview use for word and pdf option? My preview just has an empty spot on the toolbar.

You can also use the revised fivehcM.lib. Please download from the link posted by Mr. Antonio in the post above. http://fivewin.googlecode.com/files/Fivehcm.lib

If you do not see any buttons, it means you are using an older version of prev32.dll. Please copy the latest prev32.dll from \fwh\dll folder to your working folder.

Re: Crash from FWSavePreviewToPDF

PostPosted: Mon Jul 11, 2011 4:45 pm
by Gale FORd
I tried that file but it did not solve the problem. I am now being very careful that the files i am downloading or saving actually overwrite the previous file.

Re: Crash from FWSavePreviewToPDF

PostPosted: Tue Jul 12, 2011 1:52 am
by hua
I wish changes that affects UI such as this is disabled by default. That way, whatever changes need to be dealt with can be done at a later time without having to postpone linking in latest FWH to resolve whatever bugs that might exist.