CosmicDan

Good to see someone is interested in carrying on the torch This was a nice project. I myself decided to move on to Java + JNA, which is really fun and exciting. In a few days I'm already where I was at with the original AutoIt version. My original concerns regarding memory consumption were inflated - with G1GC and a small initial heap size, the program is only consuming about 60MB of RAM - considering that's with the whole Java 8 classpath available and JNA + JavaFX active, that's pretty decent. Thanks for convincing me to move on @BBs19

Yeah, when it comes down to it AutoIt just wasn't designed with these things in mind. That's fair enough. AutoIt is slow in raw speed, e.g. loops of arithmetic, but it's extremely fast in e.g. GUI's (when designed properly) because it's all actually drawn by the underlying WinAPI. Some faux-concurrency can be achieved by using event mode (why anybody uses message loop mode is beyond me, it's so much slower and more fragile) but yeah it's far from ideal. Probably wouldn't help with web requests. I'm using AutoIt because for these kinds of tools the only other choice I have is to re-learn C++ and MFC to do a lot of stuff from scratch in tens of lines that AutoIt can do in one. I'd essentially have to re-write AutoIt from scratch! OOP would be nice, but if I have to trade automatic memory management then nah no thanks lol. But again, if only AutoIt was open source EDIT: I think, actually, I can do what I want with Java + JNA (JNA allows calling the WinAPI). But I am worried about performance, and I like that AutoIt is so self-contained and low memory usage.... *sigh* first-world problems!

Fair enough. I've actually restarted my project from scratch since discovering guinness's "OOP-like approach in AutoIt" concept which is really clever, hopefully it helps keep things neat as the program grows in scale! [Rant time...] Yeah, other languages may be better for making "apps", but AutoIt remains very valuable and relevant when you're creating a tool that needs to be "very native", self-contained and reliable but don't have time doing it in C(++). Granted, it's more and more of a niche these days - what with workflows moving more into the cloud and all that stuff - but C#/CLR is still pretty trash when you want to be close to the Win32 API WinAPI. C#/CLR is also much slower than AutoIt in some cases. Or maybe "laggy" is a more accurate description, what with the JIT-compiling VM layer and all.... AutoIt is just FAR less bloated than CLR or Java thanks to it being closer to the metal (just compare the startup time and RAM consumption of a "Hello World" message box between those languages)... ...but yeah, C# or even Java is probably better for an "app". In my case I'm making something that augments the Windows Shell (Explorer) to fill the void since ClassicShell was retired. And it would of been nice to have a modern-looking UI for the configuration screens is all. I've since opted to stick to the native Win32/GDI GUI's though that AutoIt does internally though. Faster and more reliable, anyway. As for AutoIt being dead, well... just because something hasn't been updated, that doesn't mean it's "dead". This idea people have gotten of software needing regular and constant updates to be considered "alive" is a result of lousy programmers writing lousy code. I suppose it helps that the Win32 API WinAPI is extremely mature, backwards compatible and maintained by some of the best darn software engineers in the world.... There really is no need for new features in AutoIt beyond what UDF's and/or DllCall's can do already. I consider AutoIt as "finished" and "mature" rather than dead. If it can't do something in AutoIt then I could just fire up a C(++) IDE and write a new function from scratch. I've not had a need to yet, though. AutoIt is very suitable for a couple of my projects, the only other alternative would be to do it all from scratch in C(++). By "multitasking" I assume you mean multithreading...? Because that's perfectly possible right now, you can use pipes and various other IPC methods available in the WinAPI. Works fine. The reason why it never came into AutoIt proper is because it just makes no sense to have multithreading in AutoIt. It's not a game engine, dbms or video encoder... I mean really, even if AutoIt DID have a native and fast asynchronous I/O framework built-in I would have to seriously question any developer who chose AutoIt over another language for a multithreaded app. Programming languages are like tools, not race cars. There rarely is a "best" language - just some languages being more suitable than others at certain tasks. The fact that the forums here still have some active posts is pretty clear proof that AutoIt isn't dead. Even if it is an old man in a retirement home, it' still alive In many cases, C#, Java or any other third-generation/VM language is simply not possible because they all had the design goal of abstracting-away the underlying environment. That kind of thing is great if you want to make an "app" of course, but not if you want to make a "tool" for OS-level tasks. I will say one thing - it would be really nice if AutoIt was open-sourced. Development has of course been stagnant, and there are some nice QoL suggestions that could be made that'd eliminate the need for UDF's. [/Rant]

