OpenDocument causes 'RPC Server unavailable'

[cew]

Hi,

I sometimes run into problems with the following workflow:

My app has a listview with several docs the user can select from.
Selecting a new doc, the opened doc in the pdfviewer gets checked for modifications and asks the user if he wants to save the changes before switching to the new selected doc.

Sometimes the load of the new doc fails with:
HRESULT: 0x800706BA (RPC Server unavailable)

Stacktrace:

Code: Select all

 bei System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   bei System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)

It looks like a timing problem.
Are DocumentSave and DocumentLoad running asynchron?
Will the new OpenDocument start before the view is ready again?

- OS: Win7
- SDK 2.5.194

What can cause this problem??

Best regards
cew

[Vasyl - PDF-XChange]

Hi, cew

Will the new OpenDocument start before the view is ready again?

It's possible when OpenDocument/SaveDocument was called in async. mode. You may try to resolve it by setting the PXCVA_Sync flag in Flags argument...

HTH.

[cew]

Hi Vasyl,

Will the new OpenDocument start before the view is ready again?

I checked the state with a flag, set in your BeforeSave and remove in DocumentSaved events.
Before I call OpenDocument, i check that flag, but the workflow seems to be ok.
Internally, the viewer will get in trouble, especially on slow machines when repeating open - modify - save - close - open - modify - save - close ........

It's possible when OpenDocument/SaveDocument was called in async. mode. You may try to resolve it by setting the PXCVA_Sync flag in Flags argument...

Setting the flag will cause async mode as described in the documentation

To disable automatic simulation of synchronous calls, specify this flag.

I set the flag in all Open/Save/CloseDocuments-Methods, but the error still occurres.

[Vasyl - PDF-XChange]

Hi, cew.

We cannot reproduce it. Can you provide simple example for reproducing?

Thanks.

[cew]

Sorry, I can't provide a sample.

But I identified a possible problem source:

Save a large document and pull your network cable.
The PDFXChange viewer will run into a massive problem and has to be closed.

This could be our problem at our customer because their network is not really reliable.

In case of reading/saving problems an exception would be nice that we can react to this problem. But the control is complete dead and causes error to following steps using it.

Please help!

Best
cew

[Vasyl - PDF-XChange]

Hi, cew.

Save a large document and pull your network cable.
The PDFXChange viewer will run into a massive problem and has to be closed.

We have tested this situation several times. The viewer control always breaks the saving process and returns a file read/write error code from the called SaveDocument method. No crashes...

You are however right - when a document has been opened from other machine on a LAN - then after this procedure (the network cable is unplugged) it becomes unusable - it displays (wrong) blank pages or a read-error message box periodically.

Note: in .NET, VB6 etc, you should try/catch each call of any COM-method because it can throw an exception message when the control returns an error code (file open/write error, for example). Look for examples in our SDK.

FYI: Adobe's Acrobat also exhibits this wrong behavior in this case - it hangs or crashes after some time if a network-cable is unplugged during the read/save process.

I agree there should be a better solution for this rather unique situation and we will work towards a solution in the new version expected late spring..

Best
Regards.

[cew]

You are however right - when a document has been opened from other machine on a LAN - then after this procedure (the network cable is unplugged) it becomes unusable - it displays (wrong) blank pages or a read-error message box periodically.

Note: in .NET, VB6 etc, you should try/catch each call of any COM-method because it can throw an exception message when the control returns an error code (file open/write error, for example). Look for examples in our SDK.

If I could catch events I could react, but the control dies (see screenshot)



Best regards
cew

[Vasyl - PDF-XChange]

Hi, cew.

We still cannot reproduce this problem.

However I can offer you the following workaround: don't open files on network directly - create a local copy before and pass it to our control.

This will resolve possible issues/conflicts with opening/reading documents. And you may use the special property to replace in the UI the real local name by the network name of the source:

Code: Select all

ctrl.SetDocumentPropety(docId, "DispFileName", "<FullNetworkFilePath", 0);

HTH.