01-12-2023, 04:06 PM (This post was last modified: 01-12-2023, 07:17 PM by SpriggsySpriggs.
Edit Reason: Fixing link to new release post
)
Ah! I forgot to mention that I updated the Odysee channel with the release information from GitHub. I plan on trying to make a video showing off the new features this weekend, but I might be losing water at my house due to maintenance. We shall see!
01-12-2023, 05:39 PM (This post was last modified: 01-12-2023, 05:40 PM by a740g.)
(01-12-2023, 04:06 PM)Spriggsy Wrote: Ah! I forgot to mention that I updated the Odysee channel with the release information from GitHub. I plan on trying to make a video showing off the new features this weekend, but I might be losing water at my house due to maintenance. We shall see!
(01-12-2023, 04:06 PM)Spriggsy Wrote: Ah! I forgot to mention that I updated the Odysee channel with the release information from GitHub. I plan on trying to make a video showing off the new features this weekend, but I might be losing water at my house due to maintenance. We shall see!
I just noticed a small thing in the IDE.
When the IDE is busy checking the program code, it would be nice if the progress was shown in the status bar.
But this is only the case if I interrupt the test with F5.
(01-12-2023, 07:29 PM)Spriggsy Wrote: Isn't there already a small progress bar?
I never noticed anything.
Earlier in QBasic and Qickbasic there was one.
With larger programs, or when inserting somewhat larger sound files, the check can take a little longer
last. It would be nice to see how the progress is.
(01-12-2023, 08:59 PM)Steffan-68 Wrote: Earlier in QBasic and Quickbasic there was one.
With larger programs, or when inserting somewhat larger sound files, the check can take a little longer
last. It would be nice to see how the progress is.
But it was an interpreter doing the work. Cannot wait even a few seconds and thinking that the IDE froze? Then launch QB64PE from the terminal. But it wouldn't include when a program is actually being compiled and linked.
Something QuickBASIC didn't do that QB64(PE) does: darken the IDE while a program is being compiled to executable. That could be unsettling because there is no way to know if this is the first time, since system restart, that MinGW was launched, or "g++" and company on Linux. So trying to display a progress could leave a 100% much longer than an user is willing to tolerate. Take it from updating the operating system, no matter which one.
If you want features that were far beyond what could be achieved in 16-bit then you will have to wait a few seconds per compilation for it. It doesn't bother me, because there was always a hold longer than it was expected in QuickBASIC. After I got ahold of QB64 around 2009 I didn't like how it held when bidding it to compile, and therefore I resumed using QuickBASIC because it was overwhelmingly for processing text files, something that today I could use Lua for.
01-13-2023, 01:37 AM (This post was last modified: 01-13-2023, 01:49 AM by Steffan-68.)
As you can see from my screenshot, the % specification is available, but it is not always displayed.
Since I'm on vacation and my laptop isn't the fastest, I just noticed it.
At home on the PC it's not so bad because it's fast enough.
But there will also be others who don't have such a fast pc. It is sometimes difficult to distinguish whether the IDE is working or has hung.
As an example I loaded a program with 1 integrated MP3 and made a few changes, the check through the IDE took about 20 minutes on my laptop. The % display would have been very pleasant.
I only got it when I pressed F5 to run the program weren't the check.
(and some other functions) on Windows only require a KeyDown event on the console, not a full keypress. That's why the program ends when you're holding down F5, even though you pressed the F5 key while focused on QB64 the console still receives a F5 KeyDown when it goes in focus.
Personally I don't think I like that behavior, and also it doesn't match what you'd expect or the other platforms (In particular it means whatever you type will end up as input to something else afterward, since we don't actually read the key in). I'd rather it just wait for the full keypress before ending the program, it would make it much harder to close by accident.
![[Image: Manual-Quick-Basic4.jpg]](https://i.ibb.co/0C9rZXz/Manual-Quick-Basic4.jpg)
