How to catch invalid drop?

[anovy]

Hi,
I need to catch a drop of a file with invalid format (non PDF) and handle such file by myself. The only event which is sent during such drop is "Prompts.ConfirmDropFile", however it says nothing about valid/invalid format. So how can I detect that the dropped file is not in PDF format?

[Stefan - PDF-XChange]

HI anovy,

On the event a file is dropped you might intercept that and try opening the file with OpenDocument - if it is not a valid PDF then you will catch the error thrown from OpenDocument, will know that the file is not a valid PDF and will be able to program your custom operations for handling non PDF files.

Regards,
Stefan

[anovy]

But the question still remains the same: How to correctly detect, that the error is 'invalid format'? I want to process only this error. I noticed that here OpenDocument returns 0x82140002 which is equal to the PS40_ERR_INVALID_FILE_FORMAT constant defined in the pdfstr40_errors.h file. But I'm not sure if this will be valid also for all future versions of PDF-XChange viewer (ActiveX version), because these constants are undocumented.

I found some error codes only in the PXCView36SSDK_Help.chm file (which I think is for DLL version), however they differs (e.g. PS_ERR_INVALID_FILE_FORMAT=0x820f0002). I'm really confused here, because this help file has '36' number in the name (I suppose some version string), the similar header file for error codes is named pxcview36_errors.h, it includes pdfstr40_errors.h, and it defines PS40_* constants. However the PXCView36SSDK_Help.chm file lists the PS_* constants (defined in pdfstr_errors.h file).

[Lzcat - Tracker Supp]

You found the correct code, and it will not be changed until the next major version update.
PXCView36SSDK_Help.chm is documentation for the older version of our simple SDK (yes, it was named 3.6 to match the driver version at the time, and current version is 2.0), so it contains different definitions (old ones).
HTH.

[anovy]

Thanks for help. And I hope you will keep the same error constants also in next major versions to keep the backward compatibility.

[Stefan - PDF-XChange]

This is up to the dev team to say, but if there is no need for these codes to be changed I do not think they will

Regards,
Stefan

[anovy]

Hi,
I just found that although this method generaly works, it has one big disadvantage:
To catch silently the 'invalid format' error from OpenDocument I must call it with PXCVA_NoUI flag. However then OpenDocument does not display any other possible dialog or notification. The problem is for example in SDI mode when the current document is modified. Then it is replaced by the new document without 'Save before closing' prompt (i.e. all changes are lost without user's choice to save them). Any idea how to solve this?

BTW:
I still think that you should provide some method to test a file (or stream) if it is in PDF format. I suppose you already have such internal method, so it should not be problem to expose it via DoVerb method. For example DoVerb(NULL,"IsFormatPDF",datain,dataout,0), where datain contains file path or stream and dataout returns FALSE or TRUE (or PDF format version number).

[Stefan - PDF-XChange]

Hey anovy,

Asked our LazyCat for some further input here and am sure one of the first things tomorrow he would do would be to answer you.

Best,
Stefan

[Vasyl - PDF-XChange]

Hi, anovy.

We will add the fast feature into the next build, like as:
DoVerb(NULL, "IsPDF", dataIn(<stream|filename>), dataOut, 0);
Please wait for the next build.
Now you will be able to use the temporary solution for "IsPDF" testing:
PXCV_ReadDocumentW or PXCV_ReadDocumentFromIStream from pxcview.dll.

HTH.