Hi, Understandable, it's a bold project. AutoItObject UDF is quite old, and I lack the skill to maintain it - so there is no rush. I've decided instead to work on my own preprocessor to convert pseudo-OOP code (i.e. fake) into Au3 code. It's not *real* OOP, but it will make it look like it - neater code, the appearance of encapsulation, calling methods on variables, things like that. I'll be sharing it in a new thread once I have something a bit beyond a proof of concept Thanks anyway!

I did see that, but I think it's useless when class properties can't even be strings. I've opted to recreate my tool in an "OOP-like" paradigm as previously described by guinness. It's good enough - I mostly just wanted a basic level of encapsulation, even if it's only pretending to be.

People still using AIO these days? Any new performance or stability issues? I think I'm going to convert my project to it. I did find that it wasn't working in Windows 10 x64 (unless using the 32-bit wrapper) but I found a v1.2.8.3 fork which works

Shame your server is down so I can't see the docs :\ is the project dead? Or is it "finished" and production-ready? Please consider moving the documentation to ReadTheDocs or something, if you are still around... or at least a mirror of the docs uploaded here or somewhere.

I managed to solve the accelerator/tabstop issue for the moment, but now I've found an outright bug - When enabling or disabling a button, the hovers become unresponsive - if you click on the GUI however they work again. Re-activating the GUI does not solve it. I traced this cause to the GUICtrlSendMsg function. It's sending a message of code 0x172. I see that you're using raw numbers instead of constants all over the place. Wtf? How is anybody supposed to figure this out? This is not the first bug I've encountered, either, but the code in this UDF is too difficult to read. I think I'll just go and make my own implementation from scratch.

Great UDF, looks nice and runs fast. Sadly the lack of accelerator and tabstop support is a deal breaker, and I've opted to stick with the bare Win32 style of controls. I did try to implement this myself, however. First I wanted to add accelerator support to the MsgBox. I decided to parse the string for ampersand hint character and manually draw the underline: ;Parse text for ampersand (&) to draw an underline Local $iAmpPos = StringInStr($Text, "&") If $iAmpPos > 0 Then $Text = StringReplace($Text, "&", "") Local $iTextSize = _StringSize($Text, $Fontsize, 700, 0, $Font) Local $iAccelChar = StringMid($Text, $iAmpPos, 1) Local $iAccelCharSize = _StringSize($iAccelChar, $Fontsize, 700, 0, $Font) Local $iAccelCharPre = StringLeft($Text, $iAmpPos - 1) Local $iAccelCharPreSize = _StringSize($iAccelCharPre, $Fontsize, 700, 0, $Font) Local $iAccelCharPixPos = _StringSize($iAccelChar, $Fontsize, 700, 0, $Font) Local $iLineStartX = $Width / 2 - $iTextSize[2] / 2 + $iAccelCharPreSize[2] + 1 Local $iLineEndX = $iLineStartX + $iAccelCharSize[2] - 2 Local $iLineY = $Height / 2 + $Fontsize / 2 + 1 Local $Pen_BTN_AccelUnderline = _GDIPlus_PenCreate($FrameColor, 1) _GDIPlus_GraphicsDrawLine($Button_Graphic1[0], $iLineStartX, $iLineY, $iLineEndX, $iLineY, $Pen_BTN_AccelUnderline) _GDIPlus_GraphicsDrawLine($Button_Graphic1[0], $iLineStartX, $iLineY, $iLineEndX, $iLineY, $Pen_BTN_AccelUnderline) EndIf It looked OK, for the most part (I did test it with other characters too, alignment is as best as it could be based on the reported character width/position calcualtion): This is shown permanently, however. I couldn't figure out how to show the the bitmap as an overlay on the existing one when I wanted (i.e. when ALT is held down), this GDI graphics work is all magic to me. Second, the desire for tabstops was blocked by the same thing. I couldn't figure out how to actually draw the tabstop based on your existing system, since it's all heavily nested in the hover code. The drawing part was fine, I just made a new pen for dotted outline; but actually getting it to draw on the right button on-demand. I'm hopeful that these features can be added one day by someone more skilled than I. Thanks.

