You might think this keyword was leftover from TurtleBASIC, but you'd be wrong. It's actually from DOS.

SHELL is a very versatile way to either call a DOS command or run another app while staying in your current program.

SYNTAX SHELL [_DONTWAIT] [_HIDE] [DOSCommand$]

_DONTWAIT means continue on in our program flow instead of hanging until the call or program started is finished or terminated.

_HIDE means don't show the cmd.exe console window.

Hiding the console is usually preferred. If _HIDE prevents the program from launching, try adding cmd /c to the SHELL.

Waiting is useful if the app or DOS function you are accessing needs to pass information back to your program. SHELL "Dir" (and piped to a file - we'll discus piping later...) to get the directory info into the next part of your program, for instance.

So let's continue by discussing some other improvements from when this keyword was used in QBasic.

In Windows 98 and prior, we had to use COMMAND\c with our SHELLcall. command.exe was the command prompt then, but sometime after Windows 98, M$ remade the command prompt, and called it cmd.exe. We then used CMD /c in our SHELL calls. Well, along comes QB64 and guess what, cmd /c, forgetaboutit! We don't need it anymore, well, that isn't quite true. QB64 takes care of the command prompt call for us, but it fails once in awhile. (See the example marked INCLUDE PATH, a few lines below).

QB64 can use long path folder names and file names and SHELL command lines can be longer than 124 characters. (Wiki).

So now let's discuss some SHELL components and common ways to use SHELL:

A QBasic SHELL component we can still use in QB64 is START. START is an alternative to _DONTWAIT, and has one added advantages, switches...

Switches in a SHELL START to another app tell the operating how to launch it.

Commonly used switches:

/min Launch minimized to the taskbar.

/max Launch it full screen.

/p Send any text file called with the app to the printer.

Example: Launch Wordpad minimized to print a text file...

Remember, since we are using START we do not have to use _DONTWAIT in this example.

Apparently somebody tried to get it to write a game for the Atari VCS, so why not try BASIC? The results could be amusing! LoL

https://www.reddit.com/r/Atari2600/comme...the_atari/

A goofy little seasonal graphics demo.   Uses some of the techniques I've been using in my sprite mixer programs and puts them to use.

Well I havent worked on my GUI for a long while. Monthes...

So the other day I randomly got started working on it again.

I tried to totally rewrite it from scratch but didnt get the result i wanted.

So, I thought, why not just take my version that works and simplify the hell out of it.

I rewrote most sections piece by piece, and now the code is over 200 lines smaller.

The windows dont resize or maximize anymore, only minimize, move, and restore back to window.

some of the icons on the desktop launch external applications, some are minimized windows.

all the shortcuts will need to be changed because they are set up for my computer.

also, a few shortcuts are set up to open a file browser pointed at a specific directory.



I tacked on the background image subroutines as an afterthought so changing the wallpaper is all the way at the end of the program.

and adding new shortcuts and windows is at the top.



Here are some screenshots:



















and here is the source:


  os3-2.7z (Size: 148 KB / Downloads: 71)

I started working on the QB64 video+audio format maker I shared at the old forum, adding playback controls, etc.  I want to load images as Hardware images because they seem to display much faster, will allow better frame rates, but when doing that the screen blanks horrible.  Not sure why and what can fix the blinking.  Hoping to discover a solution or I will have to stick when the slower regular way.

I've attached the code and a test QBV file.  As is the video displays ok, but if you comment out line #53 and use #54 instead (hardware images) the screen will blink very badly.  The video is a low resolution one for testing purposes, me playing a short Christmas song on the piano.

Thanks for any help.

- Dav


[attachment=1221]

I thought I'd be nice and post a word today, to give Pete a break for a bit.  (Also, someone asked me about this, and it's just as easy to write an answer here as it is elsewhere.  )

WIDTH -- One of those simple little commands that has been in the language forever and ever.  Going back to the days of GWBASIC, one could always use WIDTH to set the character height and width of a SCREEN 0 screen.  You can see our wiki article on it here: https://qb64phoenix.com/qb64wiki/index.php/WIDTH

Usage has always been rather simple:  WIDTH columns, rows

