Timeline
May 16, 2018:
- 8:43 AM Ticket #3627 (Feature Request: AutoItWinGetHandle()) updated by
- Did you try to see if this was the case? When I run several concurrent instances of the same script I get a different handle returned for each instance, so it appears that the code will only return the handle associated with that instance, which is what I would expect. M23
May 15, 2018:
- 4:34 PM Ticket #3628 (_WinAPI_GetCaretPos() does not work) closed by
- Fixed: Fixed by revision [12145] in version: 3.3.15.1
May 14, 2018:
- 3:51 PM Ticket #3628 (_WinAPI_GetCaretPos() does not work) updated by
- Looks like there is an error in the _WinAPI_GetCaretPos() UDF where the pointer used in the DllCall not the struct created ($tPOINT) but the string with the struct definition ($tagPOINT). COuld you try this update: […] Jos
- 2:02 PM Ticket #3628 (_WinAPI_GetCaretPos() does not work) created by
- _WinAPI_GetCaretPos() is supposed to return an array. It only returns …
- 1:43 PM Ticket #3627 (Feature Request: AutoItWinGetHandle()) updated by
- If you have more than one AutoIt process running you could end up with the handle for another process. Also because the default title is just "AutoIt v3" it's possible another (non-AutoIt) window with that title could be open as well.
May 12, 2018:
- 7:50 AM Ticket #3222 (FileInstall) updated by
-
Owner, Status changed
May 9, 2018:
May 5, 2018:
- 7:00 PM Ticket #3627 (Feature Request: AutoItWinGetHandle()) updated by
- Why so complicated? Why not simply: […] M23
- 4:05 PM Ticket #3627 (Feature Request: AutoItWinGetHandle()) created by
- As simple as it sounds, can we get a function that just gives the …
May 4, 2018:
- 12:49 AM Ticket #3137 (FileRead() treats count parameter as bytes instead of characters for ...) updated by
- Furthermore, the poster uses files with BOM, so that shifts the byteread count.
May 2, 2018:
- 8:23 PM Ticket #3137 (FileRead() treats count parameter as bytes instead of characters for ...) updated by
- Running that test file shows me something different. It looks like StringLen is at fault here and not FileRead. If you do a ConsoleWrite right after the FileRead, and output the @extended you will see that it's always reading 7 characters/bytes like it's supposed to, but stringlen reports the wrong information. Look at the Starting and Ending offsets, and they're identical between the first and second tests.
Apr 29, 2018:
- 7:24 AM Ticket #3626 (Examples not working) closed by
- Fixed: Fixed by revision [12133] in version: 3.3.15.1
Apr 27, 2018:
- 5:53 PM Ticket #3626 (Examples not working) updated by
- You right _GUICtrlRichEdit_AutoDetectURL has already fix ( wrong align in $tagMSGFILTER) _WinAPI_GetSaveFileName() is returning @error example will be fix
- 3:59 PM Ticket #3626 (Examples not working) created by
- _WinAPI_GetSaveFileName - Example errors if you hit Cancel on the save …
Apr 21, 2018:
- 2:49 PM Ticket #3625 (DllStructGetData() does not retrieve whole string containing null ...) updated by
- Well, the Native API functions are also documented in MSDN (e.g. NtCreateKey/ZwCreateKey). Nearly all Native API functions does not require array of WCHARs to be null terminated because the functions work with UNICODE_STRING struct that has information about the length of the given array of WCHARs. Therefore, length of a string in the world of Microsoft Windows Native API is not based on position of null terminator.
- 12:25 PM Ticket #3625 (DllStructGetData() does not retrieve whole string containing null ...) closed by
- No Bug: This ticket cannot considered as a bug as AutoIt fit MSDN WCHAR/CHAR behavior If you want to catch Embedded Null Char just use Byte and do the conversion you want
- 11:35 AM Ticket #3625 (DllStructGetData() does not retrieve whole string containing null ...) updated by
- Or perhaps, by implementing a new specialized function, i.e. DllStructGetString().
- 11:32 AM Ticket #3625 (DllStructGetData() does not retrieve whole string containing null ...) updated by
- I realize there is a side effect of my proposal in the following example case: * A buffer for 2048 wchars is allocated using DllStructCreate(), then an API function returns the bytes length that is written to the buffer, for example, only 20 bytes (10 wchars) are written. * When the the 2048 wchars are retrieved using DllStructGetData(), there will be so many null characters at end the end of the final string. If the above scenario is unwanted because of the possibility to cause script breaking changes, then DllStructGetData() can provides an option to retrieve characters by length. This way will not cause a script breaking change, I think.
Apr 20, 2018:
- 10:56 PM Ticket #3625 (DllStructGetData() does not retrieve whole string containing null ...) created by
- See my question on …
Note:
See TracTimeline
for information about the timeline view.
