Confused by "file paths of files opened by a process" code

[Mbee]

I need to obtain a list of files that are open by another process. @Decipher posted some code in the examples section that is supposed to accomplish this, here: Retrieve full file paths of files opened by a process!  But not only am I confused by some type-mismatched code there that I (in my personal opinion) consider sub-par, but in several cases it just doesn't work correctly.

The problem I see fairly often is that the function _ProcessListFiles() returns an apparently empty array of open file paths, even though I'm 100% certain that the process in question has at least one open file (and usually quite a few).  One problem seems to be related to the fact that the value stored at $aFiles[0] is perhaps not consistently treated as an integer but rather as a string (?)

I won't post the code in its entirety here (it's all shown at the page I've linked above), but here are the dubious, type-mismatched code I'm confused by...

In Func _ProcessListFiles...

  For $n = 1 To $aFiles[0]    ; <-- Possible type mismatch?

  If $sPath Then              ; <-- $sPath is a string and certainly not a logical True/False. What is the result of this test?


In Func __IsFileObject...

  There are several bald "Return" statements which do not specify True or False or any other return value, even though the calling code treats the return code as a logical value.
 

In Func __FileObjectPath...

  Is it possible for this func to return a null string? It's possible that this is one of the things that goes wrong when I call _ProcessListFiles().

General...

  There are several Static declarations followed immediately by assignments. I understand that these assignment statements are ignored after the first pass, but might this be involved somehow in the bogus returns that I get from _ProcessListFiles() on occasion?
 
 
Bottom line, I would greatly appreciate some help with two issues: (1) Why does this code occasionally fail?  (2) How would you re-code this to meet more rational coding standards, such as using and returning properly typed variables, such as logical True or False instead of relying on mysterious ones and zeros?

 

Thanks!

 

[spudw2k]

Just some initial feedback.

 

In Func _ProcessListFiles...

  For $n = 1 To $aFiles[0]    ; <-- Possible type mismatch?
Typically this is how to enumerate through an array.  The author is expecting that the array $aFiles was populated in a manner which set the first array element is the count of array indecies (Ubound).  AFAIK, an array in AutoIt can have any data type, so even if you expect strings, the first element could (and in this case should) be an integer.

  If $sPath Then              ; <-- $sPath is a string and certainly not a logical True/False. What is the result of this test?
Doesn't look like the most useful condition eval, I agree.  In this case I assume the author is just checking to see that the variable was set to something that is <> 0 and <> "". Here's how I understand the conditional.
If $var = 0 OrAnd $var = "" Then Return False
If $var <> 0 AndOr $var <> "" Then Return True

edit: wrong logic ^

In Func __IsFileObject...
  There are several bald "Return" statements which do not specify True or False or any other return value, even though the calling code treats the return code as a logical value.
Another assumption...thinking the author just took the shortcut to not specify a return value that is not false.  Per the help file,  when using, "... the Return keyword to exit the function...user-defined functions return 0 unless another return value is specified."

Edited November 1, 2016 by spudw2k

[Mbee]

Hey, thanks,  @spudw2k !  I'm sorry I didn't reply sooner, but I missed the notification email...

I appreciate the assistance!  At the moment, I'm looking at another way of obtaining the info I need (using @Melba23 's mods to @seangriffin 's "FileSystemMonitor UDF"), but there's a problem with it...

 

Thanks again.

 

Edited November 1, 2016 by Mbee