WinkleDoodle

Anyone have free time to start an official SAPI5 UDF? http://msdn.microsoft.com/en-us/library/ms723627%28v=vs.85%29.aspx [Edit] Rephrased

Thanks for the sneak preview?, but unfortunely this uber complex program of yours will fail really hard unless you get feedback from others, but that's up to you. I know this first hand.

Thanks, Lars and wraithdu Certainly there's more elagant fixes around.. but I used this code instead to have WinXP and Win7+ support. Global $tagREBARBANDINFO Switch @OSVersion Case "WIN_2003", "WIN_XP", "WIN_XPe", "WIN_2000" $tagREBARBANDINFO = "uint cbSize;uint fMask;uint fStyle;dword clrFore;dword clrBack;ptr lpText;uint cch;" & _ "int iImage;hwnd hwndChild;uint cxMinChild;uint cyMinChild;uint cx;handle hbmBack;uint wID;uint cyChild;uint cyMaxChild;" & _ "uint cyIntegral;uint cxIdeal;lparam lParam;uint cxHeader" Case Else $tagREBARBANDINFO = "uint cbSize;uint fMask;uint fStyle;dword clrFore;dword clrBack;ptr lpText;uint cch;" & _ "int iImage;hwnd hwndChild;uint cxMinChild;uint cyMinChild;uint cx;handle hbmBack;uint wID;uint cyChild;uint cyMaxChild;" & _ "uint cyIntegral;uint cxIdeal;lparam lParam;uint cxHeader;" & $tagRECT & ";uint uChevronState" EndSwitch

Is there a beta or a update in the near future? Kodo is awesome but for one thing it feels incomplete, I always end up editing the output by hand which takes too much time. Often I find that some styles, extended styles, and options are disabled, missing, or do nothing when clicked on. for example the toolbar control has tons of options missing or do nothing when clicked on. Even so it's very good for a mockup GUI or a starting point. Here's some bugs that have been bugging me Copy and paste a control and the new control's position will be misaligned with the original control, drag it right next to the control and it will not match up in alignment. Moving existing controls inside a group control causes the new controls to be hidden behind the group controls.. and/or doesn not aknowledge the controls are even their and thew controls position remain unchanged if the group position is changed. Resizing a label and then changing the text values of the label to anything (empty for example) causes the label to be resized I'm not sure the exact procedures to replicate these bugs but they are there, and happens numerous times.

From the help file for _GUICtrlRebar_AddToolBarBand Top is AutoIt v3.3.6.1 Bottom is AutoIt v3.3.8.0 #include <GuiConstantsEx.au3> #include <GuiReBar.au3> #include <GuiToolBar.au3> #include <WindowsConstants.au3> #include <Constants.au3> Opt("MustDeclareVars", 1) $Debug_RB = False _Main() Func _Main() Local $hgui, $btnExit, $hToolbar, $hReBar, $hInput Local Enum $idNew = 1000, $idOpen, $idSave, $idHelp $hgui = GUICreate("Rebar", 400, 396, -1, -1, BitOR($WS_MINIMIZEBOX, $WS_CAPTION, $WS_POPUP, $WS_SYSMENU, $WS_MAXIMIZEBOX)) ; create the rebar control $hReBar = _GUICtrlReBar_Create($hgui, BitOR($CCS_TOP, $WS_BORDER, $RBS_VARHEIGHT, $RBS_AUTOSIZE, $RBS_BANDBORDERS)) ; create a toolbar to put in the rebar $hToolbar = _GUICtrlToolBar_Create($hgui, BitOR($TBSTYLE_FLAT, $CCS_NORESIZE, $CCS_NOPARENTALIGN)) ; Add standard system bitmaps Switch _GUICtrlToolbar_GetBitmapFlags($hToolbar) Case 0 _GUICtrlToolbar_AddBitmap($hToolbar, 1, -1, $IDB_STD_SMALL_COLOR) Case 2 _GUICtrlToolbar_AddBitmap($hToolbar, 1, -1, $IDB_STD_LARGE_COLOR) EndSwitch ; Add buttons _GUICtrlToolbar_AddButton($hToolbar, $idNew, $STD_FILENEW) _GUICtrlToolbar_AddButton($hToolbar, $idOpen, $STD_FILEOPEN) _GUICtrlToolbar_AddButton($hToolbar, $idSave, $STD_FILESAVE) _GUICtrlToolbar_AddButtonSep($hToolbar) _GUICtrlToolbar_AddButton($hToolbar, $idHelp, $STD_HELP) ; create a input box to put in the rebar $hInput = GUICtrlCreateInput("Input control", 0, 0, 120, 20) ;add band containing the control _GUICtrlReBar_AddBand($hReBar, GUICtrlGetHandle($hInput), 120, 200, "Name:") ; add band containing the control to begining of rebar _GUICtrlReBar_AddToolBarBand($hReBar, $hToolbar, "", 0) $btnExit = GUICtrlCreateButton("Exit", 150, 360, 100, 25) GUISetState(@SW_SHOW) While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE, $btnExit Exit EndSwitch WEnd EndFunc ;==>_Main

