TheDcoder

@Xandy You might be talking about the bash scripting language, it is indeed a programming language which works with the popular bash shell. It is not really as graceful as AutoIt though...

Yes, it does, however using it is not ideal... a native program will be heaps better and would be favoured by users who actually want to release a proper linux binary of their script It is written in C++ (I am planning to do it in C), you are more than welcome to work on the code if you think it is easy Right, but AutoIt is more than an automation tool... I never really used it for automation since the beginning, it is a great programming language above all for me!

AutoIt is closed source and Jos is part of the AutoIt Team, I doubt Jon would give me access to the code to port it... and I imagine it would be very hard to port the existing codebase. What I want to do is port the bare minium first as I have mentioned, we can take things from there.

None exists as far as I am aware... except maybe the very old version from which AHK was forked from.

@Exit I suppose you can make an april fool joke at any day in april if you are brave enough

Hello everyone, it has been a while since I have been involved in a serious AutoIt-related project discussion in the forums here, so it feels good to be back at it First a little backstory, a few months back (or a year ago) I made the switch to Linux from Windows... there were several reasons as to why I was motivated to do it, but the main things was Windows 10 was getting out of hand, it didn't offer enough freedom out of the box (restrictive settings, greedy defaults etc.) and had several issues with all kinds of software, many of them mysteriously hard to fix. I did have Linux installed as my secondary operating system for few years at that point and I began to see me regularly use it more than Windows, so one day I went ahead and said "fork it", I have stuck to Linux from that point on as my primary operating system. Windows is still installed in my computer and I also have a virtual machine with the latest version of Windows 10 on it, primarily because I still use Windows to write software using AutoIt as part of my job (freelance). I was pretty sad about the fact that I could no longer use AutoIt to make stuff for myself (since it doesn't run on Linux), I missed sharing code with the community here, this was a great hobby for me as AutoIt is what got me start with programming (even though I had tried several times to get into other languages before, those attempts were never as successful as what I have done in AutoIt). In Linux there is no language which is similar to AutoIt unfortunately, there are a few things which come close but are not on par with AutoIt's ease of use. As some of you may know, I have recently started working on other projects using the C language, it is a great step I have taken and I am learning a lot... but it is still not easy to create quick scripts or programs in C, due to the amount of configuration and dedication it takes to make a C program, also it is not ideal for sharing as multiple source files are involved. And on top of that you still have to deal with platform-specific APIs since C is a low-level language. (Getting back to core of this topic's subject) To solve this issue and to sharpen my programming skills, I could start working on an alternate cross-platform implementation of the AutoIt language which should be backwards compatible with the current AutoIt v3 on C The primary aim in the beginning is to implement all the basic functions (File, String, Numbers etc.) in AutoIt so that it is possible to make basic and fundamental scripts which would work in both Windows and Linux The main features would be: Cross-platform (Linux and Windows with the possibility supporting of Mac) Backward compatible with AutoIt 3 Byte-code based interpreter instead of source interpreter Easy to use (just like the current AutoIt) The advantage of having a byte-code based interpreter is that it makes the interpreter lighter and faster since it doesn't have to deal with parsing the source code, this would also open the door for some compile time optimizations... another bonus thing for those who don't like their source code present inside the compiler binaries is that it should be impossible to get hands on the original source code, this of course does not mean that decompilation can be stopped... it merely means that anyone decompiling would have to reconstruct the code from the byte-code. We can later on implement GUI related functions and maybe even automation related functions if the project gets enough traction I am adding a poll to keep track of people who are willing to invest in this project or would like to see it come into existence. Welcome any comments, suggestions etc. Obviously I will have a lot to learn and my work might interfere with this at times, but with enough interest I can see myself working on this to deliver a very basic prototype which could be used with basic scripts.

Like WinWaitClose but for windows that hide themselves instead of closing, if WinWaitClose doesn't work for you, then your should try this: ; $WIN_STATE_VISIBLE is stored in this include #include <AutoItConstants.au3> Func WinWaitHidden(ByRef $hWindow) While True Local $iState = WinGetState($hWindow) If Not BitAND($iState, $WIN_STATE_VISIBLE) Then Return Sleep(250) WEnd EndFunc

