Valik Posted July 1, 2009 Posted July 1, 2009 The only real oddity in my code is that I [need to] switch to MessageLoop Mode on entry to the GUI, and switch back to Event Mode (immediately after GUIDelete). Is there anything wrong with doing this?Not if it's written correctly. Perhaps you are not using an explicit HWND in your GUI function calls or you are not using GUISwitch() to update the internal "current" window. I think your question belongs more in support than here because I don't think it's an AutoIt issue (outside of poor design).
vdo Posted July 1, 2009 Posted July 1, 2009 Not if it's written correctly. Perhaps you are not using an explicit HWND in your GUI function calls or you are not using GUISwitch() to update the internal "current" window. I think your question belongs more in support than here because I don't think it's an AutoIt issue (outside of poor design).Thanks anyway.You're right, it's not related to this thread anymore. [center][font="Tahoma"]What are all those clowns following me for?[/font][/center]
wraithdu Posted July 9, 2009 Posted July 9, 2009 This - Added #764: Return Pid on ProcessWait() and handle on WinWait(), WinWaitActive, WinActivate(), WinActive(), WinMove() when successful. should probably be added to the list of script-breaking changes. Any previous 'If Win*() = 1' test will now fail.
Administrators Jon Posted July 9, 2009 Author Administrators Posted July 9, 2009 This - Added #764: Return Pid on ProcessWait() and handle on WinWait(), WinWaitActive, WinActivate(), WinActive(), WinMove() when successful. should probably be added to the list of script-breaking changes. Any previous 'If Win*() = 1' test will now fail. Oh, I'd not seen that. Yes, that's nasty. It should probably return 1 and return the PID in @extended. Deployment Blog:Â https://www.autoitconsulting.com/site/blog/ SCCM SDK Programming:Â https://www.autoitconsulting.com/site/sccm-sdk/
wraithdu Posted July 9, 2009 Posted July 9, 2009 (edited) Same thing for the Win*() functions too, return 1 as before and return the hWnd in @extended. Thanks! Edited July 9, 2009 by wraithdu
Valik Posted July 9, 2009 Posted July 9, 2009 This - Added #764: Return Pid on ProcessWait() and handle on WinWait(), WinWaitActive, WinActivate(), WinActive(), WinMove() when successful. should probably be added to the list of script-breaking changes. Any previous 'If Win*() = 1' test will now fail. If Win() = 1 is bad code. I can document script-breaking changes, however, I'm not really sure documenting breaking bad code was the intent of the page. Never test a boolean result with an explicit value. It makes for unclean code and it makes for code that is needlessly hard-coded with a value that is irrelevant. Oh, I'd not seen that. Yes, that's nasty. It should probably return 1 and return the PID in @extended. No way. It breaks bad code. Properly written code will go unaffected. New code will have new, sensible features to use. Besides, it doesn't solve the issue for any of the other functions which can't return an HWND via @extended. I'll document it - begrudgingly - but otherwise to people who's scripts were broken: Learn not to overwrite your code.
wraithdu Posted July 9, 2009 Posted July 9, 2009 Is it bad code to test a documented return value? Either way, it's not for one of my scripts, but I thought worth mentioning.
Administrators Jon Posted July 9, 2009 Author Administrators Posted July 9, 2009 No way. It breaks bad code. Properly written code will go unaffected. New code will have new, sensible features to use. Besides, it doesn't solve the issue for any of the other functions which can't return an HWND via @extended. I'll document it - begrudgingly - but otherwise to people who's scripts were broken: Learn not to overwrite your code.It's not bad code. It's a documented return value. It would be bad code if it wasn't documented and the user assumed it was 1. I'd say the majority of people (non programmers at least) would be checking for 1 (if they check at all) and anyone who uses C or something would be doing it the other way.At no point have we said "for functions that return 1 to indicate success you should test like this because we might change the value"... Deployment Blog:Â https://www.autoitconsulting.com/site/blog/ SCCM SDK Programming:Â https://www.autoitconsulting.com/site/sccm-sdk/
Valik Posted July 9, 2009 Posted July 9, 2009 It's not bad code. It's a documented return value. It would be bad code if it wasn't documented and the user assumed it was 1. I'd say the majority of people (non programmers at least) would be checking for 1 (if they check at all) and anyone who uses C or something would be doing it the other way.Why can't they test <> 0 or use Not <Function>? Why do they feel the need to test an explicit value at all? It incurs a performance penalty with unnecessary operations and tests explicitly against a value that is irrelevant. There are many ways of doing documented things in bad ways. So I do assert, despite it being documented, that it is bad code.At no point have we said "for functions that return 1 to indicate success you should test like this because we might change the value"...At no point have we said return values wouldn't change even if they are documented. This holds true when a more logical return value is contrived that improves a function.As mentioned, I will document the script breaking changes but I think it is dumb to gimp sensible behavior just because it breaks scripts of questionable quality.
Valik Posted July 9, 2009 Posted July 9, 2009 I updated the Script Breaking Changes page for the next beta.
PartyPooper Posted July 31, 2009 Posted July 31, 2009 Just curious if a date been set for the release of Beta 3.3.1.2 yet (or even just an indication in the number of days/weeks left in the milestone)? Thanks
Valik Posted July 31, 2009 Posted July 31, 2009 AutoIt is not currently in any shape for public consumption.
quacky Posted August 2, 2009 Posted August 2, 2009 3.3.1.0 (20th May, 2009) (Beta)AutoIt:- Added #757: Set defaults for MouseClick()'s x/y parameters.- Added #764: Return Pid on ProcessWait() and handle on WinWait(), WinWaitActive, WinActivate(), WinActive(), WinMove() when successful.- Added #414: better handling of OnAutoItStart/OnAutoItExit, now #OnAutoItStartRegister, OnAutoItExitRegister() and OnAutoItExitUnRegister().- Added: Better handling of AdlibEnable/AdlibDisable, now AdlibRegister(), AdlibUnRegister() and AdlibDisable().- Added #351: Reverse PixelSearch().Was a "Reverse PixelSearch()" really added? I can't find it in the Beta documentation (other than being listed in the changelog, the same as in this post).
bo8ster Posted September 29, 2009 Posted September 29, 2009 ... A better question is, when will the next beta be? When it's done AKA when I say "Jon, release this bitch" because I'm still not at all happy with the current state of AutoIt and have much work to do to get it into shape.Any updates? Post your code because code says more then your words can. SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y. Use Opt("MustDeclareVars", 1)[topic="84960"]Brett F's Learning To Script with AutoIt V3[/topic][topic="21048"]Valuater's AutoIt 1-2-3, Class... is now in Session[/topic]Contribution: [topic="87994"]Get SVN Rev Number[/topic], [topic="93527"]Control Handle under mouse[/topic], [topic="91966"]A Presentation using AutoIt[/topic], [topic="112756"]Log ConsoleWrite output in Scite[/topic]
Valik Posted September 30, 2009 Posted September 30, 2009 Clearly not or there would have been an... update. Fascinating how that works!
Valik Posted October 14, 2009 Posted October 14, 2009 (edited) AutoIt v3.3.1.2 (Beta) Released:AutoIt:- Added: new type to DllCall and DllStruct to avoid confusion with MSDN description. That avoid specially X64 errors.- Added #967: Ftp via proxy now works for the Inet functions.- Added #351: PixelSearch() now supports both right-to-left and bottom-to-top searches.- Changed: AutoIt exit callback functions are called in reverse order of registration.- Changed: AdlibUnRegister() now returns the count of remaining Adlib functions that are registered.- Changed: AdlibUnRegister()'s function argument is now optional. Called without arguments causes the last registered function to be unregistered.- Changed: @YDAY now returns values in the range 001 - 366 instead of 1 - 366. This makes it more consistent with other languages. THIS IS A SCRIPT BREAKING CHANGE.- Changed #1080: InetGet background downloads now return immediately instead of connecting to the remote host first.- Changed #1137: RegEnumKey() and RegEnumVal() now correctly return an empty string on failure instead of an error message string.- Changed: PixelChecksum() can calculate checksums from right-to-left and bottom-to-top.- Fixed #1013: MDI childs doesn't adjust to parent windows client area. (Thanks monoceres)- Fixed: Crash due to unregistering an Adlib while an Adlib was firing.- Fixed: Adlib functions no longer dominate when more than one are registered.- Fixed #1005: TraySetClick(64) = hovering. (Thanks timsky, MrCreatoR)- Fixed #1049: InetRead() inserted arbitrary null terminators.- Fixed: ClipPut("") not emptying.- Fixed #1068: Binary to Int. (Thanks amel27)- Fixed #1087: Checkbox or Radio repainting when mouse hovering.- Fixed: Bad painting on double GUICtrlSetPos() for label.- Fixed #1094: Send("{LSHIFT UP}") stay down. (Thanks nick.weltha)- Fixed #1074: Inputbox() positionning on multi monitor. (Thanks partypooper)- Fixed #1079: GUISetFont(), GUICrlSetFont() doc related to issue #918- Fixed #1105: disable colored Multiline button not properly displayed.- Fixed #1077: GUICtrlSetBkColor() bad recoloring. (Thanks Mulder)- Fixed #1116: GUICtrlCreateGraphic don't follow ResizeMode.- Fixed #1102: Better documentation of the StringInStr() count parameter.- Fixed #1161: Removed all documentation references to ColorMode.- Fixed #1156: AutoItSetOption()/Opt() now set @error instead of generating a fatal error with invalid input.- Fixed #1093: StringFormat() beta regression for non latin chars- Fixed: Comparing pointers now works correctly.AutoItX:- Removed: ColorMode option removed from AutoItSetOption().Aut2Exe:- Fixed #1036: Inet-related functions now work in compiled scripts.Au3Info:- Removed: ColorMode BGR option removed since AutoIt no longer supports the option to use BGR mode.Others:- Added #1050: TextPad v5 syntax files installation. (Thanks poebel)UDFs:- Added: GuiRichEdit and functions- Added: _WinAPI_GetGuiResources()- Added #981: _WinAPI_WideCharToMultiByte(), _WinAPI_MultiByteToWideChar() support IN/OUT as "strings"- Added #1157: Encryption functions in Crypt.au3.- Added #1128: _WinAPI_PathFindOnPath() in WinAPI.au3.- Fixed #999: _GUICtrlTreeView_SetFocused documentation- Fixed #1016: _WordDocSaveAs() Doc for error handling. (Thanks Volly)- Fixed: Sound positioning in case of VBR Format Sound. (Thanks Melba23, RazerM)- Fixed #1031: _Clipboard_SetData() fix. (Thanks Ascend4nt)- Fixed #1040: _ScreenCapture_Capture() leak memory. (Thanks rover)- Fixed #1026: _Gdiplus_BitmapCreate*() doc examples. (Thanks wraithdu)- Fixed #1092: _Timer_...() datatype for X64. (Thanks Ascend4nt)- Fixed #1059: Incorrect error handling in _FileListToArray(). (Thanks Spiff59)- Fixed #1101: _NowTime(), _NowDate() Doc. (Thanks danullman)- Fixed: _WinAPI_GetWindowLong(), _WinAPI_SetWindowLong support X64.- Fixed #1111: Bad grammar in comments for _DateAdd().- Fixed #1155: _WinAPI_CreateSolidBitmap() updated (Thanks Yashied)- Fixed: all includes use Unicode for Dllcall and SendMessage- Fixed: _WinAPI_Get/SetWindowLong under X64- Fixed: UDF library now uses #include "" instead of #include <>.- Fixed #1033: UDF library now has better and more consistent error handling when DllCall() is used.- Changed: _SQLite 3.6.14.2 -> 3.6.18- Changed: _InetGetSource() now uses InetRead().- Removed #1112: __WinAPI_Check() has been removed as have all calls to it.AutoIt 3.3.1.2 contains the following script breaking changes:Some of the following features are deprecated. Deprecated features are no longer documented but continue to work. Deprecated features will be removed after version 3.3.2.0. It is strongly recommended that scripts relying on deprecated features be updated to work with the new behavior. Some features have already been removed and will be noted as such.AutoIt:ShellExecute() and ShellExecuteWait() no longer use the "open" verb by default. See the remarks section for those functions for more details.The return value of InetGet() has changed. It is important to read and understand the changes because it is possible to leak resources if InetGet() is used incorrectly.InetGet("abort"), @InetGetActive and @InetGetBytesRead are now deprecated. The following list shows the new functions used to access the old behavior:InetGet("abort") - Calling the new InetClose() function with a handle returned from InetGet() will abort a download.@InetGetActive - Calling the new InetGetInfo() function with no parameters returns a count of active downloads.@InetGetBytesRead - Calling the new InetGetInfo() function with a handle returned from InetGet()will return the bytes read (and more) for a download.The FtpBinaryMode option set with AutoItSetOption() has been removed. Now InetGet() takes a flag to specify the transfer mode.The URLDownloadToFile() alias for InetGet() has been removed.AdlibEnable() and AdlibDisable() are deprecated. See the new functions AdlibRegister() and AdlibUnRegister().OnAutoItStart() is deprecated. See the new pre-processor statement #OnAutoItStartRegister.OnAutoItExit() is deprecated. See the new functions OnAutoItExitRegister() and OnAutoItExitUnregister().The AutoItSetOption() option OnExitFunc has been removed. See the new functions OnAutoItExitRegister() and OnAutoItExitUnregister().GUICreate() with $WS_EX_MDICHILD has been fixed to be relative to client area as documented.ProcessWait() now returns a PID instead of 1 on success.WinWait(), WinWaitActive(), WinActivate(), WinActive() and WinMove() now return an HWND instead of 1 on succes.The macro @YDAY now uses the range 001 - 366 instead of 1 - 366. This makes the macro more consistent with other languages (like C/C++) and more consistent with all other date related macros which return strings with leading 0s to pad the length.RegEnumKey() and RegEnumVal() now return an empty string instead of an error message.UDFs:The last optional parameter for _StringBetween() has been removed._StringAddThousandsSep() has been removed. There are too many opinions on what this function should do and too many revisions of this function have been made._SQLite_SaveMode() has been renamed to _SQLite_SafeMode().This release is not digitally signed.Discuss the beta here.Report issues here.Download here. Edited October 14, 2009 by Valik
wraithdu Posted October 15, 2009 Posted October 15, 2009 The new Crypt UDF is cool. But I already noticed a few problems. First, the _Crypt_EncryptFile() example has inconsistent strings that will make it not work. The combo box has strings like "AES 192" and the Case statement has strings like "AES_192". Additionally something is wrong in Scite. The "special" category is no longer purple (#Region, #AutoIt3Wrapper statements, etc). Lastly (so far) GuiCtrlCreateCombo controls height parameter seems to be the height of the edit/static control PLUS the height of the dropdown. So if you only specify 25 (like the _Crypt_EncryptFile example) you don't get a dropdown at all, just the edit control. You have to specify the height as the total height of the edit/static plus the dropdown. This also means you can't control the height of the edit/static portion of the combo control. I'll post any other oddities I find.
wraithdu Posted October 15, 2009 Posted October 15, 2009 (edited) It seems like some kind of line or character limit has been reached in the au3.keywords.properties file. If I delete a few lines from anywhere, I get some of my symbols back. With the current version, everything after and including the au3.keywords.special blocks are not colored. Edited October 15, 2009 by wraithdu
wraithdu Posted October 15, 2009 Posted October 15, 2009 (edited) Ok, I worked around the keywords problem by splitting the keywords into two files: au3.keywords.properties and au3.keywords2.properties, then adding the extra import line in au3.properties. I'm guessing there's a character limit somewhere ~60000. Edited October 15, 2009 by wraithdu
Recommended Posts