QB64-PE v4.2.0 is now available

[RhoSigma]

Download v4.2.0 here

Enhancements
- #614, #615 - Audio updates and cleanup - @a740g
  - Adds sample rate support to [_SNDNEW](https://qb64phoenix.com/qb64wiki/index.php/_SNDNEW).
  - Moves all information, warning, and trace logs to use our new logging features.
- #626 - Support for using System MinGW on Windows - @a740g
  - Adds support for using a system-installed compiler on Windows, such as a pre-existing MinGW toolchain (from MSYS2, Winget etc.). This can be helpful in situations where the user either cannot or prefers not to use the compiler bundled with QB64-PE.
  - This feature is available exclusively on Windows, a respective checkbox for switching is shown in the "Compiler Settings..." dialog under the "Options" menu, a clear warning is displayed when this option is enabled to ensure users understand the implications.
- #630, #634 - IDE Help System improvements - @RhoSigma-QB64
  - Added/fixed some Unicode char replacements.
  - The "Update All Pages" download process now excludes the mostly static _GL command pages, i.e. 337 files less to fetch, which saves us 2-3 minutes time.
- #635 - Add Windows on ARM support, closing issue #313 - @a740g
  - Enables full native support for QB64-PE on ARM-based devices, such as Windows devices using Qualcomm Snapdragon and macOS systems with Apple Silicon SoCs.
  - Eliminates reliance on runtime emulation (e.g. the Windows Prism x86 translation layer), enabling significantly faster startup times and improved execution speed.
  - The pre-compiler will set the `_ARM_` flag and the `_OS$` function return contains the string "[ARM]" when using QB64-PE on the ARM architecture.
  - On ARM architectures, the `_FLOAT` type is not natively supported due to the absence of x86-style 80-bit x87 FPU. This may lead to compatibility issues or reduced precision. Consider using `DOUBLE` or `SINGLE` for cross-platform consistency.
  - The [VAL](https://qb64phoenix.com/qb64wiki/index.php/VAL) function previously returned values as `_FLOAT` by default. Users can now explicitly specify the target numeric type such as `SINGLE`, `DOUBLE`, or an integer type via the optional `numericalType` parameter, improving type control and cross-architecture compatibility.
- #641 - Adjustments to Windows set-up scripts - @SteveMcNeill
  - Replacing `wmic` with PowerShell equivalent.
- #642 - New dialog for easy logging configuration, closing issue #576 - @RhoSigma-QB64
  - Access the dialog via the menu "Run -> Configure logging...".

Library Updates
- #635 - Update libcurl to v8.14.0 - @a740g
- #640 - Update libxmp-lite to v4.6.2 - @a740g
  - Also, the clip, miniz, tsf, qoa, qoi source files were updated to the latest releases.

Bug Fixes
- #615 - Fix auto-formatting of _MEMPUT AS TYPE & _MEMFILL AS TYPE - @RhoSigma-QB64, @a740g
  - The case of the given variable type names was not adjusted according to the active keyword formatting (UPPER/CaMeL/lower).
- #616 - Fix _MOUSEX and _MOUSEY when the mouse pointer is hidden on macOS - @a740g
  - This partially reverses the approach taken in #602. Using `CGAssociateMouseAndMouseCursorPosition()` was a mistake - it fixed `_MOUSEMOVEMENTX` and `_MOUSEMOVEMENTY` for FPS-style camera movement but broke `_MOUSEX` and `_MOUSEY` by preventing GLUT from triggering the `glutMotionFunc` callback while the mouse pointer was hidden.
  - To address this, we now use `CGEventSourceSetLocalEventsSuppressionInterval()` to work around macOS’s 0.25-second event suppression. However, this means `_MOUSEMOVEMENTX` and `_MOUSEMOVEMENTY` remain broken because macOS generates artificial movement events when `glutWarpPointer` is used.
  - For now, this is an acceptable trade-off. A proper long-term fix depends on implementing #608.
  - Many thanks to `NakedApe` from the QB64-PE forum for pointing out the issue. See [this](https://qb64phoenix.com/forum/showthread.php?tid=3290).
- #627 - Fix IDE error when loading large source file - @FellippeHeitor
  - The IDE would crash when a large source file was loaded and the syntax highlighter had to build the list of sub/functions on its own, due to errors in the loaded file preventing compilation from going through.

Full Changelog: https://github.com/QB64-Phoenix-Edition/...0...v4.2.0

[NakedApe]

Sweet! Thanks, amazing dev team, for all your time and effort

[zaadstra]

Thank you all!  Now quickly check out the new goodies 

[a740g]

@NakedApe - sorry, this one took a while. But this has the macOS fix for the mouse. So, it should work with your game.

[NakedApe]

Thanks again, @a740g! I'm psyched to try out the new version.

[RhoSigma]

Another side info,

I'll also update my Notepad++ integration pack shortly, which is then based on the current stable Notepad++ release 8.8.1, so if you not already did, you may want to update your N++ now too so that the new pack perfectly blends in and can be used without troubles.

EDIT: Update is now ready https://qb64phoenix.com/forum/showthread.php?tid=86

[doppler]

I am happy to see we did not loose Fellippe as a provider.
"- #627 - Fix IDE error when loading large source file - @FellippeHeitor"

I am re-posting a little up-grader program from long ago I made (version qb64pe 3.x something).  To assist in times like now, when a new version arrives.
This a multi-file drop program.  Collect all your EXE's and drop into the program window.  Then open a command prompt window run the doit.cmd script.

I only assume your source files are in a qb64pe directory sub folder.  In my case it's qb64pe\my programs.  If not it's an easy tweak, start with lines 13, 20 and 21.
I hope you find this useful, it saves me from individual compiling of dozens of programs.
P.S. don't recompile qb64pe and qb64pe bas upgrader  and if you get a "hit any key to continue" just doit.  Not sure why but it happens, really shouldn't.

Code: (Select All)

_Title "QB64pe Bas Upgrader v1.0"
Width 80, 10
_ScreenMove 10, 10

Cls
'
' I always use q$ to use quotes, just how I am
Q$ = Chr$(34)
'
' define where sources are  <<< change variable to your directory >>>
' remember to slap a "\" to your source path end
'
source$ = "My Programs\"

'
' get home path
' noramlly this would be in the root of qb64pe
' screwy things could happen if it isn't
'
hp$ = Command$(0)
hp$ = Left$(hp$, _InStrRev(hp$, "\"))

' assume homepath + source is one path from here on out.

ChDir hp$

_AcceptFileDrop 'enables drag/drop functionality
Print "Drag the EXE file(s) and drop in this window... or x to exit"

Do
    _Limit 3
    x$ = InKey$
    If UCase$(x$) = "X" Then
        Cls
        Print "I don't plan to open a command prompt"
        Print "for you.  doit.cmd script is in " + hp$
        Print "folder. You can examime / execute / observe."
        hitenter
        System
    End If
Loop Until _TotalDroppedFiles <> 0

Open "doit.cmd" For Output As #1

Do
    Print
    f$ = _DroppedFile
    If f$ = "" Then Exit Do
    '
    ' take out all path info and test for source available.
    ' also scrap off extention
    '
    f$ = Right$(f$, Len(f$) - _InStrRev(f$, "\"))
    f$ = Left$(f$, Len(f$) - 4)
    Print "Using "; f$
    '
    ' ok do we have source bas ?
    '
    If _FileExists(hp$ + source$ + f$ + ".bas") = 0 Then
        Print "Sorry I can not compile the above file. The source does not"
        Print "exist in paths provided. Suggest exclude the file(s)"
        Print "next time in selection and drop again."
        hitenter
    End If
    '
    ' if you got this far a doit.cmd line can be generated
    '
    Print #1, hp$ + "qb64pe.exe -c " + Q$ + hp$ + source$ + f$ + ".bas" + Q$

Loop

Close
'
' another chance to do over or exit
'
Print "doit.cmd created and closed"
Print "Hit enter, followed by x"
Print "to exit or drop files again"
hitenter
Run

Sub hitenter
    Input "Hit <enter> to continue "; bad
End Sub

[Kernelpanic]

Another outstanding piece of work! As recognition I like to invite the team to a small snack: 

[Elzaimer]

Hello 
When I launch the 4.20 version, the first F5 (compile and run) is much slower than before (more than 10 sec on my computer). 
But all the following  F5 are ok (3 sec).

With 4.10 version I always had 3 sec. 

Have you the same issue ?

[a740g]

On first launch, when you hit F5, QB64-PE compiles several internal libraries required by your program. This only happens once per feature set. So, the delay you're seeing depends on what your code uses.

For instance:

• If you use SOUND, the audio libraries will be compiled.
  
• If you use _LOADIMAGE, the image libraries will be compiled.
  

Not all internal libraries are built on the first run - only the ones your code references. That's why the initial compile is slower, but subsequent runs are much faster.