InProc vs. OutProc COM Server

PDF-XChange Editor SDK for Developers

Moderators: TrackerSupp-Daniel, Tracker Support, Paul - Tracker Supp, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Ivan - Tracker Software, Tracker Supp-Stefan

Forum rules
DO NOT post your license/serial key, or your activation code - these forums, and all posts within, are public and we will be forced to immediately deactivate your license.

When experiencing some errors, use the IAUX_Inst::FormatHRESULT method to see their description and include it in your post along with the error code.
Post Reply
AnMuWK
User
Posts: 30
Joined: Thu Dec 19, 2019 2:20 pm

InProc vs. OutProc COM Server

Post by AnMuWK »

Hi All,

we formely used the PDF Viewer SDK and changed to PDF Editor SDK a couple of month ago. One big difference is, that PDF Viewer SDK was an OutOfProcess COM Server, whereas PDF Editor is InProc.

Is there a supported way to run also the Editor SDK as outofprocess COM server? Is there another download package which we did not realize yet?

Our issue currently is, that (also related to other 3rd Party components we use) we are running out of memory meanwhile. It seems also related to the change from formely having PDF tools outofproc, now inproc.

Regards
Andreas
User avatar
Roman - Tracker Supp
Site Admin
Posts: 306
Joined: Sun Nov 21, 2004 3:19 pm

Re: InProc vs. OutProc COM Server

Post by Roman - Tracker Supp »

Hi AnMuWK,

Unfortunately no, you cannot use PDFXChange Editor as an out-of-process COM server.
This is because most of the Editor SDK COM interfaces are not marshallable (for performance reasons).
we are running out of memory meanwhile
Is your application 32-bit?
AnMuWK
User
Posts: 30
Joined: Thu Dec 19, 2019 2:20 pm

Re: InProc vs. OutProc COM Server

Post by AnMuWK »

Hi Roman,
Is your application 32-bit?
Yes, it is.

Regards
Andreas
User avatar
Roman - Tracker Supp
Site Admin
Posts: 306
Joined: Sun Nov 21, 2004 3:19 pm

Re: InProc vs. OutProc COM Server

Post by Roman - Tracker Supp »

Hi Andreas,

You can make the Editor more frugal of the memory (possibly at the expense of performance) by setting

Code: Select all

"Performance.MemUsage" = <amount (in percents) of the available system physical memory> 
or

Code: Select all

"Performance.UseMemExact" = true
"Performance.MemExact" = <number of megabytes>
If your application gets short of the process address space it is better to try the second variant. Set "MemExact" value to something like 100 and see whether this helps. If so, then gradually increase the value until you find some reliable trade-off.

However the radical way to resolve this issue is to use 64-bit process to load and interact with PDF-XChange Editor COM server.
You can leave other components of your product 32-bit, but in this case you would have to develop a communication channel (using COM or something else) between the PDF-XChange Editor host process and the main process of your application.
Post Reply