MFC opens docs STGM_SHARE_EXCLUSIVE
Mike Ward -- mikew@hilgraeve.com
Monday, June 03, 1996
Environment: VC++4.1, Win95/NT
SDI app, OLE server, Compound files enabled, Shared MFC DLL
MFC has a habit of opening doc files with the STGM_SHARE_EXCLUSIVE
flag. This has proven to be a problem to our app time and time again
since we usually have many readers but only own writer of the doc.
I'ld really like to open like to open the file STGM_SHARE_DENYWRITE.
Wading into the MFC code, it appears that everywhere a doc file is
opened, the first attempt is SHARE_EXCLUSIVE, and if that fails, then
its opened SHARE_DENYWRITE. I'm guessing one solution might be to
open the file SHARE_READ, let OpenDocument() do its thing, and then
close the SHARE_READ handle. Does anyone else have a suggestion on
how to work around this problem?
Michael Schuschk -- michael@rias.COM
Friday, June 07, 1996
Humba!
On Monday, June 03, 1996 6:09 AM, Mike Ward wrote:
> Environment: VC++4.1, Win95/NT
> SDI app, OLE server, Compound files enabled, Shared MFC DLL
>=20
> MFC has a habit of opening doc files with the STGM_SHARE_EXCLUSIVE
> flag. [...] Does anyone else have a suggestion on=20
> how to work around this problem?
No direct suggestion, but more info maybe. I have the same problem. My =
app needs to have read and write access to its compound file all the =
time. I tried all combinations of STGM_READWRITE with STGM_SHARE*. Only =
STGM_SHARE_EXCLUSIVE worked. Everything else caused StgOpenStorage or =
StgCreateDocfile to return with STG_E_INVALIDFLAG.
Browsing through "Inside OLE", I found only occurrences of =
STGM_SHARE_DENY_WRITE together with STGM_READ. My guess is that only the =
following combinations are possible:
STGM_SHARE_DENY_WRITE with STGM_READ,
STGM_SHARE_DENY_READ with STGM_WRITE and
STGM_SHARE_EXCLUSIVE with STGM_READWRITE.
I have no idea when STGM_SHARE_DENY_NONE can be used. It didn't work =
with STGM_READWRITE.
But even when your app is the only one accessing the compound file, a =
problem arises when you have MAPI support enabled and try to send your =
file via eMail. The mail client tries to open your compound file for =
reading and gets a sharing violation. My only solution would be to =
release the file before and reopen it afterwards.
Bye...Michael
/---------------------------------------------------------------------\
| Michael Schuschk michael@rias.com |
| Roche Image Analysis Systems |
| 112 Orange Drive I can think on my own, |
| Elon College, NC 27244 so I'm not speaking for the company |
| USA |
\---------------------------------------------------------------------/
Roger Onslow -- Roger_Onslow@compsys.com.au
Tuesday, June 11, 1996
>Environment: VC++4.1, Win95/NT
>
>SDI app, OLE server, Compound files enabled, Shared MFC DLL
>
>MFC has a habit of opening doc files with the STGM_SHARE_EXCLUSIVE
>flag. This has proven to be a problem to our app time and time again
>since we usually have many readers but only own writer of the doc.
>I'ld really like to open like to open the file STGM_SHARE_DENYWRITE.
>Wading into the MFC code, it appears that everywhere a doc file is
>opened, the first attempt is SHARE_EXCLUSIVE, and if that fails, then
>its opened SHARE_DENYWRITE. I'm guessing one solution might be to
>open the file SHARE_READ, let OpenDocument() do its thing, and then
>close the SHARE_READ handle. Does anyone else have a suggestion on
>how to work around this problem?
We had a similar problem (especailly during testing, were the app
somtimes crashed and left the file locked!!)
We have a "library" document which is usually only read, but
is occasionally written as things are added/updated/deleted.
To avoid locking the library, we talk a simple approach
(though perhaps not as nice).
We simple open the library document, read it, and then close it,
(without deleting the contents). When the app exits, we delete
the contents "manually").
If we need to write to the document, we simply re-open it, write it
and close it (again without deleting contents).
Only trick when doing this is MFC's insistance on deleting
the contents of the document. Even setting m_bAutoDelete
= FALSE doesn't help (still does DeleteContents, just
stops doing a "delete this;"). So we overrode DeleteContents
to do nothing and explicitly called a real contents deleter
when doing the final close (and delete).
Here's some code...
void CLibrary::LoadLibrary(LPCTSTR libname) {
CFileStatus status;
CWaitCursor wait;
if (! CFile::GetStatus(libname,status) || !
COleDocument::OnOpenDocument(libname)) {
if (! COleDocument::OnNewDocument()) {
::AfxMessageBox("Could not create or load library\n"+libname);
return;
}
}
CloseLibraryKeepData();
}
void CLibrary::SaveLibrary(LPCTSTR libname) {
m_bRemember = FALSE;
CWaitCursor wait;
if (! COleDocument::OnSaveDocument(libname)) {
::AfxMessageBox("Could not save library\n"+libname);
return;
}
CloseLibraryKeepData();
}
void CLibrary::DeleteContents() {
// don't delete contents when closing
// as we close straight after load
}
void CLibrary::CloseLibraryKeepData() {
m_bAutoDelete = FALSE; // don't delete
COleDocument::OnCloseDocument(); // does NOT delete this
m_bAutoDelete = TRUE;
}
void CLibrary::CloseLibrary() {
m_bAutoDelete = TRUE;
RealDeleteContents(); // really delete contents now
OnCloseDocument(); // does delete this
}
| Вернуться в корень Архива
|