While working with _MEM blocks and freeing them, it occurred to me that perhaps it would be a useful alteration to have _MEMFREE work similar to the new DIM syntax, where one can:

DIM AS INTEGER a, b, c, etc.

Where instead of the required syntax following:

_MEMFREE m
_MEMFREE m2
_MEMFREE m3

One could do:

_MEMFREE m, m2, m3

Would there be any interest in such a change, or would that be too difficult of an implementation?

Now, as I mentioned in the topic Come chat with me! (qb64phoenix.com), I told you guys I was going to share the HOST part of the program which we were all using to play around and chat with yesterday -- and try to highlight the steps necessary to get it to run properly for everyone.

First, let's start with the code.  We'll begin with the HOST version of my Mini Messenger (qb64phoenix.com):

I am running this program to play with the mouse, just playing with things to understand it before trying to imbed it into something else.

Ever want to be able to see the ASCII characters that do things like eject the printer paper, CHR$(12)? Well with the keyword _CONTROLCHR OFF, you can! And if you act now, because we can't do this all day, we'll throw in _CONTROLCHR$ ON at no extra charge. Just pay separate shipping and handling.

SYNTAX _CONTROLCHR {OFF|ON}

I would like to perform a test.
I would like to know if the output of the directory is the same for every language? Also what happens with date/time? And is the distance to the file name the same per language? I use Windows 10 (BE-NL) system. And what about Linux and iOS?

Not to be confused with _BREXIT, which was a useful keyword to get the hell out of the E.U., _EXIT is a useful keyword to get you out of trouble if you mistakenly click the "X" symbol before parts of your app have completed, like writing to a very large file.

SYNTAX:  var% = _EXIT

Values are as follows...

Hi,

I wrote this simple drive display function which is not that large.

It works in QB64 and uses library function GetDrivetype.

My question was:

  Id there a equivalent QB45/71 function to return drive type
  such as [cdrom] or [removable]??

Thanks, Erik.

Attached Files

  DRIVEX.ZIP (Size: 151.81 KB / Downloads: 43)
  DRIVEX2.ZIP (Size: 195.62 KB / Downloads: 31)

You must have seen a picture that is made up of many small pictures.
The program is simple. Just give him a single image at the beginning of the source code! (boss_pic$)
To create such a picture, you need a lot of pictures so that you can work with as many different shades as possible.
Specify where the program should search for images. A drive or folder.

The program will scan your computer and look for image files. Unfortunately, I think this will only work under Windows, because a 'CMD' command generates a list of found images.
After that, the program examines the color shades of all found images and stores them. Peace of mind! The program does not make any changes to any files! You don't put any garbage anywhere!

It took 5,000 pictures in 2 minutes, but I mostly have small pictures on my computer.

After the examination, he creates the mosaic image.
You only check the images once! You don't have to wait every time you start the program. It performs a new test if we change the search location for the images (file_search$) or change the aspect ratio of the mosaic images (ratio_y_start).

The higher the quality of the finished image, the more images the program can work with.

after running the program, the image is automatically saved as "saved.bmp".

during the examination, you select images that are close in shade to another existing image. This prevents the repetition of images.

use the available images proportionately during the work. that's why it randomly creates the mosaics so that there are no more identical images next to each other

There's a catch... Of course virtual, not manual and it has to work in Linux and MacOS.

Okay, so in Windows we can use a WinAPI trick to min/restore a Window, which will "Activate" the window. Activate means it is not just in focus, it is also ready to use. With QB64, we can do a _SCREENCLICK to virtually activate it, just as if we clicked it! Oops, problem here is _SCREENCLICK, and other keywords like _SCREENPRINT, etc., are not supported in LInux and MacOC.

So the challenge is to replace the _SCREENCLICK line with something else (number of lines doesn't matter) that will have the same effect to activate the window.

So to try, you need to...

1) Copy and run the first and then the second snippet, in that order. They'll use the CLIPBOARD to message between the two windows. 

2) Adjust the windows on your desktop so they don't overlap.

3) Click the first program window to initially activate it.

4) Input a test message (Type and press Enter).

5) Notice the second window "Self-Activates" and displays the message received.

6) Input a reply.

7) The first window self-activates, displays the reply, and you are ready to input another message. It's like a ping-pong effect!

So the challenge is to sub out _SCREENCLICK with any line of code or sub-routine that will work in Linux / Mac OS to do the same effect, "activate" the window so we don't have to click on it.

This challenge is based on a much more polished chat app / messenger in this thread: https://staging.qb64phoenix.com/showthre...n=lastpost

If you solve it, you be the hero of the Linux/Mac community, literally billions upon billions of brain cells will thank you.

Program one, the host...