Context Navigation

Timeline

12:57 PM Ticket #4109 (GUICtrlSetResizing() and GUICtrlGetResizing()) closed by Jpm: Fixed: Fixed by revision [13556] Added #4109: GUICtrlGetResizng().

2:00 PM Ticket #3717 (StringFormat doesn't format int64 integers correctly) updated by Jpm: In fact according to Jon recommendation i added the size prefix ll or I64 to be use with INT64 variables I send an update to Jon for next Beta/release

8:18 AM Ticket #4090 (x64 - GUI freezes with Header subclassing in ListView) closed by Jpm: Wont Fix: It seems that the subclassing is invoke and conflict with the guimsg handling you can see in #4091 conflict wit GUIRegisterMsg My recommendation is to try to avoid as much as possible (too many autoit execution with this callback when possible) I close it

9:45 AM Ticket #3832 (IDispatch and the "_" character) closed by Jpm: Rejected: As no confirm I close it
8:48 AM Ticket #4102 (Adds "StartsWith" / "EndsWith" options to _ArraySearch / _ArrayFindAll) closed by Jpm: Rejected: no proposition so I close it
8:46 AM Ticket #4091 (Header painting dysfunctional when subclassed in ListView) closed by Jpm: Wont Fix
8:45 AM Ticket #4091 (Header painting dysfunctional when subclassed in ListView) updated by Jpm: I finally understand that GUIRegister cannot be use with subclassoroc as it is working befor subclass in some case MattyD show the right way to work

1:15 PM Ticket #4101 (Requesting consistency of the default value of $iStart/$iEnd in ...) closed by Jpm: Fixed: Fixed by revision [13555] Added #4101: consistency of the default value of $iStart/$iEnd in _Array* functions (check array fix updated).
10:15 AM Ticket #4091 (Header painting dysfunctional when subclassed in ListView) updated by MattyD: Hi guys, I've done a bit more digging on this one, and FWIW this is my understanding of what's happening. The LV header's parent window is the list view. So for custom drawing - the listview's proc is where the WM_NOTIFY/NMCUSTOMDRAWINFO initially hits. If the msg is unhandled at this level (or DefSubclassProc is called) then it is fired synchronously up to the parent. This is why we can see the header's customdraw messages via GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY") and respond. The breakdown occurs when returning a value back from the parent window to the control. In x86, we can return CDRF_NOTIFYITEMDRAW from WM_NOTIFY on the parent level - and this value is returned intact by the listview proc. In x64 however, the return value seems to be converted to a bool somewhere along the way, so its numeric value is lost. […]

4:06 PM Ticket #3717 (StringFormat doesn't format int64 integers correctly) updated by jchd18: I got hit by this bug again, so I get back to this ticket. I don't get why it is so difficult to check what internal equivalent of VarGetType() says about the variable in case of integral formats d, i, o, u, x, X and print accordingly that 32- or 64-bit numeric value. This way we still enjoy the possibility of flag and precision associated with these integral formats. Of course, we can work around by using %s for everything and work out the flag and precision desired, but this is overly complicated compared to simply act according to (internal) VarGetType.

3:00 PM Ticket #4073 (Add IFileOperation support with $FOF_ constants) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
2:04 PM Ticket #4073 (Add IFileOperation support with $FOF_ constants) closed by Jpm: Fixed: Fixed by revision [13552] - Added #4073: _WinAPI_IFO_*() for IFileOperation support.
2:01 PM Ticket #4073 (Add IFileOperation support with $FOF_ constants) updated by Jpm: Summary, Type changed

Note: See TracTimeline for information about the timeline view.