I'm having a problem with the interaction between a custom EPDM add-in I wrote and the EPDM SolidWorks add-in. 

The add-in I wrote is designed to generate a PDF file every time a SolidWorks drawing enters the Approved state in my workflow.  To accomplish this, I am simply using the EdmCmd_PostState hook to listen for file entering the Approved state.  If the file is open in SolidWorks, it is activated with a call to ActivateDoc from the SolidWorks API.  If it is not open, a call to OpenDoc7 is made to open it.  Next, a call to SaveAs is made to generate the PDF.  All this works just fine, unless the file was already open in SolidWorks. If so, the generated PDF is one revision 'behind' the expected revision.  For example, if the file was at Revision 1 before the state change that sends it to the Approved state, it should be at Revision 2 after entering the Approved state.  However, the generated PDF will still be at Revision 1.

I have traced the problem to the SW EPDM add-in.  It makes changes to the on-screen document after my add-in has completed its work.  Specifically, any changes due to transition actions that set variables do not show up until after my add-in has finished processing the EdmCmd_PostState event.  I created a simple test workflow and add-in to demonstate the problem.  Here is a screen shot showing the bad behavior:

  As you can see, the dialog box shown by my add-in code correctly shows the file revision as 3, whereas the open document in SolidWorks is still showing revision 2.  Only after I dismiss the dialog box and my add-in exits the OnCmd method does the SW document update the revision to 3.

I originally implemented a workaround in which my add-in closed and then re-opened the offending document before generating the PDF.  This solved my problem but introduced another. The SolidWorks add-in throws up an error message every time:

It seems that the add-in is holding a pointer the open document.   I close and re-open that document, but the EPDM SolidWorks add-in doesn't notice and it tries to use the now invalid pointer once I've exited my OnCmd method.  The error message is only an annoyance, since all the files end up where they should be with the correct revisions, but since the error happens every time, it gets tedious very quickly.

Have I missed something, or is this just the way it works?

Jim S.