Timeline
Dec 2, 2011:
- 11:42 PM Ticket #2042 (Windows 8 support for @OS macros) closed by
- Completed: Added by revision [6473] in version: 3.3.7.22
- 11:10 PM Ticket #2061 (Rewrite OS_Version class) created by
- The code is an unwieldy mess of madness. It needs refactored so that …
Nov 30, 2011:
- 10:24 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by
- Replying to anonymous: > AFAIR, it's a known bug in SciTE, when the script is runing already and we use SciTE function that runs other tool, second copy of the script is executed. > > Try to run the script from SciTE and press F1. That would be it.
- 6:10 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) closed by
- Wont Fix: Regardless of what the root cause of this issue is, this is a SciTE bug. SciTE is not our project.
- 11:22 AM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by
- AFAIR, it's a known bug in SciTE, when the script is runing already and we use SciTE function that runs other tool, second copy of the script is executed. Try to run the script from SciTE and press F1.
Nov 29, 2011:
- 3:45 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by
- Using scite 2.27, downloaded here: http://www.autoitscript.com/site/autoit-script-editor/downloads/ Windows 7 x64, happens on any version of autoit (beta and release), had the problem for a long time. AutoIt3Wrapper v.2.0.3.0 Environment(Language:0406 Keyboard:00000406 OS:WIN_7/ CPU:X64 OS:X64) - in case it matters.
- 8:29 AM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by
- Replying to Shaggi: > Not much to say, sometimes, like 40% of times when i use ALT+I on a include line it runs the script. Very annoying sometimes. > Using the full scite4autoit. > > Couldn't find any other ticket after some searching, dno if it has been reported before.. You better describe which envirnonment you are running with, just copy the "SciTE Output plane" content. It is at least needed to understand what is going on.
- 7:54 AM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by
- Started discussion in the SciTE4AutoIt3 thread >> http://www.autoitscript.com/forum/topic/130437-new-scite4autoit3-available-with-scite-v227/page__view__findpost__p__942915
- 7:28 AM Ticket #2060 (UDFs Documentation issues) closed by
- Fixed: Fixed by revision [6462] in version: 3.3.7.22
- 12:33 AM Ticket #2060 (UDFs Documentation issues) updated by
- Oops, here is a correction for the first issue: >There should be a remark about the fact that it will work only if $LVS_SINGLESEL style not used.
- 12:28 AM Ticket #2060 (UDFs Documentation issues) created by
- While translating AutoIt help file by the Russian community, we found …
Nov 28, 2011:
- 9:18 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) created by
- Not much to say, sometimes, like 40% of times when i use ALT+I on a …
Nov 27, 2011:
- 11:34 PM Ticket #1973 (_IEAttach failes and crashes on some special window constellations) closed by
- No Bug: This is not bug and that's not solution. Create and use COM error handler to avoid situations like that.
- 11:25 PM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) closed by
- Fixed: Fixed by revision [6454] in version: 3.3.7.22
- 5:30 PM Ticket #1802 (_WinAPI_CallWindowProc() and _WinAPI_DefWindowProc() are not Unicode ...) closed by
- No Bug: Yashied you have registered a window class using Unicode version of that function. In that case the system passes text parameters of messages as Unicode, meaning your _MyWndProc() must use Unicode version functions you use. If you have done opposite of that _MyWndProc() would be correct. This proves that functions inside WinApi.au3 are not wrong. What's true is that WinApi.au3 misses Unicode versions of those functions as DllCall function calls ANSI versions of functions by default when there are any doubts. This is not a bug.
Nov 26, 2011:
- 12:55 PM Ticket #1900 (Improvements for StringRegExpGUI) updated by
- @FichteFoll Community appreciate it but not as part of standard Autoit package. This Trac is designated only for things related to standard Autoit package. Please create topic with this your improved/fixed version of StringRegExpGUI in Examples section on forum.
- 8:56 AM Ticket #1900 (Improvements for StringRegExpGUI) closed by
- Rejected: The need for this script is questionable. Apparently community doesn't appreciate it enough.
Nov 25, 2011:
- 6:00 PM Ticket #1770 (Script getting pause when popup appears in IE) updated by
-
Milestone changed
Automatic ticket cleanup. - 5:53 PM Ticket #2055 (Convert UDF's to struct* type) closed by
- Fixed: Fixed by revision [6445] in version: 3.3.7.22
- 4:29 PM Ticket #1770 (Script getting pause when popup appears in IE) closed by
- No Bug
- 4:29 PM Ticket #1770 (Script getting pause when popup appears in IE) reopened by
- 4:11 AM Ticket #1472 (GUISetCursor Bug) updated by
- Umm. No. The last time we tried to fix the idiocy that pertains to this Jon made comment:1. There's no way in hell I'm going to try again to fix it at the 11th hour. What needs to happen is a script breaking change needs to occur to normalize the values of MouseGetCursor() and GUISetCursor().
- 12:34 AM Ticket #1472 (GUISetCursor Bug) updated by
- Just clarification for developers: Here is related ticket which is cause of this bug: MouseGetCursor() - identify also standard hand cursor (IDC_HAND) http://www.autoitscript.com/trac/autoit/ticket/1311 I think this ticket should be set as Blocking.
Nov 24, 2011:
- 9:00 PM Ticket #1777 (Issues with Security.au3) updated by
-
Milestone changed
Automatic ticket cleanup. - 7:24 PM Ticket #1777 (Issues with Security.au3) closed by
- Fixed
- 7:05 PM Ticket #1770 (Script getting pause when popup appears in IE) updated by
-
Owner, Resolution, Milestone changed
Nothing changed here. I specified wrong bug id that resulted in raising this one. Error on my side.
Nov 23, 2011:
- 9:50 AM Ticket #2041 (_FTP_ListToArrayEx Datetime Format) closed by
- Duplicate: Replying to anonymous: > A few additional inforamtion: > > In the help file it says that with $b_Fmt=1 the format will be YYYY/MM/DD and with $b_Fmt=0 it will be MM/DD/YYYY. > > But as seen on the picture the output with $b_Fmt=1 is YYYY/DD/MM, so defnetly a bug. check with beta as it as been solved by #1509
Nov 22, 2011:
- 6:58 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by
- Not a problem, thank you for the response. Would it be reasonable to make a smaller change, and have DirCreate return an error when given a path greater than the buffer size, instead of returning success and creating some unknown truncated path? It's this latter behavior that should ideally be avoided.
- 3:00 PM Ticket #2057 (Advanced Window Descriptions - Add "PID" Property) updated by
-
Version changed
Automatic ticket cleanup. - 12:54 PM Ticket #2058 (WinWait, WinWaitActive and WinActive calls are waiting indefinitely ...) created by
- Few AutoItX functions are hanging when using in VS 2008(vb.net) IDE. …
- 12:41 PM Ticket #2057 (Advanced Window Descriptions - Add "PID" Property) created by
- Would be be possible to add "PID" as a property recognised in the …
- 12:38 AM Ticket #269 (ImageSearch()) updated by
- No offense taken. You should be able to see reddish box above the text area for reply. Read what it says and try to follow those guidelines. Thanks.
Nov 21, 2011:
- 10:50 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by
- JPM, you are not a developer any longer, please stop acting like one. Yes, JP brought it to our attention that long paths are not supported. All path related functions use a hard-coded buffer length of MAX_PATH. I detest hard-coded buffer sizes and I know that it needs changed to support variable length paths. The problem is I'm trying to get a release out before we all die and we can't make significant changes like this just weeks before said release. It was fine to create the ticket but all this discussion with JP has been pointless. Long paths will be supported at some point after the next release and this ticket should be irrelevant at that time.
- 9:10 PM Ticket #269 (ImageSearch()) updated by
- Replying to Zedna: > Replying to trancexx: > > After weighting gains and losses this ends up rejected. > > I'm very interested in these positive/negative arguments ... No offence, just be more detailed when closing tickets please, thanks.
- 8:13 PM Ticket #1658 (COM / OLE object access causes error code 80020003 - member not found) updated by
- I am attempting to come up with something, and will post it soon.
- 4:49 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by
- Replying to wraithdu: > So you're confirming this is an error/bug as to the behavior of DirCreate? Because DirCreate, as I showed, is not creating the extra long path properly. > > If so, thank you :) Before your ticket I already warn the other dev that we may have to support […] Perhaps they will do something. I am a banned Dev Thanks to Valik
- 4:43 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by
- So you're confirming this is an error/bug as to the behavior of DirCreate? Because DirCreate, as I showed, is not creating the extra long path properly. If so, thank you :)
- 4:27 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by
- I understand, I can add that the removal is only possible if the full path of the last created directory if less than ~260 chars. Explorer itself cannot remove it (I am running Win7 Sp1 32-bit)
- 3:03 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by
- That's not correct. The directory is not created properly. *A* directory *is* created, but it's not the one specified in the function. The path is truncated to 255 chars and a 255 char length directory is created. In fact FileExists does work correctly on paths longer than 255 chars, but you have to create them via other means to test this. Here is the path from your test as it was created: C:\some\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\lo It is 255 chars long. Try this for comparison. You'll have to rename some directories to remove the final path since it will be too long (>255). […]
- 2:26 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by
- In fact the dir is created when using […] the only thing you can perhaps contest is FileExists or DirRemove does not found such path […]
- 11:44 AM Ticket #2056 (Excel.au3 - 5 Broken Functions) updated by
- Windows 7, Excel 2010
- 11:16 AM Ticket #2056 (Excel.au3 - 5 Broken Functions) created by
- 3.3.7.21(beta) 3.3.6.1 Any reference to …
- 3:43 AM Ticket #2055 (Convert UDF's to struct* type) created by
- Just a reminder for myself.
- 2:51 AM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) created by
- DirCreate returns 1 (success) when the path is longer than 255 …
Nov 20, 2011:
- 11:56 PM Ticket #269 (ImageSearch()) updated by
- Replying to trancexx: > After weighting gains and losses this ends up rejected. I'm very interested in these positive/negative arguments …
- 9:51 AM Ticket #1953 (FileExists returns 1 for non existing path) updated by
- Quick code review indicates that there could be problems with FileGetTime and related functions. Additional problem seems to be file system redirector.
- 9:28 AM Ticket #262 (Plugins - array parameters) closed by
- Rejected: Current implementation of "Plugin" feature and internal handling of array data type makes the request not worthy of the complexity that would be the result of having this feature. However plugins would be handled eventually one way or the other. When that happens this ticket would be rendered invalid simply because plugins require thorough evaluation that should address every aspect of the implementation including array support.
- 8:05 AM Ticket #488 (ObjGet() needs an instance parameter) updated by
-
Owner, Status changed
Nov 19, 2011:
- 2:14 PM Ticket #1698 (GUICtrlSetLimit, limit 32767) updated by
- The following also does not work $1 = GUICtrlCreateInput("3389", 235, 200, 150, 20) $2 = GUICtrlCreateUpdown($1, $UDS_NOTHOUSANDS) GUICtrlSetLimit($2, 49151, 1024)
Nov 18, 2011:
- 2:43 PM Ticket #269 (ImageSearch()) closed by
- Rejected: After weighting gains and losses this ends up rejected.
Nov 17, 2011:
- 10:14 AM Ticket #2053 (HotKeySet in AutoItX) updated by
- ok. thanks for the informations. Sometimes, it would be good to have a little more explanations as we are not aware of all the internal mecanisms. I was just trying to use your tool (that is really so powerfull) and didn't have any fun to develop in basic so, I try to use autoitx with python and was just surprised that the fonctionality of the hotkeyset was not implemented as it seems so simple and that a native python solution is really uggly and requires so much coding.
Nov 16, 2011:
- 6:15 PM Ticket #2053 (HotKeySet in AutoItX) updated by
- Replying to anonymous: > Don't be surprised if autoitx isn't used by many if you react like this for a simple request. React like what? I closed the ticket as rejected with a reason why. Since you've now prodded me I'll add in that this is an incredibly stupid request. Calling it "simple" is laughable and shows just how ignorant you are. It's not simple. Implementing this requires not one but TWO completely different callback mechanisms. AutoItX would need to implement COM events for languages using it via COM. It would also need to implement a C interface for languages using that binding method. Even when the callback is invoked it's just going to shift control right back to your host language anyway so why not do the logical thing and implement all the hotkey stuff yourself in the host language? If your host language doesn't support registering hotkeys but you need that for your application then I guess you picked the wrong language to begin with? So yeah, all-in-all a really stupid request I politely closed until somebody decided to argue about it. Good job.
- 1:24 PM Ticket #2053 (HotKeySet in AutoItX) updated by
- Don't be surprised if autoitx isn't used by many if you react like this for a simple request.
Nov 15, 2011:
- 7:08 PM Ticket #2053 (HotKeySet in AutoItX) closed by
- Rejected: Your host language should provide hotkey support, not AutoItX.
- 3:00 PM Ticket #2053 (HotKeySet in AutoItX) updated by
-
Version changed
Automatic ticket cleanup. - 1:38 PM Ticket #2053 (HotKeySet in AutoItX) created by
- HotKeySet doesn't seem to be implemented in AutoItX. would it be …
Nov 11, 2011:
- 9:45 PM Ticket #2052 (When using MSTSC Remote Desktop Connection, AutoIt and AU3Info only ...) closed by
- No Bug
- 10:11 AM Ticket #2052 (When using MSTSC Remote Desktop Connection, AutoIt and AU3Info only ...) updated by
- This is not bug. MSTSC (remote desktop) only transfer screen as bitmap and key/mouse commands. So it's not not possible to "see" controls.
Nov 10, 2011:
- 9:53 PM Ticket #2052 (When using MSTSC Remote Desktop Connection, AutoIt and AU3Info only ...) created by
- Great program! However, under Remote Desktop commands such as WinWait …
- 4:49 PM Ticket #1668 (Directory Macros for Default User Account) closed by
- Rejected
- 2:32 PM Ticket #1629 (Ability to destroy embedded IE objects to rehash browser settings) closed by
- Works For Me: You not knowing how to do it doesn't mean it can't be done.
- 2:26 PM Ticket #1648 (UDF community) closed by
- Works For Me: Send mail to the administrator.
- 2:20 PM Ticket #1158 (Global update the WinAPI.au3 library) closed by
- Wont Fix: Anyone with access can add what ever they feel necessary. Ticket in this form doesn't make sense. Closing as "wont fix" because... because.
Nov 9, 2011:
- 8:45 AM Ticket #1658 (COM / OLE object access causes error code 80020003 - member not found) updated by
- ActiveX download links are no more available. Please update if you want some testing be done Thanks
Nov 8, 2011:
- 10:25 PM Ticket #2051 (Error at online documentation) closed by
- Completed: Changed by revision [6390] in version: 3.3.7.22
- 9:48 PM Ticket #2051 (Error at online documentation) created by
- Hi, at the following functions you should change "<a …
- 8:09 PM Ticket #2050 (Handle should bei called filehandle) closed by
- Completed: Changed by revision [6389] in version: 3.3.7.22
- 8:06 PM Ticket #2050 (Handle should bei called filehandle) updated by
- OK now I understand.
- 7:59 PM Ticket #2050 (Handle should bei called filehandle) updated by
- Yes I am talking about the parameters table. I think this things should be uniform (e. g. link FileClose)
- 7:34 PM Ticket #2050 (Handle should bei called filehandle) updated by
- I take it you're talking about the parameters table? It does say for those functions "A handle to a file."
- 7:31 PM Ticket #2050 (Handle should bei called filehandle) created by
- Hi, in the functions FileFlush FileGetPos FileSetPos the parameter …
Nov 7, 2011:
- 10:57 PM Ticket #1906 (reparse point) updated by
- Replying to Valik: > This seems like something that should be done via UDFs. Closing as rejected. Maybe this could be added to general recommendation about what type of requests will not be done: - these ones that can be done via UDFs - …
- 10:51 PM Ticket #1954 (ListViewItem returns 0 (failure) even though it populates the ListView) updated by
- Here is another modification […] In this case: less (only two) columns given it sucessfully create listview item and also corect nonzero control ID is returned. So there is question if in case of more columns given shouldn't be returned correct nonzero control ID if Autoit can display it correctly (cut thrid unnecessary column internally)?
- 10:16 PM Ticket #1873 (Return the thread ID of a child process from Run) updated by
- Reconsider @extended. This is extended additional info considering the nature of TID in context of other AutoIt functions.
- 10:08 PM Ticket #2049 (Missing WM_MESSAGES in WindowsConstants.au3) closed by
- Completed: Added by revision [6385] in version: 3.3.7.22
- 10:04 PM Ticket #2049 (Missing WM_MESSAGES in WindowsConstants.au3) created by
- The following list is missing from WindowsConstants.au3. Global Const …
- 9:12 PM Ticket #2048 (WindowsConstants containing invalid variables) closed by
- Fixed: Fixed by revision [6384] in version: 3.3.7.22
- 9:11 PM Ticket #2048 (WindowsConstants containing invalid variables) created by
- $WM_RBUTTONDBLCK & $WM_MBUTTONDBLCK in WindowsConstants.au3 should be …
- 9:09 PM Ticket #1862 (GUISetOnEvent should behave more like HotKeySet()) closed by
- Rejected: Receiving a second GUI message before handling of the first message is complete can be disastrous. You should never execute long-running tasks in a GUI callback function no matter what language. It's poor application design. Closing as rejected.
- 9:03 PM Ticket #1873 (Return the thread ID of a child process from Run) updated by
- This request makes sense but I cannot think of a good way to do it. I do not want to use @extended for this. It seems logical that returning an array would solve the problem but that also requires either adding a new parameter or a new flag for the parameter currently used to control STDIO.
- 8:55 PM Ticket #1885 (CreateGUID and CreateGUIDSequential missing, but $tagGUID there) closed by
- Rejected: If someone wants to write and test a library that's fine but we are not going to do it. Closing as rejected.
- 8:52 PM Ticket #1903 (Au3Check, Globals, #OnAutoItStartRegister) closed by
- Rejected: Too complex to implement for very little gain. Rejected.
- 8:51 PM Ticket #1906 (reparse point) closed by
- Rejected: This seems like something that should be done via UDFs. Closing as rejected.
- 8:49 PM Ticket #1939 (Be able to put some text in a Progress control) closed by
- Rejected: This can already be done by overlapping controls. Rejected.
- 8:46 PM Ticket #1940 (GUI*OnEvent default functions) closed by
- Rejected: Trivial to write your own wrapper function to do this.
- 8:40 PM Ticket #1955 (Unable to select the appropriate option from combo box) closed by
- No Bug: Non-standard control (.NET I think). No bug.
- 8:36 PM Ticket #1909 (little problem with an updown control) closed by
- No Bug: No script, not wasting my time trying to chase this down. Closing as no bug.
- 8:32 PM Ticket #1789 (_GUICtrlRichEdit_Create blocking syntax error reporting while in SciTE) closed by
- Duplicate: Closing as a duplicate of #1319.
- 8:19 PM Ticket #2019 (File functions: Three help file issues and one bug) closed by
- No Bug: Seems we all covered this. Closing as no bug.
- 8:15 PM Ticket #2040 (_GUICtrlDTP_SetRange; MinYear never goes below 1/1/1752 00:00:00) closed by
- No Bug: Closing as no bug. I don't feel documenting this is all that big of a deal. How often do people really need those dates?
- 5:22 PM Ticket #1954 (ListViewItem returns 0 (failure) even though it populates the ListView) updated by
- The $item2 is really invalid as it try to defined more field than the list number of columns can have. The bug is it should not be displayed. Bad internal error handling.
- 5:08 PM Ticket #1995 (Different results on x86 and x64) updated by
- In fact AutoIt does really support .* precision. Your example is wrong as an extra parameter defining the precision will be needed before the string to defined the precision […] but as I say Autoit will not support this format So fix must be done to accept or reject such precision definition
- 3:32 PM Ticket #1925 ($WS_EX_LAYOUTRTL missing in documentation) closed by
- Completed: Added by revision [6383] in version: 3.3.7.22
- 3:02 PM Ticket #1631 (Get FilePath from file handle) updated by
- Replying to guinness: > This is an Example of how to achieve this using native code - http://www.autoitscript.com/forum/topic/134578-filenamebyhandle-find-a-filepath-using-the-handle-returned-by-fileopen/. It is not using native code as comment 5 request it
- 2:56 PM Ticket #1631 (Get FilePath from file handle) updated by
- This is an Example of how to achieve this using native AutoIt code - http://www.autoitscript.com/forum/topic/134578-filenamebyhandle-find-a-filepath-using-the-handle-returned-by-fileopen/.
- 11:03 AM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) updated by
- Replying to anonymous: > Replying to Zedna: > > Replying to Jpm: > > > BitAND($iFlags, $MF_STRING) > > > is always equal to 0 > > > as $MF_STRING is equal to 0 whatever $iFlags value > > > > > > AHA! I didn't know that MF_STRING=0 > So no BUG ??? I don't know yet. I don't have time to think about it/test it right now deeply. I want only say what was source our diferrent opinion.
- 10:25 AM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) updated by
- anonymous is me
- 8:24 AM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) updated by
- Replying to Zedna: > Replying to Jpm: > > BitAND($iFlags, $MF_STRING) > > is always equal to 0 > > as $MF_STRING is equal to 0 whatever $iFlags value > > > AHA! I didn't know that MF_STRING=0 So no BUG ???
- 7:41 AM Ticket #1719 (Expose the internal function that creates the $CmdLine array?) closed by
- Rejected: Current solution is reckoned to be sufficient. For "function approach" consult different UDFs, as guinness did.
- 7:37 AM Ticket #998 (@VirtualDesktopWidth + @VirtualDesktopHeight + @DesktopMonitors) closed by
- Rejected: This is clearly UDF's job. Thank you guinness.
- 7:30 AM Ticket #1683 (Displaying thumbnails of files in a GUI) closed by
- Rejected: The accent is on using UDFs.
- 12:34 AM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) updated by
- Replying to Jpm: > BitAND($iFlags, $MF_STRING) > is always equal to 0 > as $MF_STRING is equal to 0 whatever $iFlags value AHA! I didn't know that MF_STRING=0
Nov 6, 2011:
- 11:57 PM Ticket #1683 (Displaying thumbnails of files in a GUI) updated by
- Your request can be achieved by using the following example. […]
- 11:55 PM Ticket #1719 (Expose the internal function that creates the $CmdLine array?) updated by
- Your request can be achieved by using the following example. […]
- 8:40 PM Ticket #998 (@VirtualDesktopWidth + @VirtualDesktopHeight + @DesktopMonitors) updated by
- Example of how to achieve this with the WinAPI.au3 UDF >> http://www.autoitscript.com/forum/topic/134534-desktopdimensions-details-about-the-primary-and-secondary-monitors/
- 8:23 PM Milestone 3.3.7.21 completed
- 8:09 PM Ticket #1945 (UPX is outdated in the latest beta's.) closed by
- Completed: upx was updated in revision [6163].
- 12:05 PM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) updated by
- Replying to Zedna: > @jpm > You are wrong. > $iFlags can be for example MF_BITMAP and also combined by BitOr() with other MF_xxx flags. > So my fix is correct. > > I discovered this problem in my project where About in system menu was missing after upgrade from Autoit 3.2.12.1 to latest beta. My above fix corrected the problem. > > As I said before, finally I removed from my project code line adding MF_BYPOSITION as it's not correct in this context so without it it works fine also with latest beta. Perhaps I am wrong but BitAND($iFlags, $MF_STRING) is always equal to 0 as $MF_STRING is equal to 0 whatever $iFlags value So the comparison with $MF_STRING is always true So I don't know what is the solution if one is needed as your example want to create a sparator line which is what the release/beta is doing I agree that $MF_STRING defined as 0 is a strange value but that what MS defined to
- 11:44 AM Ticket #134 (Add support for COM events to take ByRef parameters) closed by
- No Bug: We do support this for some time now. Attached code have logical error. Run method of that object doesn't take parameters byref (in sense that it advertise altering the content).
- 10:58 AM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) updated by
- @jpm You are wrong. $iFlags can be for example MF_BITMAP and also combined by BitOr() with other MF_xxx flags. So my fix is correct. I discovered this problem in my project where About in system menu was missing after upgrade from Autoit 3.2.12.1 to latest beta. My above fix corrected the problem. As I said before, finally I removed from my project code line adding MF_BYPOSITION as it's not correct in this context so without it it works fine also with latest beta.
- 10:19 AM Ticket #1966 (Transparent Tree View) closed by
- Rejected: Who's nobody? If community is really interested than community would have solutions.
- 9:46 AM Ticket #1700 (Synchronous ObjEvent) updated by
-
Owner changed
- 9:44 AM Ticket #1661 (AutoIT support for Stingray controls) closed by
- Rejected
- 9:42 AM Ticket #1739 (get/set cookie value function) closed by
- Rejected: Manual cookie manipulation isn't something AutoIt should have built-in. UDFs are made for that.
- 9:35 AM Ticket #1889 (_ArrayDisplay optionaly display columns in hex.) closed by
- Rejected
- 9:31 AM Ticket #2005 (Active Directory) closed by
- Rejected
- 9:29 AM Ticket #2005 (Active Directory) updated by
- No. There are UDFs for that.
- 9:04 AM Ticket #1442 (_FileWriteLog to allow allow file handle or filename as first parameter) closed by
- Completed: Added by revision [6369] in version: 3.3.7.21
Nov 5, 2011:
- 9:15 PM Ticket #2037 (COM speed deterioration) closed by
- Fixed: Fixed by revision [6367] in version: 3.3.7.21
- 3:17 PM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) updated by
- I am sure the suggested fix is not correct as BitAND($iFlags, $MF_STRING) is always equal to $MF_STRING so $sType will never be set to "ptr". For me you ask for a separator and you get it. Perhaps the doc is not enough precise when you use it for system menu.
- 8:05 AM Ticket #2047 (ProcessExists bad return) updated by
- Thanks, It can be difficult to understand, perhaps some warning in the doc.
Nov 4, 2011:
- 5:12 PM Ticket #2047 (ProcessExists bad return) closed by
- No Bug: This is not a bug. The process really doesn't exist. It closes immediately because it does not have a STDIN stream pointing to anything useful. If you want the program to continue to run then you need to provide a STDIN handle.
- 2:11 PM Ticket #2047 (ProcessExists bad return) created by
- […] The ProcessExists() returns 0 which is wrong. It is OK if the …
Nov 3, 2011:
- 5:59 PM Ticket #2046 (DirGetSize ( '' ) doesn't return error) closed by
- Fixed: Fixed by revision [6363] in version: 3.3.7.21
- 5:03 PM Ticket #2046 (DirGetSize ( '' ) doesn't return error) updated by
-
Description changed
Several things wrong with this bug report. * Why did you enclose the description in code tags? There was no code posted. * Why are you filing bug reports against 3.3.6.1 when we are at beta 3.3.7.20? Did you read the ticket guidelines before posting? * The fact that it returns a value should not be surprising. I expected the size of the working directory to be returned. Instead it returns the size of the drive for working directory due to stupid code. Since this doesn't behave in a sensible fashion I'll just make it error out on an empty path. It should probably return the size of the current working directory, though. - 12:29 PM Ticket #2046 (DirGetSize ( '' ) doesn't return error) created by
- DirGetSize Function ( with or without flag ) should returns -1 and …
Nov 2, 2011:
- 5:42 PM Ticket #1479 (ListView WM_NOTIFY Message on x64 Returning Wrong Results) updated by
- Thanks guys, I just about lost it loonikg for this.
Note:
See TracTimeline
for information about the timeline view.
