Changes in the WordPerfect 6.1 ODMA patch

This is written to a technical audience that wants to know what changes in
the implementation of the ODMA spec have been changed in the WP 6.1 ODMA
patch.

1.  Fixed callback routine in the ODMSaveAs dialog to handle password
protection properly.  There was a typographical error in the current code
that caused the password protection choice to work incorrectly.

2. Changed the sequence of ODMA calls when saving a document for the first
time.  The original sequence was to call ODMNewDoc followed by ODMSaveAs. 
SS would call the callback routine if ODMSaveAs was called on a DocID that
had not been accessed.  BTW: This is an incorrect operation that the
ODMASAMP sample DMS also does.  PC Docs would ignore the ODMSaveAs call if
it is called right after an ODMNewDoc call. The new sequence is to call
ODMNewDoc with the ODM_SILENT flag.  If this returns a DocID, ODMSaveAs is
called.  If the ODMNewDoc fails with a ODM_E_USERINT it is called again
without the ODM_SILENT flag and ODMSaveAs is not called, however, WP does
call the callback routine for ODMSaveAs itself.

3. Fixed incorrect error handling when ODMGetLeadMoniker returns an
ODM_E_FAIL error.  This was not immediately visible to the user.  It just
caused weird problems at document save time or in the macro language.  If an
ODMA file was opened in a macro and the ODMGetLeadMoniker called failed, the
error condition would make it back to the macro interpreter and the macro
would halt execution, even though the file would appear to load without
errors.  It was also possible for internal states to be incorrect that could
affect save conditions.  WP thought internally there was an error on the
open, yet the file opened and appeared to be OK to the user.  There was no
error condition made visible to the user.

4.  The WP menu will no longer validate while ODMA operations are active. 
In the shipping WP 6.1 if a condition arises where the WP message loop
became active while an ODMA operation was active, it was possible to select
another menu operation while the current one was active.  This was a
particular problem with PC Docs.  If the user did a SaveAs operation while
there was two or more documents active, and then chose the Close menu option
while the SaveAs operation was taking place, WP would either crash or lose
the second document.  Now the menu will show all entries greyed out until
the ODMA operation completes.

5. Removed ODMA title squashing on the title bar.  PC Docs pulls a nasty
trick and monitors the title bar for part of its state.  WP was squashing
the name if it was too long.  It does not do this any more.

6. Added support for saving selected text as an ODMA document.

7. Added support for when ODMSaveDoc returns a different lpszNewDocId from
the lpszDocId that was passed in.  SS and PC Docs never return a different
DocID in the ODMSaveDoc call.  DEC TeamLinks does change the DocID.  This is
something WP was not designed to handle, since DOS never changes filenames
on a save operation.

8. Removed delayed write through of files to the DMS.  WP will no longer
update the local file on a menu "save" operation without writing the file
through to the DMS.

9. Fixed internal problem where opening a file without write rights would
cause WP to do a Read-Only open message box query.  This shows up on the
loading of graphic images.

10. Fixed internal problem where the code to load a graphic image called
the wrong close routine.  This caused the ODMA file to be closed, but WP
did not know it was closed.  This caused problems where loading a graphic
image would cause another read only dialog to come up as well as cause
WP to actually try to open it twice from the DMS.

11. WP now handles the ODM_E_INUSE failure on ODMOpenDoc as a read-only
situation.  It calls ODMOpenDoc again with the ODM_VIEWMODE flag set instead
of the ODM_MODIFY flag.

12. I believe that I have stopped changing the case of DocID's in all
the important cases.

13. WP will not call perform an extra call to ODMSaveDoc at file close time.

14. WP will now open a Read-Only file that is specified by Shell Execute or
on the command line.

ODMA Problems that were fixed in the first patch that was used as the base
code for this patch

1.  WP now passes -1 as the pagesPrinted and activeTime values to
ODMCloseDoc instead of 0.

2.  Fixed GPF when exiting WP with the "Create Summary on Exit" preference
active.

3.  Fixed problem where WP could violate the security in SS when a local
file store was used.

4.  Fixed problem where WP would GPF if you selected Exit with multiple
documents active.


Problems I would have liked to fix, but were bigger than I could do in the
patch.  These problems should all be fixed in the 32 bit release of WPWIN7.

