Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Teach me fast
#1
Question 
bplus gave me an idea with a thread going on in his sub-forum:
https://qb64phoenix.com/forum/showthread.php?tid=1693

I'm too lame to create a topic on "Keyword of the Day" like Pete or Steve could, so it will have to be constrained to this topic. These are a few tips for people just getting started with QB64.

If there are still any doubts about using keywords, statements, variables etc. in this programming language, there is always the QB64 Wiki or Terry Ritchie's tutorials within easy reach.

Anyway, the first topic within topic here is CHR$(). The synopsis is:

Code: (Select All)
onechar$ = CHR$(bytenum)

onechar$ = return value = a one-byte string
bytenum = first parameter = a number from zero to 255.

Note "bytenum" has to be an _UNSIGNED _BYTE. Trying to go less than zero or higher than 255 creates an "Illegal function call" runtime error message. Do not use ordinary _BYTE variable as first parameter to this function, even if you don't intend with your programming calculations with going over 127. Suddenly the value could wrap around and you would be stung for it, and it could be difficult to debug. To be absolutely safe, declare a variable AS INTEGER to use as the parameter of CHR$().

This function is very necessary to produce the double-quotation mark, which is CHR$(34).

It is also very necessary for creating a few control codes such as the "newline" characters. On Windows it's CHR$(13) + CHR$(10) which is two bytes. On Linux it's only CHR$(10), and on MacOS it's only CHR$(13).

There is much more. The "bytenum" is an ASCII code which could be looked up inside the QB64 IDE: Tools menu --> ASCII chart (first option).

Some people would like CHR$() to return more than one byte. "Freebasic could do it!" Well this is not Freebasic, and therefore it will require a workaround. It has been said that a function like "printf()" in C is needed for this but it's impractical in QB64 at this time. Therefore I have provided a function that is a compromise.

There are two caveats. The parameter must be provided as a string list in which the ASCII codes have to be separated by semicolons. If you prefer to change the delimeter to comma then the two lines with INSTR() have to be changed. This function purposely blocks CHR$(0) for safety reasons. If you feel you need that, such as for re-creating a WAV file header, you could make edits toward "v = 0". Whatever value in the list this function cannot pick up as an integer, it tries to convert to hexadecimal.

Code: (Select All)
FUNCTION chrs$ (acode$)
DIM a$, b$, v AS _UNSIGNED _BYTE
DIM AS LONG z1, z2
IF acode$ = "" THEN
    chrs$ = ""
ELSE
    a$ = ""
    z1 = 1
    z2 = INSTR(acode$, ";")
    DO
        IF z2 = 0 THEN
            b$ = MID$(acode$, z1)
        ELSE
            b$ = MID$(acode$, z1, z2 - z1)
        END IF
        v = VAL(b$)
        IF v = 0 THEN v = VAL("&H" + b$)
        IF v > 0 THEN a$ = a$ + CHR$(v)
        IF z2 > 0 THEN
            z1 = z2 + 1
            z2 = INSTR(z1, acode$, ";")
        ELSE
            EXIT DO
        END IF
    LOOP
    chrs$ = a$
END IF
END FUNCTION

Examples:
Code: (Select All)
PRINT chrs$("72;101;108;108;111;33")
'produces "Hello!" (without double-quotation marks)
PRINT chrs$("222;219;219;219;219;221")
'produces a thick bar on QB64 screenie. Don't recommend printing this on a Linux terminal which is not Unicode ready.
PRINT chrs$("32;ba")
PRINT chrs$("cd;ca;b9")
'produces a two-line picture of an interesting double-line pipe, on QB64 screenie.
Reply




Users browsing this thread: 2 Guest(s)