Actually, I think his inquiry was more in line with: http://www.autoitscript.com/forum/forum-2/announcement-13-forum-rules/ Do not discuss any of the following: SPAM tools including instant messenger or forum auto-posters. This includes forum or site auto-login methods.

Use RegNotifyChangeKeyValue http://msdn.microsoft.com/en-us/library/windows/desktop/ms724892%28v=VS.85%29.aspx I think theres examples on the forum, search. [Edit] If you wanted software to do it for you then you are on the wrong section of the forum and a moderator will move this topic to the appropriate section, have a very nice day!

Yes, a rant, precisely. In my defense, Perhaps another long time postal AutoIt user has found a workaround, perhaps not, it was worth a shot.

I should have noted that I am using DirGetSize with the advanced parameters, which returns an array of Size ,Files count, Dirs Count. (not that it really matters)

Howdy, DirGetSize causes my teeth to grind in sync with the grinding noises coming from my hard drive. Seriously though in explorer I right click and that information appears almost instantaneously, or gathers information relatively fast without much grinding. I hope explorer just caches this information and the AutoIt devs feel asleep for this function because it's absolutely, terribly, ridiculously, ludicrously slow and going through the docs, there's no way to tell how many birthdays I will have celebrated until it decides it's done raping my hard drive. Anways... What does explorer do differently, and what can I use that doesn't make me want to find a new hobby/career/blow my brains out while waiting for it to finish.

Once upon a time a script got so large that it had to be organize into several smaller files. happy ever after?, well no, this resulted in the tragic death of my "debuging" function. Func _Debug($sData, $line=@ScriptLineNumber, $Ext=@extended, $Err=@error, $name=@ScriptName) ConsoleWrite('File: ' $name & ' Line ('&$line&') => '& $sData) Return SetError($Err, $Ext, 0) EndFunc So I have Main.au3 Script1.au3 Script2.au3 Script3.au3 etc.. _Debug is called from somewhere in Script2.au3 which was included in Main.au3 and Main.au3 was run from scite Console: File: Main.au3 Line (202) => This Function: Suffered from serious head blah blah blah.. The problem.. Main.au3 is only 56 lines @ScriptLineNumber becomes meaningless if I don't know which file it's referring to. @Scriptname is perfect for what it is, no need to change, etc. but for debugging it's practically useless... , do I need to practice do mnemonic exorcises to debug my shitty, horribly written code? Why can't we also have a @Whichfuckingfileisautoitreadingatthispointintime [Edit] I changed the title of the topic so I won't get a single reply ranting how stupid the title of my topic is.. one can hope. [Edit #2] I suppose it's a bit naive to assume one even reads the title of this topic...

Looks like it was fixed in the beta 3.3.7.x sometime ago. The 9 error is still undocumented... Also not documented: the separator must be a single character. @CRLF is no good. :|

Yes, but not everybody reads past "Warning:.."

