10 posts in this topic
I have a bit of code that works on my old Win10 PC, that fails on my new Win10 PC, and I think the only significant difference is the version of Autoit - old PC has 3.3.12, new has 3.3.14.
I couldn't find anything mentioned in the change logs though, so perhaps I'm wrong.
Anyway, the code to replicate my issue is:
Test('username', 'DOMAIN') ; THIS ERRORS: ;Test('localun', 'DOMAIN') ; THIS ERRORS: ;Test(' ', ' ') ; THIS ERRORS: ;Test('', '') ; THIS ERRORS: ;Test('localun', '') ; THIS ERRORS: ;Test('', 'DOMAIN') Func Test($un, $dom) $compName = 'PCNAME' $FullName = '.' $Description = '.' ; get the WIM object $objWMIService = ObjGet("winmgmts:\\" & $compName & "\root\cimv2") ; get default user full name and description $objAccount = $objWMIService.Get("Win32_UserAccount.Name='" & $un & "',Domain='" & $dom & "'") If IsObj($objAccount) Then $FullName = $objAccount.FullName $Description = $objAccount.Description EndIf ConsoleWrite($FullName & @CRLF) ConsoleWrite($Description & @CRLF) Return EndFunc
On my old PC this code will output just . and . for each of those line currently commented out. Which is fine.
On my new PC any of those commented out lines of code cause an error, and the script won't even compile.
$objAccount = $objWMIService.Get("Win32_UserAccount.Name='" & $un & "',Domain='" & $dom & "'") $objAccount = $objWMIService^ ERROR I'm very much a newb with the WMI stuff and objects, but it looks like the .Get property is failing when either $un or $dom aren't valid in v3.3.14, whereas in 3.3.12 the .Get would fail to return an object, which is then caught by the If statement.
Am I on track with this? Is there some new/better way to code the example so that 3.3.14 will compile it?
Howdy, this is my first post, massive fan of autoit.
I've searched and tried and I would just like people who are better at this than me to let me know if this is even a thing.
I'd like to perform just a variable. For example, it would be. *see inserted code*
So what i'm wanting is, create the constant $test, and that variable would be what is followed after the = . Then perform the _FileCreate. Then perform the variable. Logically or in my head rather.. That variable is declared and is equal to what it is set to above, therefore just placing the variable plainly in the script, it should be equal to what it was declared as. So what am I doing wrong, and or how can I have autoit just perform the variable.
#include <File.au3> Const $test = FileWriteLine(@DesktopDir & "\Log.txt", @CRLF ) _FileCreate(@DesktopDir & "\Log.txt") $test
I have a script , during compilation and test execution, it worked perfectly but sometimes I am getting error as "Variable used without being declared."
I understood somewhere in the branching logic this is happening.
But not able to find it exactly.
As I am using multiple include statements.the line number is also not giving accurately.
Can anyone suggest what is the approach to resolve this?
UDF to intercept the error window of AutoIt, showing more details about the error, including ability to save and send by email!
I am attempting to drag and drop a file from one windows explorer window to another windows explorer window (henceforth referred to as window1 and window2). I am not using the web. I have used autowinexp.au3 (taken from LarsJ's automatewindowsexplorer.au3) to give focus (function GetFileFocus) to a file on window1. The problem is that sometimes the file with the focus is not displayed on window1 because it is farther down the list than what is displayed in window1. There are other ways to accomplish this (like copy and paste) but I want to emulate the GUI doing a drag and drop. I work as a digital forensicator and my task is to examine what artifacts are left behind on move/copy vs a drag and drop. Please note that when I open window1 and window2 they are on top of each other, so I drag window2 over about 1150 pixels and that part works great.
My code is listed below. Please understand that I have tried several different methods to accomplish this task. The last one was to estimate that the top of the window1 header is approximately 320 pixels and to multiply the index of the file by 20 pixels since that appears to be the approximate height of individual files using the AutoIT Windows Info tool. Ideally the program would search window1 for the file name text and provide a mouse position for it. Or the program would allow me to scroll to where the file name is located. Any and all ideas are welcome.
Using Windows 10
PS Any problems in autowinexp.au3 are mine and not the author of automatewindowsexplorer.au3.