PDF error pops up again

[TimStone]

This problem arose last September, and Antonio "fixed" it in the c code.
Now I am encountering it at one of my clients locations.

Using the rpreview program, we are sending a PDF attached to an email. If the PDF document is 1 page long, it goes out fine. In fact, I can send it out multiple times ( 6 in a row ) from the same View of a document, and there is no problem.

Now, I have a document that is 4 pages long ( 3 MB ). The first time, it goes out fine. However, if I try to send it out to another addressee, I get that famous hb_xgrab can't allocate memory message.

This is happening on the client's XP machine(s). There is about 360 MB of available RAM. On my Windows 8.1 computer I cannot make it happen though I might repeat the process multiple times.

Your thoughts will be GREATLY APPRECIATED.

Tim

[Antonio Linares]

Tim,

Please call LogFile( ..., GlobalMemorySEx() ) as I do in this example, before eveytime your app is about to do the process that finally runs out of memory:

It is just a C wrapper to Windows API GlobalMemoryStatusEx():
http://msdn.microsoft.com/en-us/library/aa366589(v=vs.85).aspx

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   LogFile( "memuse.log", "used% TotalPhys(bytes) AvailPhys    TotalPageFile  AvailPageFile" + ;
                          "   TotalVirtual    AvailVirtual" )
   LogFile( "memuse.log", GlobalMemoryStatusEx() )
   MsgInfo( "testing memory consume" )
   LogFile( "memuse.log", GlobalMemoryStatusEx() )
   
   WinExec( "notepad memuse.log" )

return nil

#pragma BEGINDUMP

#include <hbapi.h>
#include <windows.h>

HB_FUNC( GLOBALMEMORYSTATUSEX) // --> aMemoryStatus
    {
       MEMORYSTATUSEX mst;

       memset( &mst, 0, sizeof( MEMORYSTATUSEX ) );
       mst.dwLength = sizeof( MEMORYSTATUSEX );

       GlobalMemoryStatusEx( &mst );

       hb_reta( 7 );

       hb_storvnl( mst.dwMemoryLoad, -1, 1 );
       hb_storvnl( mst.ullTotalPhys, -1, 2 );
       hb_storvnl( mst.ullAvailPhys, -1, 3 );
       hb_storvnl( mst.ullTotalPageFile, -1, 4 );
       hb_storvnl( mst.ullAvailPageFile, -1, 5 );
       hb_storvnl( mst.ullTotalVirtual, -1, 6 );
       hb_storvnl( mst.ullAvailVirtual, -1, 7 );
  }

#pragma BEGINDUMP

[Antonio Linares]

Tim,

Besides the above checking, we have only changed this in source/function/prv2pdf.prg:

// CloseEnhMetafile( hEMF ) // commented out 2014-02-13
DeleteEnhMetafile( hEMF ) // inserted 2014-02-13

and this code in source/classes/printer.prg:

Code: Select all  Expand view

       elseif "pdf" $ Lower( oPrinter:cFile )
          FWSavePreviewToPDF( oPrinter, If( Lower( cFileExt( oPrinter:cFile ) ) == "pdf", ;
                oPrinter:cFile, nil ), oPrinter:lPreview )
          oPrinter:End()   // it was added
       endif
    else
       oPrinter:End()
 

You could revert those changes and see if that makes a difference.

[TimStone]

Testing

[Antonio Linares]

(xHb.com issues again...)

Please try with GlobalMemoryStatus() only:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366772(v=vs.85).aspx

Please change the code to use GlobalMemoryStatus() instead of GlobalMemoryStatusEx() (as clearly xhb.com has not included the required library to use it):

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   LogFile( "memuse.log", "used% TotalPhys(bytes) AvailPhys    TotalPageFile  AvailPageFile" + ;
                          "   TotalVirtual    AvailVirtual" )
   LogFile( "memuse.log", GlobalMemoryStatusEx() )
   MsgInfo( "testing memory consume" )
   LogFile( "memuse.log", GlobalMemoryStatusEx() )
   
   WinExec( "notepad memuse.log" )

return nil

#pragma BEGINDUMP

#include <hbapi.h>
#include <windows.h>

HB_FUNC( GLOBALMEMORYSTATUS ) // --> aMemoryStatus
    {
       MEMORYSTATUS mst;

       memset( &mst, 0, sizeof( MEMORYSTATUS ) );
       mst.dwLength = sizeof( MEMORYSTATUS );

       GlobalMemoryStatus( &mst );

       hb_reta( 7 );

       hb_stornl( mst.dwMemoryLoad, -1, 1 );
       hb_stornl( mst.dwTotalPhys, -1, 2 );
       hb_stornl( mst.dwAvailPhys, -1, 3 );
       hb_stornl( mst.dwTotalPageFile, -1, 4 );
       hb_stornl( mst.dwAvailPageFile, -1, 5 );
       hb_stornl( mst.dwTotalVirtual, -1, 6 );
       hb_stornl( mst.dwAvailVirtual, -1, 7 );
  }