One keyword, two parameters to set how many columns and how many characters you wanted to print to the screen.  Can't get much simpler than that, now can it??

So, someone asked me, "WHAT THE HECK ARE THE EXTRA TWO PARAMETERS THAT QB64PE ACCEPTS AFTER THAT???"  (And yes, I was asked in all caps, so you know this is a serious question!)

Let me answer this in two parts:

For our Linux and Mac users:  Those two parameters are nothing for you.  They do nothing.  Change nothing.  They're not implemented in either Linux nor Mac.  Set them to whatever you like, nothing is ever going to change.  (At least, not until someone goes in and makes them multi-platform compatible.  At the moment, they only apply for Windows.)

Sorry guys. 

For our Windows users, those two parameters are used FOR THE CONSOLE ONLY.  Unless you use $CONSOLE in your program, they're not going to change anything at all for you either.  You might as well be using a Linux PC, as far as WIDTH and the 3rd and 4th parameter are concerned.

So...  You're a windows user.  Your program uses $CONSOLE.  What the heck does those last 2 parameters do for you?

They set the total width and height of your available console.

For example, let's try the following program:

Every time in the past, when I need to store something to file, I always used a user-defined type and wrote and read the contents to a file using INPUT and OUTPUT. Now starting to design the actual gradebook, I am a little stumped. Naturally, an array sounds useful for something like this. My initial thought is assigning every student a unique ID (UID), unknown to the user but used by me, so if the name changes or something of the sort, we still can line the grades with the proper name.

So, the thinking is UID, Grade or mark, and notes. I am not overly experienced using multi-dimensional arrays. Is there any issues resizing them using REDIM PRESERVE. Is there a better idea for keeping and using this information or storing it with INPUT/OUTPUT won't be overly taxing since I would have to overwrite the file every time I make an update? Using RANDOM sounds like I have to make all these decision on the front-end... I guess I am just looking for a nudge in the right direction since I am kinda inexperinced with this type of programming 

Thanks y'all

This is a QB compatible language for programming microprocessors. I have been using it for some time and can recommend it for its (relative) simplicity. So if you want to move on from arduinos (who likes C anyway) you can write you own controller programs in BASIC. As far as is possible it has the same instructions as QBasic.
I have attached my latest project. It reads the outside temperature (via a rf link) and displays it on an analog dial gauge. I got the enclosure from a charity shop.

Ever wish we could travel the world on a transporter beam? Well, we can't, so for now, let's stay home and play with COMMAND$...

SYNTAX: cmd$ = COMMAND$[(count%)]

USE: Passing arguments to other apps and drag and drop applications.

And as a bonus, if you act now, we'll throw in _COMMANDCOUNT to evaluate that count% variable.

Okay, let's get our demo of the day going...

Works for Windows, untested for Linux or Mac...

From the thread here, I had a couple of people message me about NOT and why I mentioned it was an oddball in the Order Of Operations (OOO).  Let me see if I can explain this simply, without confounding the issue..

Exponents are one of the first things we solve in our OOO.  Right?

And NOT is down near the end of our OOO.  Right?

So following those rules, write a program to parse and solve: 1 ^ NOT 2 ^ 3 AND 4

???   <-- Now how the heck DOES it calculate that???

The odd secret is NOT is both calculated FIRST, and near the LAST of our OOO.

Here's the trick I learned:  Put a beginning parentheses BEFORE your NOT, and the ending parentheses before any binary operators like AND, OR, EQV...

1 ^ NOT 2 ^ 3 AND 4 gets solved as:  1 ^ (NOT 2 ^ 3) AND 4

1 ^ (NOT 2 ^ 3) AND 4 makes sense to us.  Do the parentheses FIRST, even if NOT might be evaluated down low on the OOO.

You can't just say, "Solve it last," as sometimes, such as in this case, you have to solve it first before you can do the other operations.  1 raised to the WHAT power?   The (NOT 2 ^ 3)rd power!

Put a beginning parentheses BEFORE your NOT, and the ending parentheses before any binary operators like AND, OR, EQV.  <-- That's the rule for parsing and solving NOT properly.