Try to find the source for the video feed, you can use a video player to directly stream the video and then use PixelChecksum on it... Most browser allow you to inspect elements by right clicking on them, you can also search for <video> elements in the DOM explorer and find the source Or maybe even your camera itself provides a way to get the video feed directly? -- Though I doubt PixelChecksum would work as it would detect any changes in pixels, so even a moving leaf could trigger the script... also it might not be the most efficient way to check for changes in a video stream

I suspect that this is the hardest part, it would be tricky to do it efficiently. Is this your first AutoIt project? If yes, then this might be a complex start...

@Rhidlor My pleasure, you may also find it useful to know how to directly execute scripts via the AutoIt3.exe interperter without compiling them: https://www.autoitscript.com/autoit3/docs/intro/running.htm

Execute the script directly via PHP and supply the data as command line parameters, that is how I always do it. Make sure you sanitize all user input before passing it into the command.

That is perfectly fine and acceptable, if you have the technical know-how and are willing to put in effort to write code with fewer layers, then that is a good thing in any imaginable way. But that is not my point at all! Using the raw implementation is often not that easy, especially for beginners. And since how AutoIt is meant to be a simple language, it is natural for it to have many wrapping functions, just look at the huge library of WinAPI UDFs. Most of those implementations are not optimized, but what they lack in performance make up in ease of use Most of the time the average AutoIt coder would look at how to accomplish a certain task, rather on how to accomplish it in the most efficient way using the direct APIs In my opinion, the AutoIt community largely owns up to the amount of UDFs it has. That is one of the beauties of the language, it is easily extensible. I am not contesting this fact I gracefully disagree, it is what you make of it. Beauty is what you make of it, if you can write code which is easy to understand and is very organized, then it is beautiful in that manner. UDFs help achieve that by wrapping "dirty" functions calls (especially DllCall) into a consistent set of functions

@LarsJ For me the beauty of AutoIt is that it is simple to create UDFs to wrap any slightly complex tasks (like handling objects) in a simple function call, performance doesn't really matter most of the time if you are using an interpreted language, and I don't agree that it matters in this instance... _ArraySearch would still take up a lot of time than the overhead of wrapper functions will ever take up @iamtheky I do remember your UDF, you bought it up in one of my topics about maps I have gone searching for that on several occasions, but it is elusive, never managed to find it when I needed it... It could be polished but it is usable in the current state

Scripting.Dictonary is also a good candidate for associating variables with strings, shame no one has made a proper UDF wrapping it yet (that I know of)...

@Nine Yes, I do have an example I learned all of this quite recently too, while porting one of my AutoIt projects to C, had to learn a lot about WinAPI. Here is the example in my actual code (which is part of a library): // Source: https://github.com/DcodingTheWeb/liballium/blob/241fbf79cd709b1babed42a6c2cb2d1351844ce6/allium.c#L167 unsigned long bytes_read; if (ReadFile(instance->stdout_pipe, buffer, 1, &bytes_read, NULL) == false || bytes_read == 0) return NULL; // P.S The forum doesn't have highlighting for C :( You can see that in the if statement I check if ReadFile has returned false (it will return false if there is an error), this condition will evaluate to true when the child process closes its write handle to the standard output. A bit of warning if you actually want to study the whole function as an example, I have mixed POSIX and WinAPI functions with the help if #ifdef through out the code, so it can get confusing if you are not familiar... Also sorry about hijacking your thread BetaLeaf

Yes, it will set @error if the child process is still running, the way how it works is that the child process has a handle to write to stdout, if the child closes it, then StdOutRead will set @error because the stream has been closed. The more technically accurate explanation is that, to read the stdout of a child process, you will have to use the ReadFile/ReadFileEx function. The child can use the CloseHandle function on its write handle without exiting, this will make the ReadFile function in the parent return an ERROR_BROKEN_PIPE error, which means that the other end of the "pipe" (write handle) has been closed. More details from the documentation: That is how StdOutRead would detect EOT/EOL and set @error and how the child could still well be running Though I should mentioned that it is rare for programs to close their stdout write handle without following up with an exit, but still a thing to note That is perfectly fine to do as well, I was just trying to provide a more generic loop, it is meant to be adjusted to your needs... like how in this case it might be a good idea to detect the elapsed time and exit the loop when it reaches 0

