FileSystemMonitor UDF

[seangriffin]

I get this error when opening some applications

See attached png image

Hi ripdad,

I've moved this script into a UDF now. Currently at v0.3 with lots of fixes. See how you go now.

Cheers,

Sean.

[seangriffin]

I got the same problem... I delete the file using Windows Explorer, and use the $monitor_type = 3 but it only report drive free space has changed.

There was a bug in the UDF where monitoring wasn't working after a change to the monitoring path. It's fixed in v0.3. Alot of other problems have been fixed in v0.3. I've done many tests on this version, using the two examples provided at the top of this topic, and it's looking good. I haven't been able to break it yet, or seen any such bugs.

[seangriffin]

I use your example on the first post.

So yes ...

Another question about the UDF.

Is it possible to have the name of a modified (content) file?

Checkout the latest version of the UDF (0.3), and the two examples provided. I've done lots of fixes and hopefully it's working now.

The UDF does currently report the names of files who's time stamp or attributes have changed. I just tried this myself, by running example #2 above, opening a text file in notepad, changing it's text and saving it. The result is it's last modified timestamp changes, and the script catches this and displays the change. It gives the filename also.

The following website explains in more detail what actions are monitored for directory changes:

http://msdn.microsoft.com/en-us/library/aa364391(v=VS.85).aspx

[ripdad]

Hi Sean - keep up the good work!

Here's my findings:

1. Still having the same AutoIt error - even with something as simple as clicking on the Windows solitaire game.

2. "FileSystemMonitor Explorer example.au3" has a typo error ...

"Case $LVN_ENDLABELEDIT" - should be --> "Case $LVN_ENDLABELEDITA"

3. See this image:

[Tlem]

+1

But for the update of FileSystemMonitor.au3 and the FileSystemMonitor example.au3, I'm really impress so tank you very much for your wonderful work.

[picaxe]

Nicely done, thanks for sharing Sean.

3. See this image:

The fix is to either comment out or delete this line

;_GUICtrlListView_SetUnicodeFormat($directory_listview, False)

or change to

_GUICtrlListView_SetUnicodeFormat($directory_listview, True)

[ripdad]

@picaxe

that fixed number 3 - thanks

[Tlem]

wonderful.

[ripdad]

scratch all that

-EDIT 3-

I believe I found the trouble-maker for Number 1 ..

"$SHCNE_EXTENDED_EVENT = 0x04000000" plus a unlisted "event item" = crash!

So .. what is the extended event? <grin>

$fs_event.item(Hex(0x04000000)) = "PROGRAM_EXECUTE|EXTENDED_EVENT"

Any Votes?

Edited May 2, 2010 by ripdad

[seangriffin]

Hi Sean - keep up the good work!

Here's my findings:

1. Still having the same AutoIt error - even with something as simple as clicking on the Windows solitaire game.

2. "FileSystemMonitor Explorer example.au3" has a typo error ...

"Case $LVN_ENDLABELEDIT" - should be --> "Case $LVN_ENDLABELEDITA"

3. See this image:

Thanks!

1. The cause seems to be "_GUICtrlListView_SetUnicodeFormat($directory_listview, False)", found above by picaxe. I don't get a garbled display myself. Maybe coz I'm not using Unicode fonts? Not sure. There was a a reason thought for including this line, but I can't for the life of me remember what it was! I recall something doesn't work if it's excluded. But I've excluded it just now, and everything seems to still work, so I'll leave it out. Will update the example above shortly.

2. I don't think this is a typo. It came from one of the listview examples in the AutoIT Help file. I've also confirmed in "ListViewConstants.au3" that this is correct:

Global Const $LVN_ENDLABELEDITA = ($LVN_FIRST - 6) ; The label editting is ending
Global Const $LVN_ENDLABELEDITW = ($LVN_FIRST - 76) ; [Unicode] The label editting is ending
Global Const $LVN_ENDLABELEDIT = $LVN_ENDLABELEDITA

Edited May 2, 2010 by seangriffin

[seangriffin]

scratch all that

-EDIT 3-

I believe I found the trouble-maker for Number 1 ..

"$SHCNE_EXTENDED_EVENT = 0x04000000" plus a unlisted "event item" = crash!

So .. what is the extended event? <grin>

$fs_event.item(Hex(0x04000000)) = "PROGRAM_EXECUTE|EXTENDED_EVENT"

Any Votes?

