|
I did not know what was meant by the initial question and the answer could have depended on the difference.
People trying to help often waste their time answering a misunderstood question. People asking questions should try to be clear. In this situation, this person is not trying. It is now not important for this question, but this person will likely waste people's time in the future.
My guess is that this person is not using the best solution for their fundamental problem. They probably think that this solution is the easiest, but then they will need to enhance it some more and the final solution is likely to be more work than if they considered all their requirements initially and asked for solutions for all the requirements.
|
|
|
|
|
I understood what he meant. Sometimes people do be vague and it annoyes me, but in this instance I didn't have any problems.
Steve
|
|
|
|
|
I have not been very active in CodeProject, but in the CodeGuru forums I was the first to hit 10,000 posts and about 99% of them were efforts to help others. So I have seen quite a few vague questions and such. People often spend less time asking a question than we spend answering them. In this situation, my guess is that there are better answers if the person were to take the time to be clear about requirements.
|
|
|
|
|
I can't argue with you there.
Steve
|
|
|
|
|
I am a rank amateur fighting scope creep and finalizing (one can always hope!) a general educational program in MFC/C++ Document/View after years of "bang your head on the wall" programming. It is good to allow multiple instances of the program, and extensive testing using multiple instances has uncovered only one apparent issue - the ability of multiple instances of the program to open and edit the same file. When switching with Alt-Tab between two instances of the program with the same file open, it is possible to overwrite the file from either instance, resulting in the ability to lose work by overwriting with an earlier version.
How can I use a semaphore (or anything else) to prevent the user from opening a file that is already open, or at least give the user a warning on file open or save? I am having trouble understanding how to use the semaphore (or anything else) to lock the file when I open it or test to see if it is locked when I try to open it again because there just do not seem to be many examples out there due to the apparently prevalent desire to prevent multiple instances of an application.
Thanks in advance for your time and consideration.
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
A named Mutex object would work if you want to synchronize access to the file at the thread level
across processes.
An easier method would be to open the file in a share mode that doesn't allow others to open the
file (or at least denies write access).
lctrncs wrote: a general educational program in MFC/C++ Document/View after years of "bang your head on the wall" programming.
Some would say with MFC Doc/View you can expect many more years of the same.
|
|
|
|
|
Mark Salsbery wrote: Some would say with MFC Doc/View you can expect many more years of the same.
As a biochemistry type, I find programming to be like an incredibly difficult puzzle. You can move the parts around and try them here and there, and eventually they fit. I am trying to learn what the parts are and how they fit together, but my numb biologist's brain may not be correctly configured for such endeavors.
Thank you for the nice clue.
Including a CreateFile function passing a dwSharedMode 0 in my OnOpenDocument allows me to open a file when I use the lpszPathName of OnOpenDocument as the first argument in the CreateFile function.
If I then try to open the file a second time using a different instance of my app, a "sharing violation" message appears.
If I try to save the first instance of the file using the first instance of my app, a First Chance Exception occurs that passes "access denied" back to the program.
I have tried various file attributes, but am probably doing something more basic wrong.
Any suggestions?
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
lctrncs wrote: If I try to save the first instance of the file using the first instance of my app, a First Chance Exception occurs that passes "access denied" back to the program.
How are you saving the file? Have you overridden OnSaveDocument() as well? If not, then you
should, and use CloseHandle() to close the file handle returned by CreateFile() in your
OnOpenDocument() override.
lctrncs wrote: As a biochemistry type, I find programming to be like an incredibly difficult puzzle. You can move the parts around and try them here and there, and eventually they fit. I am trying to learn what the parts are and how they fit together, but my numb biologist's brain may not be correctly configured for such endeavors.
Thanks for reminding me that questions can come from a different point of view. Apparently I'm
bitter about the Doc/View architecture. I used it for years with both Borland's OWL framework
and MFC (even had an article published on the subject). Because of the direction my user
interface code ended up going, Doc/View became more and more of a nuisance and at this point
I still have code using it a bit but not completeley. Some day I hope to have the time to remove
it. It's actually a great model and well implemented in MFC for RAD but I've found that extending
it gets complex unless one knows the MFC code intimately. I guess I have a love/hate relationship
with Doc/View. Way off topic, I know, but my comment in the first reply was really unnecessary
and you reminded me of that, so thanks 
|
|
|
|
|
Thanks for another clue.
I added an OnSaveDocument by hand since the classwizard stopped allowing me to add new member functions a while back.
Sadly, overriding OnSaveDocument and using CloseHandle to close the file handle resulted in no change in the program's behavior (I did not check how a second instance of the application's attempt to open the file). I still receive the access denied messge in the primary program when I try to save. I defined a handle in the Doc.h file so both functions could see it. Since I do not understand how CreateFile is working in concert with OnOpen/SaveDocument (and have precious little time to learn) it is difficult for me to proceed.
I can probably release my new version as is with it's numerous cosmetic and operational improvements (you can see the current version at www.studypartnernow.com) and just warn users about this issue.
I hate to take your time. Any other suggestions?
Mark Salsbery wrote: Apparently I'm
bitter about the Doc/View architecture.
I used to be a Microsoft evangelist - until I worked on the launch of Windows 95 as a "Remote Service Engineer." Microsoft technology COULD have been mega cool, but it appears to me that at some point money became the primary motivation for operations, and everything has been downhill ever since on the technical side, especially in the absence of viable competition.
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
Oops - getting crispy in crunch mode.
I added and overrode (I think) an OnSaveDocument function, not an OnSaveFunction or OnSaveRecord.
Thanks for all your help.
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
I'm trying to figure out where the access denied message would even come from. It's a message
box that pops up? Can you post the code for your CreateFile() call, especially all the
flag/security params you are passing?
Also, you're not calling the base class OnOpenDocument/OnSaveDocument I hope.
lctrncs wrote: I used to be a Microsoft evangelist
That always reminds me of "Cup-o-Joe", an evangelist on the worldwide live broadcast of the
rollout/introduction of Windows 95 (I think).
|
|
|
|
|
THANK YOU!
I wonder if the problem stems from the flat file database I have hanging off the doc/view.
CODE FOR CreateFile call etc.
From StudyPartnerDoc.cpp file
/////////////////////////////////////////////////////////////////////////////
/////////////////// OnOpenDocument //////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////
BOOL CStudyPartnerDoc::OnOpenDocument(LPCTSTR lpszPathName)
{
if (!CDocument::OnOpenDocument(lpszPathName))
return FALSE;
//Get a pointer to the view
POSITION pos = GetFirstViewPosition();
CStudyPartnerView* pView = dynamic_cast<cstudypartnerview*>( GetNextView(pos) );
//Tell the view that its got a new data set
if (pView)
pView->NewDataSet();
/////////////////////////////////////////////////////////////
// Attempts to prevent file overwrite when multiple copies of app open the same file
///*
//CreateFile and dwsharedmode to prevent make file read only when one instance is using it
//opens the file - but "access denied" passed through to program on save after First Chance Exception
m_hFileLock = CreateFile(
lpszPathName,
GENERIC_WRITE|GENERIC_READ, // access (read-write) mode
//0, //attempt to use "query device attributes without accessing the device."
0,// share mode
NULL,// pointer to security descriptor
OPEN_EXISTING,// how to create
FILE_ATTRIBUTE_NORMAL,// file attributes
NULL); // handle to file with attributes to copy
//FILE ATTRIBUTES TRIALS
//FILE_ATTRIBUTE_NORMAL - crash on save
//FILE_ATTRIBUTE_TEMPORARY - access denied
//FILE_FLAG_WRITE_THROUGH - First Chance Exception on save
//FILE_ATTRIBUTE_HIDDEN
DestroyDialog(); //Ensure that the Study Dialog is closed
return TRUE;
}
/////////////////////////////////////////////////////////////////////////////
/////////////////// OnSaveDocument //////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////
BOOL CStudyPartnerDoc::OnSaveDocument(LPCTSTR lpszPathName)
{
if (!CDocument::OnSaveDocument(lpszPathName))
return FALSE;
////////////////////////////////////////////////////
// Close the file handle opened for CreateFile and dwShareMode
CloseHandle( m_hFileLock );
return TRUE;
}
////////////////////////////////////////////////////
////////////////////////////////////////////////////
////////////////////////////////////////////////////
////////////////////////////////////////////////////
//From doc.h file
class CStudyPartnerDoc : public CRichEditDoc
{
//protected: etc...
public:
// MFC Overrides
BOOL OnOpenDocument(LPCTSTR lpszPathName);
BOOL OnSaveDocument(LPCTSTR lpszPathName);
HANDLE m_hFileLock;
//etc.
}
Thanks again!
Mark Salsbery wrote: That always reminds me of "Cup-o-Joe", an evangelist on the worldwide live broadcast of the
rollout/introduction of Windows 95 (I think).
Cup-o-Joe? LoL. Never heard of him. Microsoft and the other two companies tied up in the project kept us pretty busy with classes (and not quite true statements) etc. right up until the second they turned on the phones. I will have to check this out a bit.
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
You're welcome!
Calling the base class OnOpenDocument() (CDocument::OnOpenDocument()) the file using a CFile
object, reads the file into a CArchive object, and closes the file. No problem there except a
waste of CPU cycles and RAM.
Calling the base class OnSaveDocument() (CDocument::OnSaveDocument()), on the other hand, opens
the file using a CFile object in this mode: "CFile::modeCreate | CFile::modeReadWrite |
File::shareExclusive" which will fail miserably since you've opened the file with CreateFile().
Thus, calling the base class methods is a bad idea in this case - you are handling the open/save
functionality yourself.
Once you've opened that file with no sharing enabled, any other attempt to open the file will
fail, which should work nicely with your multiple processes.
Mark
|
|
|
|
|
You appear to be correct about the failure of other attempts to open the file once I have it open with CreateFile. Such attempts yield a Sharing Violation message. However, the Access Denied exceptions upon attempts to save the primary file and the Invalid Handle exceptions upon attemtps to close the primary instance of the application with the file open or closed remain an issue. 
It appears that I am not even gaining access to the file to save it, AND something else seriously wrong associated with CreateFile is interfering with nominal shutdown of the program. 
You can look at an earlier version of the program at www.studypartnernow.com. I wonder if the flat file database that also contributes to the file structure might be part of my problem with the CreateFile.
Groff
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
Maybe I misunderstood....you did remove the calls to the CDocument::OnOpenDocument and
CDocument::OnSaveDocument in your derived document class, right? I noticed they were still
in the code you posted so I'm not sure if you did that before or after the last messages we
exchanged.
Those need to be removed or there will be problems for sure!
Mark
|
|
|
|
|
I just was not sure that
if (!CDocument::OnOpenDocument(lpszpathname)
return FALSE;
was the same as
CDocument::OnOpenDocument
However, I thought I understood you to say that both were to be removed for the success of the CreateFile. I attempted this, but encountered problems when I removed the calls to the base classes.
Below, please find a matrix indicating the results of a quicky test of the various possibilities.
Column 1 2 3 4 5
OnOpenDoc base class code 0 1 1 1 1
OnSaveDoc base class code 0 0 0 1 0
CreateFile code 1 1 0 1 0
First app opens file? 0 1 1 1 1
First app saves file? x Inv. Hndle 0 Acc.Den. 0
Open second file instance? x 0 1 0 x
It appears that the best results occur in column two and four, in which the app opens the file and prevents use by a second app while it has it open. However, both of these configurations result in exceptions when the user attempts to save the file.
Note that the base class calls appear to be required for function of the open and save capabilities.
It appears that the challenge revolves around restoring functional save capabilities when the base class calls are not present and the CreateFile code is, or overcoming the Access Denied exception that occurs when the open and save base class calls are present in conjunction with the CreateFile code.
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
lctrncs wrote: It appears that the challenge revolves around restoring functional save capabilities when the base class calls are not present and the CreateFile code is, or overcoming the Access Denied exception that occurs when the open and save base class calls are present in conjunction with the CreateFile code.
Yes.
I looked at your code again and noticed your document class is derived from CRichEditDoc.
You'll definitely need the serialization code used in CDocument::OnSaveDocument() to get the
changes to save. Sorry about that!
I (now) think the simplest solution would be to copy the code from CDocument::OnOpenDocument() and
CDocument::OnSaveDocument() into your overridden implementations. Then tweak the CFile related
code to hold the file open for the entire time the document is open. Also adjust the open flags
appropriately to prevent sharing. Something like this:
class CStudyPartnerDoc : public CRichEditDoc
{
CFile StudyPartnerDocFile;
public:
virtual BOOL OnOpenDocument(LPCTSTR lpszPathName);
virtual BOOL OnSaveDocument(LPCTSTR lpszPathName);
virtual void OnCloseDocument();
};
BOOL CStudyPartnerDoc::OnOpenDocument(LPCTSTR lpszPathName)
{
#ifdef _DEBUG
if (IsModified())
TRACE(traceAppMsg, 0, "Warning: OnOpenDocument replaces an unsaved document.\n");
#endif
CFileException fe;
if (!StudyPartnerDocFile.Open(lpszPathName,
CFile::modeReadWrite | CFile::shareExclusive, &fe))
{
ReportSaveLoadException(lpszPathName, &fe,
FALSE, AFX_IDP_FAILED_TO_OPEN_DOC);
return FALSE;
}
DeleteContents();
SetModifiedFlag();
CArchive loadArchive(&StudyPartnerDocFile, CArchive::load | CArchive::bNoFlushOnDelete);
loadArchive.m_pDocument = this;
loadArchive.m_bForceFlat = FALSE;
TRY
{
CWaitCursor wait;
if (StudyPartnerDocFile.GetLength() != 0)
Serialize(loadArchive);
loadArchive.Close();
}
CATCH_ALL(e)
{
StudyPartnerDocFile.Abort();
DeleteContents();
TRY
{
ReportSaveLoadException(lpszPathName, e,
FALSE, AFX_IDP_FAILED_TO_OPEN_DOC);
}
END_TRY
e->Delete();
return FALSE;
}
END_CATCH_ALL
SetModifiedFlag(FALSE);
return TRUE;
}
BOOL CStudyPartnerDoc::OnSaveDocument(LPCTSTR lpszPathName)
{
StudyPartnerDocFile.SeekToBegin();
CArchive saveArchive(&StudyPartnerDocFile, CArchive::store | CArchive::bNoFlushOnDelete);
saveArchive.m_pDocument = this;
saveArchive.m_bForceFlat = FALSE;
TRY
{
CWaitCursor wait;
Serialize(saveArchive);
saveArchive.Close();
}
CATCH_ALL(e)
{
StudyPartnerDocFile.Abort();
TRY
{
ReportSaveLoadException(lpszPathName, e,
TRUE, AFX_IDP_FAILED_TO_SAVE_DOC);
}
END_TRY
e->Delete();
return FALSE;
}
END_CATCH_ALL
SetModifiedFlag(FALSE);
return TRUE;
}
void CStudyPartnerDoc::OnCloseDocument()
{
CRichEditDoc::OnCloseDocument();
StudyPartnerDocFile.Close();
}
Note that in CStudyPartnerDoc::OnOpenDocument() I left the original error handling when opening
the file. You'll probably want to handle it more gracefully in cases where the file is open
in another app instance (sharing violation).
Maybe I'm on the right track and haven't completely derailed...
|
|
|
|
|
Mark,
Thank for all your help.
This feature is becoming a bit too much for my current schedule.
Chances are that I will return to it at some point. However, for right now I am going to have to put this on the back burner because I need to generate some income (through freelance writing) and find a way to protect my Doc/View based content files (six are ready for posting) so that they cannot be edited and then misrepresented as the work of my company.
Since setting the "read only" bit on the file will not be permanent enough, I thought I might save a flag with my original files then override DoSave to prevent saving if the flag is set.
Another way might be to somehow embed the file in the program itself, so each content file distributed from my company comes with a program, again with DoSave = NULL in the Save As function or some such thing. This approach has the added benefit that I could distribute the content using Armadillo (which I use to provide 30 day trial functionality) which is not able to protect simple unzippers and non-executables.
Since the second approach probably requires the completion of the first, it looks like that will be my starting point.
Thank you again. Your posts were very educational, useful and well written. If you were on my team, I'll bet you could fix all of the problems I plan to spend the next 6 months beating my head against the in an afternoon.
Thanks again. I hope you enjoy your "greetings seasons." Take the rest of the year off.
Groff Schroeder
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
lctrncs wrote: Thanks again. I hope you enjoy your "greetings seasons." Take the rest of the year off.
You're welcome! I wish I could take the rest of the year off but I am about to release my own
product (yeah, I said that last year at this time, and the year before...) which is 5 years
in the making. I have to get it out...this living as a "starving artist" thing is getting old.
At least I have the drums to beat out my aggressions
Anyway, I may have missed the point of what you were trying to achieve. If it's protecting
content then I would make the doc/view editors read-only and encrypt the content files so they
can't be edited outside of your application. There's always a solution (I refuse to ever be
convinced otherwise).
Best of luck (or "break a leg"?) on your writing projects!
Mark Salsbery
|
|
|
|
|
Drums!?
My little band needs a drummer badly. Do you like Pink Floyd? Do you live anywhere near Colorado?
When you get close with your product, send me a version and I will happily test it for you. I once turned down a full time job teaching college for a six-week gigue testing network protocol analyzers for HP. I stayed a year and a half, then came back as a full consultant. Those were the days! Testing is specialty of mine and since you have been so helpful, I would gladly punish your software for you. Bwaahahahahhaaaa!
If you send me your email address through that web site I sent you to, we can both avoid public postings.
Best of luck.
Groff
PS: Thanks for the heads up on the download error. I experienced the same thing and learned that the problem occurs when the complete file does not download. It is about 5.5 meg, so it is probably easy to try to start early. I will probably put up a little warning page in my "free time." GS
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
BOOL CStudyPartnerDoc::OnSaveDocument(LPCTSTR lpszPathName)
{
StudyPartnerDocFile.SeekToBegin();
...should be
BOOL CStudyPartnerDoc::OnSaveDocument(LPCTSTR lpszPathName)
{
StudyPartnerDocFile.SetLength(0LL);
StudyPartnerDocFile.SeekToBegin();
...
|
|
|
|
|
I downloaded the free demo...is that the right one?
I get the following error in a messagebox:
<exe path="">\Setup.ini
Invalid Database.
The Installation will be cancelled.
|
|
|
|
|
The Win32 CreateFile function's dwShareMode parameter can be use to control this without the need to mutexes. Passing in a value of 0 should do the trick.
Steve
|
|
|
|
|
Thank you for responding.
Won't this collide with my existing code for opening files?
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
Thank you for the nice clue.
Including a CreateFile function passing a dwSharedMode 0 in my OnOpenDocument allows me to open a file when I use the lpszPathName of OnOpenDocument as the first argument in the CreateFile function.
If I then try to open the file a second time using a different instance of my app, a "sharing violation" message appears.
If I try to save the first instance of the file using the first instance of my app, a First Chance Exception occurs that passes "access denied" back to the program.
I have tried various file attributes, but am probably doing something more basic wrong.
Any suggestions?
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