1.  Stop changing the case of the DocID in WP.  The ODMA spec says that a
DocID is case insensitive, but does not say whether an application can
change the case of the DocID.  WordPerfect 7 will not change the case. 
WordPerfect 6.1 does change the case sometimes. -- Note I believe that I
have pretty much fixed this after all.

2.  There are a lot of places where the DocID shows up instead of the
ODM_TITLETEXT in dialogs.

3.  There are still some file I/O areas where ODMA makes sense, but I did
not have time to add it or there were technical reasons not to.

4.  The call sequence when ODMSaveAs returns a new DocId is not ordered
exactly the same as the "typical sequence of operations an application might
follow" in the spec.  WP will close the old DocId before opening the new
DocId.  This is not a real problem, but could affects the effiency of at
least one DMS.

5.  The call to GetLeadMoniker takes place after the call to ODMSaveAs but
before the call to ODMSaveDoc.  This means that if your DMS supports
GetLeadMoniker and changes the ID in ODMSaveDoc that the moniker will still
refer to the original DocId.  This currently does not affect any known
applications, but it is a potential problem.

6.  WP does not handle ODMA DocId's that have " and <space> in them.

7.  Trying to open a second copy of WP with a different file on the
command line will not work.

New additions made in the second ODMA patch

PC Docs uses DDE to communicate between its ODMA integration and main
application.  DDE is inherently asychronous in nature.  This means that
all DDE communication sequences need to be created as finite state machines
unless the communications are done in a sychronous way.  DDEML attempts
to turn the asychronous DDE calls into sychronous calls by just spinning
the message loop after the DDE message is posted until the response message
comes back from the other process.
For better or worse, WP assumes that the message loop will not run when
it is making a procedure call to many of its I/O routines.  PC Docs breaks
this assumption.  This is all related to problem #4 in the first list
of bugs fixed in the first ODMA patch.  There were two additional bugs
related to this problem that were fixed in this release.  In fact this
problem is the primary reason for the existence of this patch.
The big problem with the WP message loop becoming active while an ODMA
operation is active is that it is possible for a user to provide input
to WP that will start an operation that will corrupt the file while the
original ODMA operation is still completing.

1.  There was additional code added to WP to detect reentrancy conditions
taking place while ODMA calls are taking place.  Every ODMA call in WP
is wrapped so that the token handler can detect any time WP is trying to
execute a token while an ODMA call is active.  It is not able to fix the
condition, but it can show that it has happened.  WP will put up a message
box that says that an ODMA error has occurred and give some information
to relay to Corel support.  It will be obvious that this is not a normal
error message when it comes up.  If this condition ever occurs, please
notify Corel with the information in the error message and exit WP as
soon as possible after it occurs and check to see that whatever operation
you were doing when the error occurred completed correctly.  We expect that
this should never occur.

2.  WP now protects input from happening while tokens are executing
that have ODMA calls in them.  The button bars go grey.  The menu entries
are all grey.  No keystrokes are processed.  This is the same as
fix #4 above, but it is now implemented in the token processor.  The
new implementation is smaller, cleaner and allows the addition or subtraction
of any tokens necessary by just changing a table.  This has cleaned
up quite a few problems.

3.  There was an additional problem when a document switch would occur
immediately after an ODMA call executed.  WP would post itself a
SWITCH_DOCUMENT_NOTIFY message that was not supposed to be seen until
the ODMA call was complete.  However, since DDEML spins a message loop
that sends the unprocessed messages to the Document Window, this message
showed up too early.  The new code makes sure that the message is posted
back to the message queue without processing until the ODMA call is
complete.

4.  ODMA access has been added to "Insert Object from File".

5.  The length of DocId's supported on the command line is now 255 instead
of 64.

6.  Merge will not lower case the DocId's anymore.

7.  Timed backup will not take place while Tokens that include ODMA
operations are active.

8.  Files can be saved to the native application when they have not
been saved before.  This should only have been a problem on DMS's that
do not support the ODM_SILENT in the ODMNewDoc call.  This is most
likely PC Docs.

9.  WP will not process mouse clicks while ODMA operations are taking
place.  This keeps the MOVE_TO_XY_POSITION token from firing and
messing things up.
