 |
|
 |
when a file was coped,can it finger out?
|
|
|
|
 |
|
 |
Hi,
I am trying to use the CFileChangeEvent class in a cdialog-derived class. I manage to get the message that a file has changed, but if I try to do UpdateData() when this happens, the program crashes. I believe that this is for the same reason that the UpdateAllViews in the doc/view architecture wont work, but I am not sure how to solve this for a CDialog. Can Anyone please offer an solution?
Thanks a lot,
-----------------
Genaro
|
|
|
|
 |
|
 |
There is a bug in CFileChangeEvent::addFile in the following line:
m_Paths[nPath] ++ ;
// increment reference counter
m_Paths is declared as CArray<CFilePath *>, so the above line increments the pointer, instead of the intended calling of CFilePath::operator ++. It should be:
(*m_Paths[nPath]) ++ ;
and also inside CFileChangeEvent::removeFile it should be:
(*m_Paths[nPath]) -- ;
If you do not change these lines and call addFile twice for two files in the same folder and then close the program, you get a violation error.
|
|
|
|
 |
|
 |
I need to implement a RegistryChangeEvent, but I haven't been able to figure out how to do this. Any ideas?
Royce
|
|
|
|
 |
|
 |
I think there is an issue in the code detecting the "removed" event: After the createfile function: HANDLE f = CreateFile(it->second->getName().c_str() ... it checks the existance in the following manner if ( f ) but CreateFile returns INVALID_HANDLE_VALUE (0xFFFFFFFF) when a file can not be created.
|
|
|
|
 |
|
 |
I think you should change the code to this:
if(GetFileTime (f, &dtCreateDate, NULL, &dtFileDate))
{
if ( it->second->getDate().GetStatus() != COleDateTime::valid )
{
it->second->setDate(dtCreateDate);
pFileChangeEvent->OnFileAlarm(FA_CREATED, it->second->getName());
}
else
{
COleDateTime dtDate = dtFileDate;
if ( it->second->getDate() < dtDate )
{
it->second->setDate(dtDate);
pFileChangeEvent->OnFileAlarm(FA_CHANGED, it->second->getName());
}
}
}
else
{
pFileChangeEvent->OnFileAlarm(FA_REMOVED, it->second->getName());
pFileChangeEvent->removeFile(it->second->getName());
}
CloseHandle(f);
The problem is that, if the file is removed, for some reason, HANDLE f = CreateFile(it->second->getName().c_str() still returns a valid handler, so the if(f) exception is not reached, but the GetFileTime function do return an error. I did it this way, and works perfect.
Thanks a lot for your code
|
|
|
|
 |
|
 |
Your code is excellent.Could you give me some ideas about preventing a file from being deleted.I mean before a file could be deleted,let me confirm the aciton.Thank you very much.
jacky zhu
|
|
|
|
 |
|
 |
Hi,
I put your code in my application, and I'm having some problems to remove files from the list of files to watch.
My code is like below:
.
.
m_FileChangeEvent.removeFile( (const char *)lpszStr );
.
.
.
m_FileChangeEvent.addFile( (const char *)lpszPathName );
if ( !m_FileChangeEvent.isWatching() ) m_FileChangeEvent.startWatch();
.
.
Can you see anything wrong?
Thanks,
Vinicius
|
|
|
|
 |
|
 |
Warning You can't call the method UpdateAllViews in the OnFileAlarm. This is why :
A thread can access only MFC objects that it created. This is because temporary and permanent windows handle maps are kept in thread local storage to ensure protection from simultaneous access from multiple threads.
How can we solve this ?
I overide OnIdle() on tha CMyApp class. Added an ApplicationEventQueue class, ApplicationEventListener class & of course ApplicationEvent class. Taked care that OnIdle the queue will be checked and items (ApplicationEvents)will be handled
Creating an event is by "new CApplicationEvent"(destination). destination is inherit from CApplicationEventListener. and firing it is by callinf ->Fire(). The line looks like:
(new CApplicationEvent(this))->Fire()
Fire will place the AppEvent in the Queue. OnIdle, an Item from the queue will be fetched and will be called on:
Item = ApplicationEventQueue->RemoveHead();
Item->Listener->OnApplicationEvent();
Item->RemoveReference();
Very Simple. & it works great with a 15 short time liveing, dying, & rebornings threads
& GUI thread and it has no limitations like CDocument do not tiny object can add inheritence from CApplicationEventListener, fire an event on a methos via a 2nd thread handling and notify via the GUI thread.
BTW: 1 more thing!!!
The OnIdle() needs al the time to return TRUE, i.e. to demand more IdleTime.
I will be happy to hear contributed remmarks on that, or to get a more MFC standard solution that is still absolutely flexible and abstract!
Tnx
Amit
|
|
|
|
 |
|
 |
Can the API's watch a remote file (e.g. \\dmadden\share\filename.ext) ?? If so, how...
Thanks in advance,
Dan
|
|
|
|
 |
|
 |
Not sure that the behaviour is correct. I've ran the application, added "e:\1.txt" and "e:\2.txt" and then started the monitor. Then by creating a new file "e:\x.txt", I get a notification fired by the demo program for both 1.txt and 2.txt. I have tried this on an NT 4.0 and a W2000 machine with the same results
|
|
|
|
 |
|
 |
I just thought people would like to know that change notfications (FindFirstChangeNotification) do not work from a 95/98 machine watching a file on a NT Machine (network shared of course). Or maybe it is vice-versa an NT watching a file on 95/98? This is an undocumented issue that I brought to the attention of MS years ago but they never documented or fixed. Of course, this class will work fine for monitoring local files on either OS. But, there is no error checking for when FindFirstChangeNotification fails.
Also, the date and time of the file could be retrieved using GetFileAttributes or GetFileAttributesEx without opening and closing the file
|
|
|
|
 |
|
 |
I had the same problem, but I solved it by adding FILE_NOTIFY_CHANGE_LAST_WRITE and FILE_NOTIFY_CHANGE_SECURITY flags for my application running on NT operating system (including Windows 2000). But If you add these 2 flags, It will not work in 95/98 operating system. So put a OS check before adding these 2 flags, everything works fine.
|
|
|
|
 |
|
 |
Project file is missing in Demo projec
|
|
|
|
 |
|
 |
Here`s the solution...
- rename the original-project folder to something else
- make a new project called FileChange
- close this project
- copy all Files of the name-changed original folder to the new FileChange folder
- open the project (it will load without errors)
- attach the files FileChangeEvent.cpp/.h and FileInfo.cpp/.h to the project
- compile
hope that helps
|
|
|
|
 |