This effectively adds Http support to QB64-PE via adding $Unstable:Http
which will trigger building with DEP_HTTP, which enables Http support in
libqb.
Modifies libqb.cpp to add support for opening HTTP connections via
_OPENCLIENT(). This makes use of the libqb_http API in ./libqb, which is
backed by libcurl.
This also includes a bit of refactoring for some of the code that
required additions. I replaced a few of the integer values with enums,
and added a new entry for Http and then implemented it in all the
necessary locations. In addition to `_OPENCLIENT()`, there is also
support for using HTTP connections with `EOF()`, `LOF()`, `GET #`
(variable and fixed length), and `CLOSE`.
I additionally fixed an issue of parsing the colon parts of the
`_OPENCLIENT()` parameter, where having too many colons would cause the
program to crash. Since we only allow so many parts to begin with it I
simply limited the max number of parts it will split to 10.
Fixes: #98
Fixes: #46
This adds the libqb_http API, which is designed to support HTTP and
HTTPS usage from QB64-PE source.
The design consists of a single thread which services all the HTTP(s)
connections. There are then various libqb_http APIs exposed that allow
interacting with this thread to create a new connection, query
connection status, read data, or close the connection.
Internally the thread makes use of the curl_multi interface to allow a
single thread to service multiple HTTP(s) connections in parallel. This
means you can _OPENCLIENT() multiple HTTP connection in a row and all of
them will be serviced at the same time in whatever order data is
available.
HTTP is optional and selected via a Makefile setting. A stub is swapped
in if HTTP support is not used, which avoids need to add another build
flag to libqb.cpp.
The 'New Dialogs' menu option was renamed to 'GUI Dialogs' to better
explain what it does. Additionally the setting of which dialogs to use
is saved to the config.ini file so that it presists across multiple runs
of QB64-PE.
We were incorrectly treating the empty string and NULL the same and
using a password dialog for both. It now has the correct behavior of
displaying the password when provided the empty string, but just
displaying a blank input box when provided NULL.
It seems we weren't including stdint.h on Windows by mistake. Likely we
were getting it anywy from some other header, but it sounds like that
got changed in newer versions of MinGW and either way we shouldn't rely
on that.
Being that we include stdint.h on all platforms, I also changed os.h to
always use these types when defining the `int32` and friends sized
types. Ideally we get rid of those defines in the future but we can at
least use the stdint.h types going forward (as we already have).
This applies various dialog settings so that the dialog is always on
top, and also so that Tab works as expected to move between the
controls. The Edit control is moved first so that it's focused when the
window appears.
Currently we have two different ways of determining what Window handle
to tie our dialogs too - we either use GetForegroundWindow(), or create
a completely new and hidden handle. The associated window determines
what process names shows up on notifications, and also which window
can't be interacted with while a dialog is open.
Both of those approaches aren't really good. In the case of
GetForegroundWindow(), it just returns whatever window the user has in
focus, which might be a completely different process. With the hidden
window, it means the dialog and notification aren't really tied to the
QB64-PE program, so you can still interact with the window even when a
dialog is open, and the notification doesn't show an exectuable name.
To solve this we're now using EnumWindows() to enumerate over all the
Windows on the system and find one associated with our ProcessId. We
then check if it's the top-level window and return it if it is.
If that process fails to find a window (such as if this is a
console-only program, or $SCREENHIDE is used) then we check if
GetConsoleWindow() gives us a handle and use that.
If neither approach works, then we fall back to creating a hidden window
so that the dialogs can still work.
Functionally it doesn't matter what kind of images we store for the
tests, as _LOADIMAGE() will open them exactly the same. png however has
the advantages of being substantially smaller, and also viewable
directly on GitHub in PRs, making them easier to review.
I accidentally declared these as uint32_t even though I store -1 in
them. It was working anyway due to the implicit conversion that happens
when adding it to an int32_t, but it should be fixed regardless.
The border color parameter to PAINT is optional, but sub_paint was not
handling that case. What it should do in that situation is keep painting
until it finds pixels that are not the same color as the original
starting pixel was. Instead it would simply assume border color was
valid and paint until it finds color zero (the default parameter value
when it's not provided).
This was originally reported in QB64Official/qb64#2, and Walt
(@TheJoyfulProgrammer) fixed it in QB64Official/qb64#38. Functionally
this is the same change, however I'm checking `passed & 4` to see
whether a border color was provided rather than `bordercol == NULL`.
The later has problems if the provided bordercolor is zero, which is
allowed since zero is a valid color. The `passed` argument indicates
which of the function arguments were actually provided in the QB64
source that called PAINT.
Additionally, along with the `while (true)` loop that Walt changed I
went ahead and removed the duplication of the sections for each
direction. We now just use a couple of arrays to determine which
direction we're checking and loop over all 4.
A function was made unnecessary but wasn't removed, triggering a
warning. Additionally gcc likes parenthesis around `=` assignments used
for conditions.
Fairly simple, this sets the ES_PASSWORD flag when the default text is
blank.
Additionally I fixed the dialog callback to correctly call EndDialog()
rather than DestroyWindow().
These are the last of the quote checks, these don't require any
associated changes as the underlying Win32 functions already allow
quotes. They were simply added to keep parity with the functionality on
other platforms, that that has since been fixed.
This removes the VBS based InputBox for Windows and replaces it with a
version that uses DialogBoxIndirect to create the dialog. While it is a
bit more complicated in some respects, it removes any concerns about the
contents of the strings as they're no longer being inserted into the
generated script.
It also has the advantage that it doesn't spawn another process (which
then shows up in the task bar in some situations).
With this changes quote characters are allowed in all of the parameters.
Escaping the osascript commands requires two layers of escaping: One for the
script itself, and one for the sh arguments.
For the script itself, we simply have to escape the " character with \". When
then take the result of that and escape it sutably for sh arguments in single
quotes. We already have a function for that so we simply call that to do the
job.