Sorry for double post, but it's worthy of a notification to all subscribed. I found a solution to this but with one caveat - it only works when the script is compiled. GenerateConsoleCtrlEvent works, but the console needs to be "attached" first. Example below, all credits to rover 2k12. EDIT: It also doesn't work if it's run by SciTE/Wrapper "#AutoIt3Wrapper_Run_After="%out%"" directive... so it's a very last-resort thing. But still better than doing a "kill process" IMO. ;coded by rover 2k12 ;Ref: ;<a href='http://stackoverflow.com/questions/813086/can-i-send-a-ctrl-c-sigint-to-an-application-on-windows' class='bbc_url' title='External link' rel='nofollow external'>http://stackoverflow.com/questions/813086/can-i-send-a-ctrl-c-sigint-to-an-application-on-windows</a> #NoTrayIcon ;#AutoIt3Wrapper_Change2CUI=y If Not @Compiled Then Exit #include <windowsconstants.au3> Opt("MustDeclareVars", 1) Global $iCallback OnAutoItExitRegister("_Exit") Global Const $CTRL_BREAK_EVENT = 1 Global Const $CTRL_C_EVENT = 0 Global $fCloseFlag = False $iCallback = _InitConsole() _Main() Func _Main() GUICreate("", 600, 400) Local $iMemo = GUICtrlCreateEdit("", 2, 28, 596, 370, $WS_VSCROLL) GUICtrlSetLimit(-1, 1048576) Local $cCtrl_C = GUICtrlCreateButton("Ctrl-C", 2, 2, 120, 25) GUISetState() Local $iExitCode = Cmd("cmd.exe /c dir c:\ /s", $iMemo, $cCtrl_C) MsgBox(262144, "Exit Code", $iExitCode & @TAB & @TAB & @TAB) GUICtrlSetData($iMemo, "") $iExitCode = Cmd("ping.exe -t " & @IPAddress1, $iMemo, $cCtrl_C) MsgBox(262144, "Exit Code", $iExitCode & @TAB & @TAB & @TAB) ;Local $Archiv = @TempDir &amp; "\" &amp; @HOUR &amp; "_" &amp; @MIN &amp; "_" &amp; @SEC &amp; "_test.zip" ;GUICtrlSetData($iMemo, "") ;$iExitCode = Cmd(@ProgramFilesDir &amp; "\7-Zip\7z a -tzip "&amp;$Archiv&amp;" "&amp;@TempDir &amp; "\*.*", $iMemo, $cCtrl_C) ;MsgBox(262144, "Exit Code", $iExitCode&amp;@TAB&amp;@TAB&amp;@TAB) ;send ctrl-c to console process not launched by script GUICtrlSetData($iMemo, "") DllCall("kernel32.dll", "bool", "FreeConsole") ;free console so we can attach to another console process MsgBox(262144, "Open CMD prompt", "open a single cmd prompt with ping.exe -t yourIP, then continue") Local $aCon = WinList("[CLASS:ConsoleWindowClass]"), $PID For $i = 0 To $aCon[0][0] $PID = WinGetProcess($aCon[$i][1]) If $PID <> @AutoItPID Then DllCall("kernel32.dll", "bool", "AttachConsole", "dword", $PID) Next GUICtrlSetData($iMemo, "Ctrl-C to close existing console") While 1 Switch GUIGetMsg() Case -3 ExitLoop Case $cCtrl_C ;send ctrl-c to script and child process event handler, script event handler will block exit DllCall("kernel32.dll", "bool", "GenerateConsoleCtrlEvent", "dword", $CTRL_C_EVENT, "dword", 0) EndSwitch WEnd DllCall("kernel32.dll", "bool", "FreeConsole") Exit EndFunc ;==>_Main Func _Exit() DllCall("kernel32.dll", "bool", "FreeConsole") DllCall("Kernel32.dll", "bool", "SetConsoleCtrlHandler", "ptr", 0, "bool", 0) DllCallbackFree($iCallback) EndFunc ;==>_Exit Func Cmd($sCmd, $cEdit, $cBtn) Local $iPid = Run($sCmd, @ScriptDir, @SW_HIDE, 2) Local $h_Process = DllCall('kernel32.dll', 'ptr', 'OpenProcess', 'int', 0x400, 'int', 0, 'int', $iPid) Local $sData, $retval = -1 While 1 $sData = StdoutRead($iPid) If @error Then ExitLoop $sData = StringReplace($sData, @CR & @CR, @CR) If $sData Then GUICtrlSetData($cEdit, $sData & @CRLF, 1) #cs If $fCloseFlag Then ;continually send ctrl-c until child process exits (not all child processes will respond to Ctrl-C the first time) DllCall("kernel32.dll", "bool", "GenerateConsoleCtrlEvent", "dword", $CTRL_C_EVENT, "dword", 0) If ProcessExists($iPid) = 0 Then ExitLoop EndIf #ce Switch GUIGetMsg() Case -3 ;ExitLoop Case $cBtn ;send ctrl-c to script and child process event handler, script event handler will block exit DllCall("kernel32.dll", "bool", "GenerateConsoleCtrlEvent", "dword", $CTRL_C_EVENT, "dword", 0) EndSwitch WEnd $fCloseFlag = False If IsArray($h_Process) Then Local $i_ExitCode = DllCall('kernel32.dll', 'ptr', 'GetExitCodeProcess', 'ptr', $h_Process[0], 'int*', 0) If IsArray($i_ExitCode) Then $retval = $i_ExitCode[2] DllCall('kernel32.dll', 'ptr', 'CloseHandle', 'ptr', $h_Process[0]) EndIf Return $retval EndFunc ;==>Cmd Func _InitConsole() DllCall("kernel32.dll", "int", "AllocConsole") ;DllCall("kernel32.dll", "bool", "AttachConsole", "dword", -1) Local $hConsolehWnd = DllCall("Kernel32.dll", "hwnd", "GetConsoleWindow") If @error Then Return WinSetState($hConsolehWnd[0], "", @SW_HIDE) Local $iCB = DllCallbackRegister("_ConsoleEventHandler", "long", "dword") DllCall("Kernel32.dll", "bool", "SetConsoleCtrlHandler", "ptr", DllCallbackGetPtr($iCB), "bool", 1) Return $iCB EndFunc ;==>_InitConsole Func _ConsoleEventHandler($dwCtrlType) Switch $dwCtrlType Case $CTRL_C_EVENT, $CTRL_BREAK_EVENT $fCloseFlag = True ; set flag for checking if child process exists Return True ; exiting blocked, exit must be called from loop ;Return False ;exit normally EndSwitch Return False EndFunc ;==>_ConsoleEventHandler

