Context Navigation

Timeline

4:04 PM Ticket #4113 (Make version of Execute() that can take multiple lines.) updated by anonymous: No this is not what I meant. You interrupted string in the middle of $ContextVariable. The original idea was that entire $DynamicCode comes from external source exactly as it is. For example from file or post request body or other source. In addition, that example doesn't work because execute() simply does not support multi line code to begin with so there isn't anything that support forum can do about it, since it's the limitation of execute().
1:25 PM Ticket #4113 (Make version of Execute() that can take multiple lines.) closed by Jos: Completed: Please use the forum for questions. This is a place to report bugs and Features! To me your code should look something like this: […] .. but post a support topic in the forum and we can discuss it. :-)

8:27 PM Ticket #4113 (Make version of Execute() that can take multiple lines.) created by anonymous: I am a ware of /AutoIt3ExecuteScript switch which allows me to run …

10:49 PM Ticket #4112 (_WinAPI_MapWindowPoints addition) created by MattyD: Hey JP, I thought this one would probably be a good candidate for an …

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. […]

Note: See TracTimeline for information about the timeline view.