I think you raised a good point a few moments ago ripdad. I wasn't doing any error handling in the func "_FileSysMonActionEvent" for unexpected events. Yes as you said, the "StringSplit" was failing for a SHCNE_EXTENDED_EVENT. What a wierd event? MSDN's website mentions it, but it's description is "Not currently used.". Hmm. In any case, I'm going to whack a "if StringLen($fs_event.item(Hex($event_id))) > 0 Then" at the top of this code to ensure unexpected events don't crash it. Will update the topic shortly.

Cheers,

Sean.

[ripdad]

All I have in my copy of "ListViewConstants.au3" is:

Global Const $LVN_ENDLABELEDITA = ($LVN_FIRST - 6) ; The label editting is ending

Global Const $LVN_ENDLABELEDITW = ($LVN_FIRST - 76) ; [unicode] The label editting is ending

Also, I noticed according to the website that $SHCNE_EXTENDED_EVENT is not used.

But, evidently it is. I have no idea what it's "actually" doing.

I do know, that the only time I see it used is when I execute a program.

[seangriffin]

All I have in my copy of "ListViewConstants.au3" is:

Global Const $LVN_ENDLABELEDITA = ($LVN_FIRST - 6) ; The label editting is ending

Global Const $LVN_ENDLABELEDITW = ($LVN_FIRST - 76) ; [unicode] The label editting is ending

Also, I noticed according to the website that $SHCNE_EXTENDED_EVENT is not used.

But, evidently it is. I have no idea what it's "actually" doing.

I do know, that the only time I see it used is when I execute a program.

That's interesting. I think I'm running a version of AutoIT that's about 2 years old Sounds like the use of "$LVN_ENDLABELEDITA" is the safer bet. I'll go with that. Will update the example shortly. The update to the example will also ignore these other events, such as SHCNE_EXTENDED_EVENT. It will just report on the ones it knows about. Edited May 2, 2010 by seangriffin

[seangriffin]

Version 0.4 is now available for download.

Changes include:

• Updated "FileSystemMonitor example.au3" to include an $event_id check and filter for unexpected events.
• Fixed "FileSystemMonitor Explorer example.au3" to exclude the "_GUICtrlListView_SetUnicodeFormat" call.
• Fixed "$LVN_ENDLABELEDIT" to be "$LVN_ENDLABELEDITA" in "FileSystemMonitor Explorer example.au3" for better compatibility.

Has that addressed all the issues thus far? Edited May 2, 2010 by seangriffin

[ripdad]

seangriffin

Has that addressed all the issues thus far?

yes, sure looks like it - thanks

[seangriffin]

yes, sure looks like it - thanks

Thank you everyone!

I have to say, I'm not easily impressed, but when I see people across the world devoting their valuable time to helping others such as myself, in a forum like this, that's something really amazing.

I started this file system monitoring script a couple of weeks ago, not expecting it to be that difficult. But it's been very rewarding going through the research and development of it for AutoIT. Now hopefully I can easily integrate it into my Rapid Video Converter (which was the whole reason this all came about in the first place).

[guinness]

Wow! Thats pretty cool now and very easy to understand sine it's in the UDF format. Thanks for providing, will you lets us know when you finish the Rapid Video Converter?

[wraithdu]

Why use ansi constants / functions (LVN_ENDLABELEDITA) instead of the unicode versions? There's no reason not to make everything unicode compatible. Your current ansi version won't work right on other localized windows versions.

[seangriffin]

Why use ansi constants / functions (LVN_ENDLABELEDITA) instead of the unicode versions? There's no reason not to make everything unicode compatible. Your current ansi version won't work right on other localized windows versions.

Not sure what the issue is here. If you can point me at where the fault is in the script, and what the solution is, that would be good.

The LVN_ENDLABELEDIT / LVN_ENDLABELEDITA reference came straight from an example for the function "_GUICtrlListView_Create" in the AutoIT help file, v3.2.12.0.

[wraithdu]

No errors, simply a compatibility issue. If you leave your listview in ANSI format and don't use Unicode notifications / messages, then it will not be able to display unicode file names. Since your monitor deals with files, paths, etc., being unicode compatible is important. As I said, any localized OS with unicode characters in the file names will not display correctly. I haven't looked through your UDF, but if the other DllCall's you use are not Unicode as well, then the whole thing could fail.

You should make sure all DllCall's use the unicode version of the function if there is one (W suffix), you use unicode notifications / messages (LVN_ENDLABELEDITW), and you set the listview to Unicode format with _GuiCtrlListView_SetUnicodeFormat (might be default anyway).