Any luck? I've searched for the past hour, Writing Chr(3) to StdIn nor GenerateConsoleCtrlEvent work. Googling this, it seems to be a widespread "feature" of Windows - rather than an AutoIt bug. See here for more (albeit non-AutoIt) discussion on this.

evilertoaster, Thanks for the help - I really appreciate it. Well, In fact I don't mind that it may/probably not work in AutoIt, I think it a good platform for rapid development. The C# sample code you've provided is actually much more useful, since this makes it easier to write up a Snarl-specific extension without the reliance on a separate process running all the time. I myself am only a novice at C#, but you have indeed provided a solution I can use. Thanks a lot =) P.S. For those interested, another chap has started working on a Snarl Balloon-Notification-Capture program and detailed it in the Snarl group - working on x64 - it is python-based and doesn't use DLL hooking, however it is incomplete. I will continue to work on this method in particular with C# though out of personal interest. Thanks again evilertoaster, much appreciated

*Bump* I've tried everything I can think of, it's just beyond my ability. The source for the DLL and the old VB6 code is there, but all I am trying to do is get AutoIt to make the hook, and make a MsgBox when it gets a notification from it. But I just can't get them "talking", as soon as I can though I will easily figure the rest out on my own... Really hope someone can find the time to lend a hand with this so I can kiss their feet

Thanks evilertoaster, I'll check them out and see if I can figure any more out. Here's the SnarlTray extension in a ZIP archive: http://cid-e9fb2bf7954e2e2e.office.live.com/self.aspx/Public/SnarlTray.zip Note that it won't compile or anything, though, as it's just a fragment of the entire Snarl repository and thus has some missing includes. However, code that's specific to this DLL is all in there.

Sorry, I don't really have any problem with the Snral Tray API - at least, I have not gotten that far yet. The geOTraySpy DLL has nothing to do with Snarl really, I'm just trying to see if this x64 DLL will work at intercepting the WM_COPYDATA messages of the Balloon Tips. Only, I'm stuck with how to do it. My last post has a link to the source code of the DLL (C++). The AutoIt script loads the hook code already, I think. But I don't know how to actually get the DLL hook to "talk back" to my AutoIt script. Ignore anything "Snarl" right now... that's not the main concern. Sorry to have confused, I really do appreciate the help EDIT: Here is the source for the SnarlTray extension itself. Most of the code can be ignored, because all I really want to do right now in the AutoIt script is get a Messagebox/ConsoleWrite the result of a BalloonTip from the hook. So it might be easier seeing it in the VB6 example. http://cid-e9fb2bf7954e2e2e.office.live.com/browse.aspx/Public/SnarlTray EDIT2: Looking at the code, my guess is that I need to create a window with a specific classname so the hook knows where to forward data to. But I don't know how to do that. The GSSPY_DOWNLOAD registration is actually not needed, I didn't realize that the code was commented-out in the SnarlTray VB6 app.