Katharsis

The parentheses fixed it. Thanks! Also, the Au3Check is version 1.54.22.0.

...or maybe with the way it now communicates with CDO.DropDirectory. We have a script that monitors e-mails that come in to a drop directory. The script looks at the e-mails and sends a response accordingly to the user that sent the e-mail. However, after updating to the latest AutoIt, I cannot compile due to a supposed syntax error which does not exist. Here is the relevant code: $objDropDirectory = ObjCreate("CDO.DropDirectory") $colMessageCollection = $objDropDirectory.GetMessages($DropFolder) If $colMessageCollection.Count > 0 Then For $msg In $colMessageCollection $fileFullPath = $colMessageCollection.Filename($msg) If StringInStr($msg.To, "daily", 2) Then ...do stuff... EndIf Next EndIfThe error I receive upon compiling is this: (36,26) : ERROR: missing separator character after keyword. If StringInStr($msg.To, Clearly, there is a separator character. The comma is right there. This wasn't happening before 3.3.8.x. Any ideas?

Yes, I saw that (as I said I read it), but that didn't necessarily negate what he said before about it being dangerous. Even the link he provides from MS says: "Note This value is for system use only. To avoid unpredictable behavior, do not modify this value in any way." Anyway... From that MS link I did find the Wow64RevertWow64FsRedirection call. I can do this to make sure it's safe and it will only run for just that portion of the script: If @OSArch = "X64" Then DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1) $arrFileList = _FileListToArray("C:\Windows\System32\") _ArrayDisplay($arrFileList) If @OSArch = "X64" Then DllCall("kernel32.dll", "int", "Wow64RevertWow64FsRedirection", "int", 0) $arrFileList = _FileListToArray("C:\Windows\System32\") _ArrayDisplay($arrFileList) The first portion of this will actually talk to System32. The second will talk to SysWOW64. Problem solved. Thanks for the links.

Yes, and the response after that, from an MVP, said this: I took that to mean I shouldn't do it. I know they also said that it's only for the calling thread, but still, do you think this is safe?

As for the first link, writing a variable workaround won't do anything, since I'm already spelling it out for AutoIt, and it still decides to veto me. And the second link basically says it's not going to be fixed any time soon. In other words, AutoIt ousts me out of one of my own folders like a tyrant, and the developer says it's not being fixed, so the solution is to have two binaries. It's pretty upsetting for the developers to do this and think I don't know the difference between the two folders. I think it's time for me to move completely to VBscript. Thank you for your input.

Hmm, no they really are in system32, but apparently it's the SysWOW64 folder that's being looked at when I have #AutoIt3Wrapper_UseX64 set to no. Does anyone know of a way to FORCE AutoIt to REALLY check system32 if I have #AutoIt3Wrapper_UseX64 set to no? I'm not sure why it thinks I want to look in SysWOW64 if I'm not telling it to. Is this a case of it thinking I'm an idiot? Also, why is it that VBscript doesn't do that, but AutoIt does? That's pretty frustrating. Something else interesting: When I do MsgBox(0, "", @SystemDir), it will of course spit out C:WindowsSysWOW64. But apparently even if I use the aforementioned functions to look specifically at C:WindowsSystem32, it's as if AutoIt is vetoing me and saying, "No no no, idiot, you mean SysWOW64!" This is dumb. I say it's AutoIt because clearly VBscript doesn't do it. E.g. When I do this: $arrFileList = _FileListToArray("C:\Windows\System32\") AutoIt acts as if I'm doing this: $arrFileList = _FileListToArray("C:WindowsSysWOW64")

OK, well, I guess I'll have to figure out how to use VBscript to do it. But clearly _FileListToArray and FileFindFirstFile are not fully functional in Windows 7 x64 at least. Also, for more specifics, in the above screenshot, localspl.dll and LocationApi.dll have the exact same permissions and attributes. AutoIt shows one but not the other. EDIT: OK, so I changed #AutoIt3Wrapper_UseX64=n to #AutoIt3Wrapper_UseX64=y. Now it is showing all the files in system32. However, this won't do, because this code needs to be run on our XP 32-bit machines and any 64-bit machines as well.

None of the files are marked as hidden. It's not just these files, either. It's a LOT of files. This is just a small snippet. Also, I can get this to work fine in VBscript to find the particular file that AutoIt doesn't show: strDir = "C:\Windows\System32\" Set oFSO = CreateObject("Scripting.FileSystemObject") Set objDir = oFSO.GetFolder(strDir) wscript.echo getInfo(objDir) Function getInfo(pCurrentDir) For Each aItem In pCurrentDir.Files If LCase(aItem.Name) = "TestFile.txt" Then getInfo = aItem.Name End If Next End Function If it won't work in AutoIt, is there a way I can pass the result of the VBscript back into AutoIt? (The AutoIt script is the main file, and it's already about 1000 lines.)

Does anyone know why this is the case? I have been trying to write a script to find whether or not a certain file exists in system32, and it ALWAYS detects that it doesn't, even when it does. Also, _FileListToArray() simply does NOT find all files in system32. Here is a screenshot as proof. I am running as Administrator on Windows 7. The left side of the screenshot is an _ArrayDisplay of the results of _FileListToArray("C:\Windows\System32\"). The right side is the actual contents of a part of system32. The circles files are an example of what AutoIt does not pick up. I have Googled for this problem and found no results as of yet. This is a problem.

@water The new _AD_GetPasswordDontExpire() code works perfectly. The first array value is the number of accounts it found with Password Doesn't Expire, and the rest are the accounts, and only in the OU specified. That's what I was looking for. Thanks!

Thanks so much for these tools! I wish I had discovered this a long time ago. It's helping me a lot. I do have one question about _AD_GetPasswordDontExpire. I would like to use it in just a single OU, not the whole domain. However, there's no option for that, and when I try to connect with _AD_Open only specifying the OU I want, I still get a list of every account in the domain whose passwords don't expire. I'm using this format: _AD_Open("", "", "", "domain controller", "OU=TheOUIWant,OU=MainOU,DC=something,DC=com") $array = _AD_GetPasswordDontExpire()I know it's probably something I'm doing wrong. I just discovered these tools today.