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.
Fairly straight forward, the Powershell code was fundimentally just
calling Shell_NotifyIcon under the covers which we can easily do
ourself. The notification has to be tied to a window, so I simply create
a hidden one to use.
A nice improvement here is that instead of having to use the Powershell
icon we can make use of the EXE icon if one was provided. If one is not
provided then we use the default 'application' icon.
tinyfiledialogs had lots of issue surounding the quoting of the
arguments to the dialog functions. The arguments are effectively placed
verbadim into shell commands, and without any proper treatment they
would get accidentally evaluated by the shell, which is a big problem.
Additionally, any arguments containing quotes would just not work since
they would screw up the underlying shell command.
This change fixes all that for Linux. Every argument to the dialog
functions is now surrounded in single quotes, which prevents any
evaluation of the string by the shell. Additionally, because this is
standard the only chracters that need special treatment are the single
quote characters, and proper escaping for them has been added. The
result is that the dialog functions can now accept arguments that hvae
single and double quotes in them (on Linux).
Unfortunately InForm code calls this function directly via
`DECLARE LIBRARY`. For the moment we're adding it back in to keep those
programs functioning, in the future it may be removed.
I broke this by accident in 5031de2, likely by misreading the $0. What
the line was intended to do was change to the directory the script is
located in when the script starts, this allows the script to be started
from any location.
Typically this isn't necessary functionality, but for Mac OS it's
important because if you double-click the script (the typical way to run
it) it is started from the user's home directory. Due to this I also
updated the Mac OS distribution test to run the script in this way so
that it's closer to how a user will run it.
Fixes: #218