#pragma BEGINDUMP

[TimStone]

Seems to be a problem with logging.

I only get the following in the file:

06/12/14 07:26:15: 35

It would appear each submission writes the same line over rather than advancing / appending a line.

Tim

[Antonio Linares]

Tim,

Please post the code to see how you are using it, thanks

[TimStone]

Antonio,

I took your sample but put it into rpreview in the email section. I have my own sendmail, so it is like this:

Code: Select all  Expand view

   LogFile( "memuse.log", "used% TotalPhys(bytes) AvailPhys    TotalPageFile  AvailPageFile" + ;
                          "   TotalVirtual    AvailVirtual" )
   LogFile( "memuse.log", GlobalMemoryStatusEx() )

   ASWMail( cSendto, cDocText )

   LogFile( "memuse.log", GlobalMemoryStatusEx() )
   WinExec( "notepad memuse.log" )
 

It only includes 1 line, ie the last line executed.

Tim

[TimStone]

I have finally isolated this to the specific line(s) of code:

First, the problem ONLY occurs on computers running XP, and it is happening on all computers in that business running XP

The problem is confined to the SendEmail( ) method in rPreview.
The error is hb_xgrab( ) cannot allocate memory.
The error occurs in the following section of code:

Code: Select all  Expand view

 
 CursorWait()
 cFile := ::SaveAs( .t., cFile, .f. )
   CursorArrow()
 

To make it happen, we open a document in View mode. Press the @ icon to send an email. The email completes. Now, press the button again, and the error box will popup. So, something apparently is causing the ::SaveAs( ) to force an error in XP.

All ideas or suggestions would be appreciated. Yes, I did step through each line of the SendEmail( ) code and this is clearly where the error occurs.

Thanks.

[Antonio Linares]

Tim,

Please comment the section where the email is sent and lets see if the error keeps happening:

Code: Select all  Expand view

METHOD SendEmail() CLASS TPreview

   local oMail, cName, cFile

   cName := If( ::oReport != nil, ::oReport:cName, ::oDevice:cDocument )
   cFile := cFilePath( ::oDevice:aMeta[ 1 ] ) + StrTran( cName, '.', '' ) + ;
            Left( HB_TToS( HB_DateTime() ), 14 ) + ".pdf"

   CursorWait()
   cFile := ::SaveAs( .t., cFile, .f. )
   CursorArrow()

   if ! File( cFile )
      MsgInfo( FWString( "PDF not saved to send Email" ), FWString( "Information" ) )
   elseif ::bEmail != nil
      Eval( ::bEmail, Self, cName, cFile )
   else
      /* commented to identify where the problem comes from
      DEFINE MAIL oMail ;
         SUBJECT cName ;
         TEXT "" ;
         FILES cFile, cFile ;
         FROM USER

      ACTIVATE MAIL oMail
      */
      // MsgInfo( oMail:nRetCode )  check the returned code!
   endif

   ::oMeta1:SetFocus()

return nil

[TimStone]

I call my own email routine ... So, I simply use ASWSendMail( ... ) in place of your method. I have to use my own because I have to allow support for SMTP, CDO, and MAPI.
I commented it out, and the error goes away.

The frustration is that it only occurs on XP computers ... and since I can't force it to happen, I can't actively debug it.

So now I go back to my SMTP code to see how it could possibly change the rpreview state ...
I know there are no duplicate variable names ...

[Antonio Linares]

Tim,

Would you mind to post the source code of your ASWSendMail() here so maybe we can help you to find the problem in it ? thanks

[TimStone]

Antonio

The problem is resolved, but not solved. A response on how your PDF system now works in another thread I started led me here.

Previously, I used a library, Image2PDF.dll, to create PDFs for my emails. I stopped using it when you incorporated PDFs into rpreview. I was curious why, on the XP machine, the PDF was 3 MB, but only 215 KB on mine. I hadn't realized that the program used my Word 2013 to create the PDFs.

I made an option in rpreview that allowed me to use the Image2PDF.dll on the client's computer, instead of the FWH one. That solved the problem. Also, the PDFs that it creates are 13 KB, instead of 215 KB, or 3 MB. Yes, the exact same data is used in all 4 cases, and its a 4 page invoice.

Apparently there is something in the PDF creation that is at the root of this problem. However, I have a solution in place for now, so hopefully that will let me focus on other tasks.

Tim

[nageswaragunupudi]

I made an option in rpreview that allowed me to use the Image2PDF.dll on the client's computer, instead of the FWH one. That solved the problem. Also, the PDFs that it creates are 13 KB, instead of 215 KB, or 3 MB. Yes, the exact same data is used in all 4 cases, and its a 4 page invoice.

Please see my posting in the other thread. Image2PDF is the best. Personally I think it is better than even the Word 2003/7/10 option. Best quality with small size.