If StringRight ($sOutput, ??) = "Something" Then ExitLoop ; this is the tricky part, you need to find a way to know <End of Transmission> @Nine This is nice to have, but not needed to detect EOT or EOL at all, since StdOutRead should set @error if the child has ended the transmission by closing the stream

This is correct, to be more accurate, StdoutRead sets the error if EOF has been reached, meaning the stream has been closed and there is no more data available. The application can still keep the stream open but the buffer might be empty, in this case you can check @extended for the number of bytes read, which would be 0 if the buffer is empty. Here is an ideal loop: While True Sleep(10) ; Don't kill the CPU $sOutput &= StdOutRead($iPID) If @extended = 0 Then ContinueLoop ElseIf @error Then ExitLoop EndIf WEnd

@BetaLeaf I also recommend using $STDERR_MERGED with Run to capture the standard error stream as well, otherwise you would not get anything which might be written to STDERR

@jchd Good point, I did not notice that ProcessExist was being used, just saw that the function accepted a string instead of the PID in the documentation. @Deye Yes, a matter of personal preference I guess... though most of the time in my scripts I do readily have the PID of the processes that I would want to automate the GUI for The best course of action would be to just change the documentation to also include the fact about accepting PID

@Deye An useful snippet, I recommend accepting a PID instead of a process name since it is more accurate and flexible in terms of which process to target, your function could return undesireble results if multiple instances of the same process exist. Using a PID would solve the problem

@water Just tested with Microsoft Word 2016 (not 2019, oops ) and it works: @error = 0x00000000, @extended = 0x00000000 I can also find the Doc1.docx file under "My Documents" as mentioned by @Nine

Is it okay if I test it using the 2019 version? That is the only version I have installed at the moment. I will be able to test this later tonight

If you are talking about automated testing that you can run everytime to check the code for bugs, then AutoIt does not have a testing framework (that I have seen). Someone has made an extension for AutoIt in Visual Studio if I remember correctly... ah, here you go:

I discovered another way to hugely cut up the speed... by using the inbuilt AutoIt transpose function! Just set $bForceFunc parameter to true and enjoy the gains #include <Array.au3> #include <Excel.au3> #include <MsgBoxConstants.au3> Global $iTotalTime = 0 Test() Func Test() Local $oExcel = _Excel_Open() Local $oBook = _Excel_BookAttach("Test.xlsx", "FileName", $oExcel) Local $sSheet = "Sheet1" If @error Then Return MsgBox($MB_ICONERROR, "Excel Failed", "Failed to attach to Excel") Local $iNum Time() Local $aData = _Excel_RangeRead($oBook, $sSheet, "A1:B6", 1, True) Time() _ArrayDisplay($aData) For $iRow = 0 To 5 Time() Local $iNum = Number($aData[$iRow][0]) If $iNum = 1 Then ConsoleWrite("Row " & $iRow + 1 & " is 1 and value of column B is " & $aData[$iRow][0]) Else ConsoleWrite("Row " & $iRow + 1 & " is not 1") EndIf ConsoleWrite(". Reading took: ") Time() Next ConsoleWrite("The whole operation took " & $iTotalTime & " milliseconds." & @CRLF) EndFunc Func Time() Local Static $hTimer Local Static $bRunning = False If $bRunning Then Local $iTime = Round(TimerDiff($hTimer), 2) $iTotalTime += $iTime ConsoleWrite($iTime & @CRLF) Else $hTimer = TimerInit() EndIf $bRunning = Not $bRunning EndFunc 24.44 Row 1 is 1 and value of column B is 1. Reading took: 0.04 Row 2 is not 1. Reading took: 0.01 Row 3 is 1 and value of column B is 1. Reading took: 0.01 Row 4 is 1 and value of column B is 1. Reading took: 0.02 Row 5 is not 1. Reading took: 0.01 Row 6 is 1 and value of column B is 1. Reading took: 0.01 The whole operation took 24.54 milliseconds. From 1500 ms to 120 ms, and finally to 25 ms, that is an astonishing 60x improvement in total The excel function for transposing must really suck... or it accounts for a lot of things that our array transpose function cannot. Either way, I am happy with the outcome.