@Bowmore That's precisely what I was hinting at, albeit more eloquently put. I've successfully updated a project of mine using this method. there's with one caveat though. Any long looping routines inside a WM_COMMAND message can deadlock the whole WM_COMMAND message, which in worse case scenario leads to application freezing, leaving one to wait till the routine finishes or killing the process. But... of course, with GUICreateDummy() there's a nifty little work around. You'll need GUIOnEvent(), (I don't think this is possible with GUIGetMsg()..). #include <ButtonConstants.au3> #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> Global $hGUI, $edtData, $btnStart, $btnClose, $lbStatus, $dummyCallBlockingFunction ; this variable is checked inside our "BlockingFunction" ; if it is false then the routine stops Global $fRUNNING = False _Example_GUIOnEvent() Func _Example_GUIOnEvent() ; OnEventMode because it's not possible to use GUIGetMsg() when a function is Opt("GUIOnEventMode", 1) $hGUI = GUICreate("WM_SYSCOMMAND/WM_COMMAND Example", 300, 141, 192, 204, BitOR($WS_THICKFRAME, $gui_ss_default_gui)) $edtData = GUICtrlCreateEdit("", 8, 16, 290, 57) $btnStart = GUICtrlCreateButton("Start", 0, 88, 75, 25) $btnClose = GUICtrlCreateButton("Close", 80, 88, 75, 25) $lbStatus = GUICtrlCreateLabel("Ready", 0, 120, 196, 17, $SS_SUNKEN) $dummyCallBlockingFunction = GUICtrlCreateDummy() ; All "BlockingFunctions" e.g. functions that have long looping routines should have ; a dummy control to pass the burden to this will allow other message to be processed ; we don't need to set GUICtrlOnEvent for other controls because they will by processed ; by WM_COMMAND and WM_SYSCOMMAND GUICtrlSetOnEvent($dummyCallBlockingFunction, "BlockingFunction") ; handles all GUICtrl*Create and _GUICtrl*Create events GUIRegisterMsg($WM_COMMAND, "WM_COMMAND") ; handles GUI_EVENT_CLOSE, etc events GUIRegisterMsg($WM_SYSCOMMAND, "WM_SYSCOMMAND") GUISetState(@SW_SHOW) While 1 Sleep(100) WEnd EndFunc Func Close() GUICtrlSetData($edtData, "Shutting down..." &@CRLF) Sleep(1000) Exit EndFunc Func BlockingFunction() $fRUNNING = True GUICtrlSetData($btnStart, "Stop") GUICtrlSetData($lbStatus, "Started!" &@lf) GUICtrlSetData($edtData, @HOUR &":"& @MIN &":"& @SEC & " Inializing test.." &@CRLF) While 1 If $fRUNNING = False Then ExitLoop GUICtrlSetData($edtData, @HOUR &":"& @MIN &":"& @SEC & " Running test: Quantum spacetime" &@CRLF) Sleep(1000) GUICtrlSetData($edtData, @HOUR &":"& @MIN &":"& @SEC & " Running test: Splitting atoms" &@CRLF) Sleep(100) WEnd GUICtrlSetData($edtData, @HOUR &":"& @MIN &":"& @SEC & " Testing aborted by user" &@CRLF) GUICtrlSetData($lbStatus, "Stopped!" &@lf) $fRUNNING = False GUICtrlSetData($btnStart ,"Start") EndFunc Func WM_SYSCOMMAND($hWnd, $iMsg, $iwParam, $ilParam) Local $hWndFrom, $iIDFrom, $iCode #forceref $hWnd, $iMsg, $iwParam, $ilParam, $hWndFrom, $iIDFrom, $iCode $hWndFrom = $ilParam $iIDFrom = BitAND($iwParam, 0xFFFF) ; Low Word $iCode = BitShift($iwParam, 16) ; Hi Word Switch $iwParam Case 0xF060 ;SC_CLOSE ConsoleWrite("!Close window" & @LF) Close() Case 0xF120 ;SC_RESTORE ConsoleWrite("!Restore window" & @LF) Case 0xF020 ;SC_MAXIMIZE ConsoleWrite("!Maximize window" & @LF) EndSwitch Return $GUI_RUNDEFMSG ; Only workout clicking on the button EndFunc ;==>MY_SYS_COMMAND Func WM_COMMAND($hWnd, $iMsg, $iwParam, $ilParam) Local $hWndFrom, $iIDFrom, $iCode #forceref $hWnd, $iMsg, $iwParam, $ilParam, $hWndFrom, $iIDFrom, $iCode $hWndFrom = $ilParam $iIDFrom = BitAND($iwParam, 0xFFFF) ; Low Word $iCode = BitShift($iwParam, 16) ; Hi Word ; $hWndFrom is equal to @GUI_CtrlHandle ; $iIDFrom is equal to @GUI_CtrlId Switch $iIDFrom Case $btnStart ; "Blocking functions" need to be passed onto a dummy control ; so that we can process other messages If Not $fRUNNING Then GUICtrlSendToDummy($dummyCallBlockingFunction, 1) Else $fRUNNING = False EndIf Case $btnClose ; Non blocking functions don't need a dummy control Close() EndSwitch Return $GUI_RUNDEFMSG EndFunc

