LateArrival

To Mat Btw if I got this right do you take: 43 38 48 31 30 4e 34 4f 32 with 43 31 32 48 32 32 4F 31 31 or without?

I guess in my case I need an elephant with a machine gun! A lot of the low level stuff like handling windows, controls, trays, ini files - if you care for that - or hotkeys are not very accessible in WPF or are very counter-intuitive to work with.Do-able but a royal pain. On the other hand, wiring sophisticated GUIs together in AI is also doable but also a royal pain. I mean who wants to register WM_something to handle control events in 2013. So there is no happy medium as I see it. Enough people have build some of the 'missing' features in WPF over the years so rather than trying to turn AI into something it is not perhaps the best course of action is to invest time in building up the features one needs in C#/WPF (or similar). I could be wrong but attempting to do the opposite may be quite a huge task and there are always lots of people with varying needs and you can never keep everybody happy. To be honest it would be too much for me to presume what is right or not for AI since I am new here and I have very healthy respect for anybody who can produce a language and run it successfully over many years. Anyway wasn't poo poing your idea but I just come to think that AI is a pretty good script language to automate windows applications. That is it I think...The rest is just mismanaged or unrealistic expectations (on my part at least).

Forgive me for being somewhat critical but I struggle to see how shoehorning another language into autoit is a good idea. I would much prefer Autoit or AutoitObject to evolve to be a fully fledged OOP language rather than masquerade it to something that it is not. I love autoit for its directness and simplicity in achieving tasks that would otherwise take you a lot of time to get through in another language. At the same time my 10-20,000 lines of structured code (not anymore) can use the oop treatment. So I would ideally prefer for Autoit or AIO to evolve to provide better OOP plumbing (i.e. events etc.) stuff you find in C# and .NET (there you go I said it). If found myself building similar “frameworks” that look like this: #include 'System.au3' #include 'System.Collections.au3' #include 'System.ComponentModel.au3' #include 'System.Diagnostics.au3' #include 'System.Data.au3' #include 'System.Messaging.au3' #include 'System.Drawing.au3' #include 'System.IO.au3' #include 'System.Windows.au3' #include 'System.Windows.Automation.au3' #include 'System.Windows.Controls.au3' #include 'System.Windows.Forms.au3' #include 'System.Windows.Input.au3' You can guess what’s in there and what they are supposed to do but I say “frameworks” because in reality it’s a mickey mouse attempt to dress up win api or au3 functions so that they behave like .net. It worked for a while but before too long you run into all sort of other issues. Having been through this loop I really think it’s a waste of time. There is language that does this already. Its called C# and it runs on a framework that dos all this already and its called .NET and you can buy some thing like DevExpress or similar to sex it up. Autoit is still great. Just a few days ago it helped me sort through 150,000 images and save the day for a pretty major retailer all from code found in the help files. Thank you very much. I love Autoit but I am gonna have to give up trying to make it look and work like .NET J

Question to the authors of this UDF: Given some of the functionality being released in the more recent AU3 betas. Are there any plans to further enhance this UDF?

Cross-Posting from here:'?do=embed' frameborder='0' data-embedContent>> "Hi (probably replying to late to this but I just came across it whilst looking for something else) It is not a good idea to put your main loop inside a method. Basically the code will run inside the method and it doesn't get a chance to process your input. Here is an alternative approach (hope it helps)" #include 'AutoitObject.au3' #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> _AutoItObject_StartUp() #region Form Class ======================================== Func Form() Local $this = _AutoItObject_Class() ; field properties $this.AddProperty('Handle', $ELSCOPE_READONLY) $this.AddProperty('IsInitialised', $ELSCOPE_READONLY, False) ; get/set propeties $this.AddMethod('Visible', '___Form_Visible') ; methods $this.AddMethod('Load', '___Form_Load') ; destructors $this.AddDestructor('_Analista_Finalise') Return $this.Object EndFunc ;==>Form ;------------------------------------------------------- Func ___Form_Load($self, $iCaption = 'Form', $iLeft = Default, $iTop = Default, $iWidth = Default, $iHeight = Default, $iStyle = Default, $iStyleEx = Default) $self.Handle = String(GUICreate($iCaption, $iWidth, $iHeight, $iLeft, $iTop, $iStyle, $iStyleEx)) $self.IsInitialised = True EndFunc ;==>___Form_Load ;------------------------------------------------------- Func ___Form_Visible($self, $iVisible = Default) If Not $self.IsInitialised Then Return SetError(1) Switch @NumParams Case 1 ; get Return (BitAND(WinGetState(HWnd($self.Handle), ''), 2) = 1) ; 2 = Window is visible Case 2 ; set If Not IsBool($iVisible) Then Return SetError(2) Switch $iVisible Case True Return WinSetState(HWnd($self.Handle), '', @SW_SHOW) Case False Return WinSetState(HWnd($self.Handle), '', @SW_HIDE) EndSwitch EndSwitch EndFunc ;==>___Form_Visible ;------------------------------------------------------- Func ___Form_Finalise($self) If Not $self.IsInitialised Then Return SetError(1) GUIDelete(HWnd($self.Handle)) EndFunc ;==>___Form_Finalise #endregion Form Class ======================================== ; Main Program Global $C_Analista = Form() ;~ $C_Analista.Load('Analista', 10, 10, 224, 438, BitOR($WS_SYSMENU, $WS_BORDER, $WS_CAPTION)) $C_Analista.Load('Analista') $C_Analista.Visible = True While 1 $nMsg = GUIGetMsg() ConsoleWrite('!...Tela travada' & @CRLF) Switch $nMsg Case $GUI_EVENT_CLOSE $C_Analista.Visible = False $C_Analista = 0 _AutoItObject_Shutdown() Exit EndSwitch WEnd

