1. ReadDirectoryChangesW. QM uses it for file triggers.
2. SHChangeNotifyRegister. QM uses it to monitor scheduled tasks.
3. Change Journals. Did not try it.
ReadDirectoryChangesW can wait, or can use event and you can wait for the event.
SHChangeNotifyRegister is easier. I think it is better to use if you for example need to be notified that something modified a file that is opened in your editor.
Now I cannot give examples. Try to find C++ examples. In QM would be similar.
Not sure what to do with any of this...I'm downloading the Windows SDK because apparently there are examples there. Wish they could just be online. Whatever...9hrs later...
Anyone have other good resources for examples on how to use this?
ret ;messages sel message ,caseWM_INITDIALOG ,CFileChangeMonitor- t_fcm ;;declare one thread variable for each folder you will monitor ,if(!t_fcm.Register(hDlg "$personal$"));;monitor My Documents folder ,,mes"failed to set file change notifications""""!" , ,caseWM_DESTROY ,t_fcm.Unregister ,caseWM_COMMANDgoto messages2 , ,caseWM_USER+145 ,;wParam is SHNOTIFYSTRUCT containing pidl of the file or folder (depending on event). If renamed, also contains the new pidl. ,;lParam probably is wEventId of SHChangeNotify (documented in MSDN library) ,SHNOTIFYSTRUCT& n=+wParam ,str s1 s2 ,if(n.dwItem1)PidlToStr+n.dwItem1 &s1 ,if(n.dwItem2)PidlToStr+n.dwItem2 &s2 ,out"0x%08X %s %s" lParam s1 s2 , ,;notes: ,;SHChangeNotifyRegister documentation says that sometimes multiple messages are combined into 1. ,;Also, sometimes more than 1 notification may be sent for the same event. ,;Sometimes notifications may be not sent. Eg if an app forgets to call SHChangeNotify after it makes a change, and OS does not call it too. Especially in older OS. ,;I don't know, are dwItem1 and dwItem2 always pidls. Maybe sometimes they can be paths or friendly names, like when calling SHChangeNotify with SHCNF_PATH etc. ret ;messages2 sel wParam ,caseIDOK ,caseIDCANCEL ret1
QUESTION:
Is it possible to track the file changes in relation to a QM control?
In other words, I have shdocvw control which points to a folder, I want to track the changes the shdocvw control makes.
(Not in relation to the folder the shdocvw points, but the changes the shdocvw control makes when running)
I have used the trigger $f 0x449 "C:\" from the above mentioned topic and tracked the changes to the folder:
C:\Users\r0n\AppData\Local\Microsoft\Windows\AppCache
C:\Users\r0n\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData
C:\Users\r0n\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content
C:\Users\r0n\AppData\Local\Microsoft\Internet Explorer
C:\Users\r0n\AppData\Local\Microsoft\Windows\INetCache\IE
I was hoping the above example in this thread could be applied (constrained) to an control (shdocvw):
sel message ,caseWM_INITDIALOG ,CFileChangeMonitor- t_fcm ;;declare one thread variable for each folder you will monitor ,if(!t_fcm.Register(hDlg "$personal$"));;monitor My Documents folder ,,mes"failed to set file change notifications""""!" , ,caseWM_DESTROY ,t_fcm.Unregister ,caseWM_COMMANDgoto messages2 , ,caseWM_USER+145 ,;wParam is SHNOTIFYSTRUCT containing pidl of the file or folder (depending on event). If renamed, also contains the new pidl. ,;lParam probably is wEventId of SHChangeNotify (documented in MSDN library) ,SHNOTIFYSTRUCT& n=+wParam ,str s1 s2 ,if(n.dwItem1)PidlToStr+n.dwItem1 &s1 ,if(n.dwItem2)PidlToStr+n.dwItem2 &s2 ,out"0x%08X %s %s" lParam s1 s2 , ,;notes: ,;SHChangeNotifyRegister documentation says that sometimes multiple messages are combined into 1. ,;Also, sometimes more than 1 notification may be sent for the same event. ,;Sometimes notifications may be not sent. Eg if an app forgets to call SHChangeNotify after it makes a change, and OS does not call it too. Especially in older OS. ,;I don't know, are dwItem1 and dwItem2 always pidls. Maybe sometimes they can be paths or friendly names, like when calling SHChangeNotify with SHCNF_PATH etc. ret ;messages2 sel wParam ,caseIDOK ,caseIDCANCEL ret1
Again if to complex/time consuming, I understand.
I can always continue to use the alternative cleanup solution from the original topic.
(The reason for this method is to be "100%" sure I am cleaning up traces of changes the control makes.)