Timeline
Feb 11, 2019:
- 8:10 PM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
- Not sure why I'm persevering but it has occurred to me that what you said about MS not documenting it is not actually true. The MSDN documentation says: lpNumberOfBytesTransferred - A pointer to a variable that receives the number of bytes that were actually transferred by a read or write operation. It doesn't say "but only in the case when GetOverlappedResult is True otherwise it can't be bothered to tell you how many bytes were successfully transferred" When GetOverlappedResult returns False and GetLastError()==ERROR_MORE_DATA The Read/Write operation has transferred a whole buffer, and *lpNumberOfBytesTransferred is set to tell us how many that is - exactly as MSDN documents. The UDF then discards the value leaving junk in $iBytes (Also if an operation is aborted part way through, then it tells you how many where transferred - though I can't believe that's very reliable for Write). Anyway this is absolutely my last comment on the matter, a workaround is too easy for all this effort. Alan
- 6:47 AM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
- Hi, For me it is not a workaraound as if MS make some internal changes the UDF still work I leave to Jon the final answer on this Ticket Cheers
- 2:10 AM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
- Indeed MSDN doc is lacking <- nothing new there. In the MSDN example at the end of what I linked to in the first post, just how many chars does the _tprintf statement output anyway??? BUT:- as MSDN does NOT document how and when it sets the $iBytes parameter, why should the UDF decide to discard the value set by Microsoft, based on some unnecessary and arbitrary logic in the UDF. Why discard the value if the return is False but use it when it returns True. Surely the UDF should pass back whatever the Dll call sets! A look at Wine's implementation https://source.winehq.org/source/dlls/kernel32/file.c#0610 shows that it always sets the $iBytes value regardless of the return code or GetLastError() value. But it's up to you whether you fix this bug or not. AS you say there are workarounds.
Feb 10, 2019:
- 6:41 PM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
- Thanks, the MSDN DOC does not describe how the ibyte parameter is set <hen the return result is set to zero. So after the _WinAPI_GetOverlappedResult() return false you call the Getlasterror==ERROR_MORE_DATA then you need to use the nbbyte you use in the function that initiated the transfert _WinAPI-ReadFile() or other related function you use. Perhaps it was working with the old coding but as it is not described in the MSDN DOC I will not change it Cheers
- 11:58 AM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
- The Struct/ptr code change is not the problem (that change since 3.3.8.1 is fine and wanted) The problem is that: If @error Then Return SetError(@error, @extended, False) was changed to If @error Or Not $aResult[0] Then Return SetError(@error, @extended, False) So if $aResult[0] is False then the $iBytes = $aResult[3] statement doesn't get done. The issue is just that the ByRef parameter needs to be assigned whatever is set by the DllCall in all cases, not just when the result is True. An example would be long and complex but could be done, but hoping you don't need it. Alan
- 6:36 AM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
-
Component changed
- 6:36 AM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
- Hi, I cannot undzrstand why passing a ptr instead of a struct can set $iBytes. But well can you post an example that reproduce the pb so I can analyse more carefully Thanks for the help
Feb 9, 2019:
- 1:37 PM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) updated by
- Sorry - should have set component to Standard UDFs
- 11:29 AM Ticket #3697 (_WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes ...) created by
- _WinAPI_GetOverlappedResult does not set the $iBytes [out] parameter …
Feb 3, 2019:
- 2:53 PM Ticket #3696 (Func _ArrayFromString($s, $sDelim_Col = "|", $sDelim_Row = @CRLF, ...) created by
- […] This function reconstructs an "array to text" created with …
- 2:40 PM Ticket #3695 (Func _SQLite_Display2DResult($aResult, $iCellWidth = 0, $bReturn = ...) created by
- […] This version has the possibility to declare Column and Row …
Feb 2, 2019:
- 2:07 AM Ticket #3694 (WinGetSize function missing from AutoItX3_64) created by
- I am using AutoItX3_x64.dll (AutoItX3.dll does not load). I tried the …
Jan 30, 2019:
- 8:33 AM Ticket #3238 (Au3info doesn't compensate for DPI scaling) updated by
-
Owner, Status changed
Understood but that would mean a change in the program in case that needs changing. I just demonstrated that the manifest needs updating for the dpi awareness. I leave this ticket open to make the change permanent in the next versions. Jos
Jan 29, 2019:
- 11:10 PM Ticket #3238 (Au3info doesn't compensate for DPI scaling) updated by
- It displays the correct pixels now but now the window is very small on high resolution monitors since it doesn't use the system-wide DPI scaling now.
Jan 27, 2019:
- 1:01 PM Ticket #3238 (Au3info doesn't compensate for DPI scaling) updated by
- Replying to anonymous: > Jos can you repost it. I get Not Found > > The requested URL /autoit3/scite/download/beta_SciTE4AutoIt3/Au3Info.exe was not found on this server. It should be there again.. Jos
- 12:55 PM Ticket #3693 (Invalid SciTEConfig_Source.zip File on downloads page) closed by
- Fixed
- 12:36 PM Ticket #3693 (Invalid SciTEConfig_Source.zip File on downloads page) updated by
- Updated the ZIP file by skipping the -LMZA parameter on the 7zip commandline. It can now also be opened by the buildin WIN10 extract option. Same done for Au3Stripper.zip. Jos
- 1:37 AM Ticket #3693 (Invalid SciTEConfig_Source.zip File on downloads page) created by
- Issue: The SciTEConfig_source.zip file that is located here …
- 12:47 AM Ticket #3238 (Au3info doesn't compensate for DPI scaling) updated by
- Replying to Jos: > It seems just a matter of changing the manifest of the program. I have made a trial version of the original au3info where I updated the manifest with reshacker and stored it here: https://www.autoitscript.com/autoit3/scite/download/beta_SciTE4AutoIt3/Au3Info.exe > > Give it a try and let us know. > > Jos Jos can you repost it. I get Not Found The requested URL /autoit3/scite/download/beta_SciTE4AutoIt3/Au3Info.exe was not found on this server.
Jan 21, 2019:
- 5:42 PM Ticket #3692 (SciTE v. 4.1.2.0 - the function luaL_register has removed) closed by
- Wont Fix: Ok... I will close this report. :) Jos
- 5:11 PM Ticket #3692 (SciTE v. 4.1.2.0 - the function luaL_register has removed) updated by
- There are even more procedure entry points that are no longer present in the newer SciTE versions. The list in the Attachment SciTE-Procedure_entry_points.7z shows which procedure entry point is supported in which SciTE version.
- 4:39 PM Ticket #3692 (SciTE v. 4.1.2.0 - the function luaL_register has removed) updated by
- I've now tested with the original from Neil (v 4.1.3 Jan, 10. 2019). The result is the same. So I'll link this report to Neil's scite-interest group. Thanks for the hint.
- 3:15 PM Ticket #3692 (SciTE v. 4.1.2.0 - the function luaL_register has removed) updated by
- Is this working in Neil's official version of SciTE and failing in my version or is this a generic issue in SciTE 4.1.2? Jos
- 11:03 AM Ticket #3692 (SciTE v. 4.1.2.0 - the function luaL_register has removed) created by
- Because luaL_register has removed, it's impossible to use external dll …
Jan 19, 2019:
- 10:11 PM Ticket #3684 (Aut2exe.exe window title and version number) updated by
- As far as I can tell, none of the tools gives the version number/build number when shown, or in the Help=>About dialog. The only item that shows a build number is the help file .exe , as I think should be the case. Do they really need to?
- 9:52 PM Ticket #3690 (ieCreate function failing with Windows 10 update 1804) updated by
- I can't confirm this problem. I'm running Win10, build 1809, AutoIt 3.3.14.5 and it works for me every time. I never get any errors.
Jan 14, 2019:
- 4:49 PM Ticket #3691 (Wrong link in the CLSID List page) created by
- In the help page of the CLSID list …
- 12:00 AM Ticket #3690 (ieCreate function failing with Windows 10 update 1804) updated by
- Upon reboot the script runs fine for the first couple of times and then stops working. Have confirmed that on each machine with the latest feature release this behavior is observed.
Jan 13, 2019:
- 11:57 PM Ticket #3690 (ieCreate function failing with Windows 10 update 1804) updated by
- Sorry - its 1809 October release - my mistake.
Note:
See TracTimeline
for information about the timeline view.
