Leaderboard

It will work. The binary is converted to a string of UCS2 encoding units with exact same data: only the encoding is changed. PCRE (the underlying regex processing code is imune to embedded NULLs. In AutoIt 0x00 is only a string termination on I/O (AFAICT).

New version PSPad4AutoIt3 v1.2.0 beta (2020-08-03). Download in Posting # 1 The highlights of the new features: Improvement kit The biggest innovation is the "killer feature" CallTips for OUDFs . The CallTipViewer has only shown Au3Api functions so far, now CallTips are also implemented for OUDFs! Au3Api functions are the official AutoIt functions, which are either "built in" or delivered with AutoIt. In short, all functions that can be found in the au3.api or the AutoIt help. OUDF stands for "own user defined function", which is NOT found in the AutoIt help, but is in an Au3 script that you are currently working with, or which are in the included Au3 scripts. These can be functions that you or someone else wrote, everything that is not in the AutoIt help is displayed in the CallTipViewer as OUDF. Even volatile functions are displayed. Display in the CallTip A CallTip has two lines. For Au3Api functions, the syntax of the corresponding function is displayed in the first line and a description of this function in the second line. For OUDFs, the first line also shows the syntax of the corresponding function, but the second line shows the path to the Au3 script in which this function is located. Invalid functions Valid functions and also most invalid functions are displayed in the CallTip. There are only a few criteria with which invalid functions are filtered out and therefore no CallTip is displayed. It is e.g. checked whether there is an associated function foot for a function head and whether there is an opening and an associated closing parenthesis after the function name. But don't worry, the compiler takes care of invalid functions! Monitoring CallTips for OUDFs are only displayed for saved files! That means, if you are working in a script and e.g. have just written a new function, it will not be displayed in the CallTip until you have saved the script. This is because the files are monitored for changes via folder monitoring. This means that the CallTips are automatically updated when a file is saved, even live* while a CallTip is currently visible. (* Delay by Windows ShellChangeNotify of about 1 second.) Also external changes, thus outside PSPad, are detected. So the CallTips for OUDFs are always up-to-date! Color Scheme "auto" The Color Scheme of the CallTip is now automatically adapted to the current PSPad skins. If a light skin is selected the CallTip will also be shown with the light color scheme, if a dark skin is selected the CallTip will automatically be shown with a dark color scheme. The previous features for Au3Api functions also apply to OUDFs. Credits And as always: I would be happy if you have a look at the program and write your opinion about it. Praise, criticism, ideas, tips and hints on bugs are welcome. Have fun with the new features! Prof Bernd.

use while _IsPressed

@ThePoro A couple of things - 1. Follow the above link or see here about getting an update to WinHTTP 2. I ran into a similar situation recently when running geckodriver 0.27. I'm guessing that you are running a 64bit version of Windows. Try running the x64 version of geckodriver.

If you use #RequireAdmin in your script, and SciTE wasn't started with the same level of access, i.e. using Run As Administrator, then when you run your script, the #RequireAdmin will be seen and the script will end, and then restart itself with administrator permissions. This is why you don't see anything in SciTE, start it as an administrator, and then run your script, should work fine.

@Aether and anyone else that feels like testing, here's a simple test script I've been using -- #include "WinHttp.au3" #include <WinAPIError.au3> Opt("MustDeclareVars", 1) Global $sDomain = "www.github.com" Global $sPage = "dragana-r/autoit-winhttp" ; Initialize and get session handle Global $hOpen = _WinHttpOpen() ; Get connection handle Global $hConnect = _WinHttpConnect($hOpen, $sDomain) ; Make a request Global $hRequest = _WinHttpOpenRequest($hConnect, "GET", $sPage) _WinHttpSetOption($hRequest, $WINHTTP_OPTION_DECOMPRESSION, $WINHTTP_DECOMPRESSION_FLAG_ALL) _WinHttpSetOption($hRequest, $WINHTTP_OPTION_UNSAFE_HEADER_PARSING, 1) _WinHttpSetOption($hRequest, $WINHTTP_OPTION_REDIRECT_POLICY, $WINHTTP_OPTION_REDIRECT_POLICY_ALWAYS) _WinHttpSetOption(_WinHttpQueryOption(_WinHttpQueryOption($hRequest, $WINHTTP_OPTION_PARENT_HANDLE), $WINHTTP_OPTION_PARENT_HANDLE), $WINHTTP_OPTION_SECURE_PROTOCOLS, BitOR($WINHTTP_FLAG_SECURE_PROTOCOL_ALL, $WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1, $WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2)) ; Send it. Specify additional data to send too. This is required by the Google API: _WinHttpSendRequest($hRequest) If @error Then ConsoleWrite("_WinHttpSendRequest _WinAPI_GetLastError=" & _WinAPI_GetLastError() & @CRLF) ; Wait for the response _WinHttpReceiveResponse($hRequest) If @error Then ConsoleWrite("_WinHttpReceiveResponse _WinAPI_GetLastError=" & _WinAPI_GetLastError() & @CRLF) ; See what's returned Dim $sReturned If _WinHttpQueryDataAvailable($hRequest) Then ; if there is data Do $sReturned &= _WinHttpReadData($hRequest) Until @error EndIf ; Close handles _WinHttpCloseHandle($hRequest) _WinHttpCloseHandle($hConnect) _WinHttpCloseHandle($hOpen) ; See what's returned ConsoleWrite($sReturned & @CRLF) MsgBox(64 + 262144, "Done", "Page source is printed to console") This fails for me under Windows Server 2016, with this error -- _WinHttpReceiveResponse _WinAPI_GetLastError=12175 It works if I comment out the final _WinHttpSetOption line.