Do you own a Debenu Quick PDF Library version 7, 8, 9, 10, 11, 12, 13 or iSEDQuickPDF license? Upgrade to Debenu Quick PDF Library 14 today!

Debenu Quick PDF Library - PDF SDK Community Forum Homepage
Forum Home Forum Home > For Users of the Library > I need help - I can help
  New Posts New Posts RSS Feed - RenderPageToString: How to free result memory
  FAQ FAQ  Forum Search   Register Register  Login Login

RenderPageToString: How to free result memory
 Post Reply Post Reply
Author
Message
  Topic Search Topic Search  Topic Options Topic Options
kmsb12 View Drop Down
Beginner
Beginner


Joined: 05 Aug 13
Status: Offline
Points: 4 		Post Options Post Options   Thanks (0) Thanks(0)   Quote kmsb12 Quote  Post ReplyReply Direct Link To This Post Topic: RenderPageToString: How to free result memory
    Posted: 05 Aug 13 at 2:16PM
I am using the RenderPageToString and the DARenderPageToString functions of the Quickpdf library.
Those functions return me a pointer to char (char*) to the rendering results. The memory holding the result data will not be freed until I call RenderPageToString again. The memory will not be cleaned up when I call DACloseFile either.
I found out that I can call DARenderPageToString with an invalid pageRef (0 for instance). The memory from the last rendered page is cleaned up and no new memory will be reserved for the next page rendering.

My question now: Is there any official function for cleaning up memory and invalidating the render results or do I have to live with my workaround?

Thanks a lot.
Kristoff
Back to Top
Ingo View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 29 Oct 05
Status: Offline
Points: 3524 		Post Options Post Options   Thanks (0) Thanks(0)   Quote Ingo Quote  Post ReplyReply Direct Link To This Post Posted: 05 Aug 13 at 6:33PM
Hi Kristoff!

I think you'll need the FREE ;-)
Another hint: Don't mix (never!) DA... and non-DA-functions!
Inside a try...create...finally...free...end you should use DA... or non-DA but never both!
This you can read in the online-references, too ;-)

Cheers and welcome here,
Ingo
Back to Top
AndrewC View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 08 Dec 10
Location: Geelong, Aust
Status: Offline
Points: 841 		Post Options Post Options   Thanks (0) Thanks(0)   Quote AndrewC Quote  Post ReplyReply Direct Link To This Post Posted: 06 Aug 13 at 4:33AM
Kristoff,

DQPL maintains a buffer to return data from the DLL.  As you have correctly determined the memory is not freed again until the next call to the DLL.  You could call something like QP.LibraryVersion which will return a much much smaller buffer effectively freeing the larger buffer from the previous DLL call.

Andrew.
Back to Top
kmsb12 View Drop Down
Beginner
Beginner


Joined: 05 Aug 13
Status: Offline
Points: 4 		Post Options Post Options   Thanks (0) Thanks(0)   Quote kmsb12 Quote  Post ReplyReply Direct Link To This Post Posted: 20 Aug 13 at 4:25PM
Thanks for your answers!
QP.LibraryVersion did not work for me.
I now free the library with delete (I am using the C++ wrapper of the library)
Back to Top
tfrost View Drop Down
Senior Member
Senior Member


Joined: 06 Sep 10
Location: UK
Status: Offline
Points: 437 		Post Options Post Options   Thanks (0) Thanks(0)   Quote tfrost Quote  Post ReplyReply Direct Link To This Post Posted: 21 Aug 13 at 10:51AM
Are you absolutely certain that your main program and the DLL use a common allocator and common memory pools, and always will in future?  Allocating and freeing memory on opposite sides of a DLL boundary is normally a recipe for subtle problems which hit you long after the event, when the pool is next used.
Back to Top
kmsb12 View Drop Down
Beginner
Beginner


Joined: 05 Aug 13
Status: Offline
Points: 4 		Post Options Post Options   Thanks (0) Thanks(0)   Quote kmsb12 Quote  Post ReplyReply Direct Link To This Post Posted: 21 Aug 13 at 3:40PM
Originally posted by tfrost tfrost wrote:

Allocating and freeing memory on opposite sides of a DLL boundary is normally a recipe for subtle problems

To clearify, I do not delete the memory block holding the pixel data directly. I tried that too, but it did not work Wink
Instead I delete the whole library object.

DebenuPDFLibraryDLL0914 *pdfLib = new DebenuPDFLibraryDLL0914(...);
...
// do whatever with pdfLib
...
delete pdfLib;

By doing this, I have to recreate the library object again every time after destroying it. But that's OK. As I use the DA... (direct access) methods, I do not need to reload the whole PDF file as I instantiate the pdf library.
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 11.01
Copyright ©2001-2014 Web Wiz Ltd.

Copyright © 2017 Debenu. Debenu Quick PDF Library is a PDF SDK. All rights reserved. About — Contact — Blog — Support — Online Store