Occasionally the PDF-XChange Viewer will present the user with a message saying that it has encountered a problem and needs to close. I wonder if there is a way that this situation can be detected via the SDK, so that my application can re-initialize the ActiveX control. It would be nice if an event were generated which my application could monitor, however I realize that this may not be possible due to the error situation.
If I knew the process ID of the instance of PDFXCview.exe that was running, I could check in code to see if that process had exited. However I have not been able to figure out how to do this. There can be multiple instances of the Viewer running, and some of them might be running standalone; there doesn't seem to be any way to determine which one corresponds to a given instance of the ActiveX control.
Anyone have thoughts on this?
Thanks.
Detecting viewer component failure
Moderators: PDF-XChange Support, Daniel - PDF-XChange, Chris - PDF-XChange, Sean - PDF-XChange, Vasyl - PDF-XChange, Ivan - Tracker Software, Stefan - PDF-XChange
-
- User
- Posts: 223
- Joined: Wed Aug 22, 2007 4:40 pm
-
- Site Admin
- Posts: 2449
- Joined: Thu Jun 30, 2005 4:11 pm
Re: Detecting viewer component failure
Code: Select all
Occasionally the PDF-XChange Viewer will present the user with a message saying that it has encountered a problem and needs to close.
We will to add some special features into next build:If I knew the process ID of the instance of PDFXCview.exe that was running, I could check in code to see if that process had exited. However I have not been able to figure out how to do this.
1. new parameters:
"General.ProcessID" - will represents server-process ID.
"General.ProcessName" - will represents name of special global synchronization-object(mutex) which unequivocally corresponds to server-process.
You will be able to test existence of server-process:
Code: Select all
string syncObjName;
GetProperty("General.ProcessName", syncObjName);
hMut = OpenMutex(READ_CONTROL | SYNCHRONIZE, FALSE, syncObjName);
if (hMut)
{
res = WaitForSingleObject(hMut, INFINITE);
CloseHandle(hMut);
}
Last edited by Vasyl - PDF-XChange on Thu Apr 23, 2009 8:26 am, edited 3 times in total.
PDF-XChange Co. LTD (Project Developer)
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
-
- User
- Posts: 223
- Joined: Wed Aug 22, 2007 4:40 pm
Re: Detecting viewer component failure
Sorry I wasn't more specific - I mean it really happens, my users have reported this a number of times. They are understanding about it because Acrobat (which we formerly used in our application) used to crash a lot. But I want to minimize inconvenience for them.Vasyl-Tracker Dev Team wrote:Please details: it hypothetically or crashes occurs really?
Thanks.
-
- Site Admin
- Posts: 5223
- Joined: Tue Jun 29, 2004 10:34 am
Re: Detecting viewer component failure
Understood and investigating - thanks for your patience.
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.
Best regards
Tracker Support
http://www.tracker-software.com
Best regards
Tracker Support
http://www.tracker-software.com
-
- User
- Posts: 223
- Joined: Wed Aug 22, 2007 4:40 pm
Re: Detecting viewer component failure
By the way, the proposed changes you have described sound good. I look forward to the release of build 42.
-
- Site Admin
- Posts: 2449
- Joined: Thu Jun 30, 2005 4:11 pm
Re: Detecting viewer component failure
About crashes..
We would like to fix it.
Thank you.
If you have a detailed information about it (for example: the problem document, sequence of user's actions which leads to crash) that please give us this information....I mean it really happens, my users have reported this a number of times...
We would like to fix it.
Thank you.
PDF-XChange Co. LTD (Project Developer)
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
-
- User
- Posts: 223
- Joined: Wed Aug 22, 2007 4:40 pm
Re: Detecting viewer component failure
I would love to provide you with sufficiently detailed information to reproduce the problem. Whether I can actually do so is another question. Our users do not operate in a standard environment - there are different versions of Windows, not to mention different hardware on which they are operating. There is no one particular document that causes the problem - they work with hundreds of documents per day, from many different sources. And in most cases they cannot tell me exactly what they were doing when an error occurred. So there just seem to be too many variables.Vasyl-Tracker Dev Team wrote:If you have a detailed information about it (for example: the problem document, sequence of user's actions which leads to crash) that please give us this information.
The only thing I can tell you is that their work consists exclusively of adding comments to documents - generally using the Sticky Note, Text Box and Typewriter tools, plus the underliner, strike-out and highlight tools.
I can tell you that one user reported several crashes in one day when she was using the stamp tool on a document that had very small text (I believe it had been created from a print document that was scanned into PDF) - she had the zoom level set at 200%, and as a result she had to resize each stamp after placing it on the page. Apparently the act of resizing the stamp was what would trigger the crash. However I have tried reproducing the error using this information, and could not. So evidently there is some other crucial factor which I cannot identify.
Thanks for your efforts.