QB64 v1.4 released

[odin]

 [ You are not allowed to view this attachment ]

Get the latest version from https://github.com/QB64Team/qb64/releases/tag/v1.4

Changelog available at https://www.qb64.org/portal/changelog-of-v1-4/

[RhoSigma]

Hooray,

once again congratulations and a big THANK YOU to all main developers and contributors for your everlasting efforts into the QB64 project.

Maybe you may want to update the changelog a bit, mentioning that the support for &B prefixed numbers was enhanced, so those numbers are now also possible in DATA lines and can also be read by INPUT (from file & keyboard).

[FellippeHeitor]

That's true, Rho! Sorry about that. I'll be adding it in a few moments.

Edit: added "Enhanced support for &B prefixed numbers, so the notation can now also be used in DATA lines and read by INPUT (from file & keyboard)."

[RhoSigma]

Thanks Fellippe,
did some more proof-reading. You should also review the 3rd paragraph of the changelog, as version 1.4 is finally out now, it sounds ugly to mention that you can "already" test the new version in the dev builds :)

another thing is on the QB64.org main page:
The entry Latest Version in the Downloads dropdown menu still links to version/release 1.3, all other v1.4 related links work as expected.

For completeness v1.3 should be added to the Historical Versions, although it is available at the GitHub releases page too. To save webspace, you could simply add the "old" Latest Version link to the historical list, instead of copying the v1.3 archive over to QB64.org.

[FellippeHeitor]

Thanks for the remarks, I'll be tackling those now.

The historical versions page will indeed link to the 1.3 release, as it'll remain available on GitHub.

[Qwerkey]

1.4 installed and working.  My (free) virus-checker AVG didn't like it to start with: said QB64.exe was ' a very rare' file and went off to spend some time checking it offline, then reported back later that you're now added to the datebase of safe software.

[FellippeHeitor]

❤️

[doppler]

It's nice to see all the little and not so little things become the next release V1.4

After reviewing the change log.  It's easy to conclude not much changed, but you would be sorely wrong in that way.  A lot of thoughtful improvements have occurred worthy of being call V1.4.  Most of the changes improved IMHO were for the mostly often orphaned CONSOLE window.  It's now an important feature and tool for the bag of tricks.

I would be at a loss to even know what V1.5 should focus on next.  I would love to say more built-in interfacing with windows system DLL calls.  But that would leave out the MAC and Linux audiences.  And I am loathed to even suggest an IDE per-compiler command to turn on branched Windows/Linux/Mac system interface calls.  Maybe a tool bag of tricks, to be sanctioned as an $INCLUDE command for each system.  Right now it's find and include tricks found in the forum.  Relying on published programs and solutions to questions is not easy, if you don't follow the forum all the time.  Just a suggestion now.

[Qwerkey]

And I am loathed to even suggest ...

No, you are not loathed but highly admired.  Just a little correction of English:

"I am loth to do something" means that I am reluctant (it is possible to spell the word "loath", but better sticking to "loth").

"I am loathed" means that people hate me.

Pronunciations: "loth" the "th" is as in "both", loathe the "th" is as in "the".

You see that I have nothing useful to say about programming.  I am loth to add anything to that subject!

[SMcNeill]

And I am loathed to even suggest an IDE per-compiler command to turn on branched Windows/Linux/Mac system interface calls. 

Isn’t this what the $IF precompiler statements do for us, already?

$IF WIN THEN
    ‘Do windows stuff or link to windows libraries
$ELSEIF LINUX THEN
    ‘Do linux stuff and link to linux libraries
$ELSE
    ‘Do Mac stuff and link to mac libraries
$END IF

[doppler]

No I was thinking along the lines of a single command which would compile differently.  A comand to determine a window handle number.  Would be the same command (WHANDLE) but use the different system calls.  x=WHANDLE, x would always come back with the handle regardless of the OS system.  This would be very limited to common usage across all OS's.  re: Much like what WINE does for windows programs on Linux.  There very well maybe limited common functions across the OS's.  I never played with MAC so I can't be sure of anything.