Hi (probably replying to late to this but I just came across it whilst looking for something else) It is not a good idea to put your main loop inside a method. Basically the code will run inside the method and it doesn't get a chance to process your input. Here is an alternative approach (hope it helps): #include 'AutoitObject.au3' #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> _AutoItObject_StartUp() #region Form Class ======================================== Func Form() Local $this = _AutoItObject_Class() ; field properties $this.AddProperty('Handle', $ELSCOPE_READONLY) $this.AddProperty('IsInitialised', $ELSCOPE_READONLY, False) ; get/set propeties $this.AddMethod('Visible', '___Form_Visible') ; methods $this.AddMethod('Load', '___Form_Load') ; destructors $this.AddDestructor('_Analista_Finalise') Return $this.Object EndFunc ;==>Form ;------------------------------------------------------- Func ___Form_Load($self, $iCaption = 'Form', $iLeft = Default, $iTop = Default, $iWidth = Default, $iHeight = Default, $iStyle = Default, $iStyleEx = Default) $self.Handle = String(GUICreate($iCaption, $iWidth, $iHeight, $iLeft, $iTop, $iStyle, $iStyleEx)) $self.IsInitialised = True EndFunc ;==>___Form_Load ;------------------------------------------------------- Func ___Form_Visible($self, $iVisible = Default) If Not $self.IsInitialised Then Return SetError(1) Switch @NumParams Case 1 ; get Return (BitAND(WinGetState(HWnd($self.Handle), ''), 2) = 1) ; 2 = Window is visible Case 2 ; set If Not IsBool($iVisible) Then Return SetError(2) Switch $iVisible Case True Return WinSetState(HWnd($self.Handle), '', @SW_SHOW) Case False Return WinSetState(HWnd($self.Handle), '', @SW_HIDE) EndSwitch EndSwitch EndFunc ;==>___Form_Visible ;------------------------------------------------------- Func ___Form_Finalise($self) If Not $self.IsInitialised Then Return SetError(1) GUIDelete(HWnd($self.Handle)) EndFunc ;==>___Form_Finalise #endregion Form Class ======================================== ; Main Program Global $C_Analista = Form() $C_Analista.Load('Analista', 10, 10, 224, 438, BitOR($WS_SYSMENU, $WS_BORDER, $WS_CAPTION)) $C_Analista.Visible = True While 1 $nMsg = GUIGetMsg() ConsoleWrite('!...Tela travada' & @CRLF) Switch $nMsg Case $GUI_EVENT_CLOSE $C_Analista.Visible = False $C_Analista = 0 _AutoItObject_Shutdown() Exit EndSwitch WEnd

Tested in Vista and it works very well. Really good work. Line 292 Func _InputEvent_SetPollInterval($millisecs = 10) ;-> none $_InputEvent_PollInterval = $_InputEvent_PollInterval EndFunc Although 10msec I think is about right anyway. The example is quite "busy", It might be worth making the mousemove event optional on the debug list. Only because there are some move events generated it is drowning all other event types making it difficult to test. I was also looking to implement derivative events like doubleclick (i.e. by tracking tick differences between two mousedowns + cancelling a mouseup event when detected a double clieck and finally the distance between the first and the second click). Although I cannot help feeling that this would much faster within the the DLL. Aside from that I was thinking that I could modify __InputEvent_InvokeEvent to include support to registering objects and methods to generate pseudo-events that will call up event handling methods. I got something along these line working with the SetOnHover UDF and Mailslot to queue the raised events but using this udf processing keys and more mouse events from one single source would be much better. I need to find some time to do a test on this.

Hi, I tried to test your script in an XP machine (will try Vista later - still a 32bit machine) but I am getting and error after which your sample terminates. "The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL32.dll" PS also your example_full.au3 has this line #include <D:AutoItInputEventversions1.1InputEvent.au3>