This is really cool.. now I won't have to cram *everything* in my main loop any more, functions are not blocking GUI messages e.g. #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> GUIRegisterMsg($WM_COMMAND, "MY_WM_COMMAND") GUIRegisterMsg($WM_SYSCOMMAND, "MY_SYS_COMMAND") GUIRegisterMsg($WM_HSCROLL, "WM_HVSCROLL") $GUI = GUICreate("Test GUI", 200, 200, -1, -1, BitOR($WS_THICKFRAME, $gui_ss_default_gui)) $Button = GUICtrlCreateButton("Test", 20, 20) $Button2 = GUICtrlCreateButton(" Another Test ", 20, 100) $Slider = GUICtrlCreateSlider(20, 60, 150) $hSlider = GUICtrlGetHandle($Slider) GUISetState() Global $iStopTest = 0 _Test() While 1 Sleep(100) WEnd Func _Test() While 1 If $iStopTest Then ConsoleWrite('_test function stopped!' &@lf) ExitLoop EndIf Sleep(1000) ConsoleWrite(@HOUR&@MIN&@SEC& " working..." &@lf) WEnd EndFunc Func MY_SYS_COMMAND($hWnd, $msg, $wParam, $lParam) Local $nNotifyCode = BitShift($wParam, 16) Local $nID = BitAND($wParam, 0x0000FFFF) Local $hCtrl = $lParam Switch $wParam Case 0xf060 ConsoleWrite("!Exit pressed" & @LF) Exit Case 0xF120 ConsoleWrite("!Restore window" & @LF) Case 0xF020 ConsoleWrite("!Minimize Window" & @LF) EndSwitch Return $GUI_RUNDEFMSG ; Only workout clicking on the button EndFunc ;==>MY_SYS_COMMAND Func MY_WM_COMMAND($hWnd, $msg, $wParam, $lParam) Local $nNotifyCode = BitShift($wParam, 16) Local $nID = BitAND($wParam, 0x0000FFFF) Local $hCtrl = $lParam Switch $nID Case $Button MsgBox(0, "", "You pressed the button marked TEST, stopping '_Test' function") $iStopTest = 1 Case $Button2 MsgBox(0, "", "You pressed the button marked 'Another Test'") EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>MY_WM_COMMAND Func WM_HVSCROLL($hWnd, $iMsg, $wParam, $lParam) #forceref $hWnd, $iMsg, $wParam, $lParam Switch $iMsg Case $WM_HSCROLL Switch $lParam Case $hSlider ConsoleWrite("+Slider moved to: " & GUICtrlRead($Slider) & @LF) EndSwitch Case $WM_VSCROLL EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>WM_HVSCROLL

Besides usual case of UPX, I believe the second reason for the virus flag is because of "FileInstall" function.

Maybe they are cooking something behind the scenes. ie. 3.x mostly been getting bug fixes, hope for 2012 (10 years of AutoIt3) to change all that.

Compared to what? How much "heft" does statically linking msvr library actually add to AutoIt?