Yay! Today, we get one of those keywords that I personally find utterly useless, but it is what it is. 
Let's start by talking about how to decipher that long string of random characters, and try and understand what CVSMBF might actually stand for:
CV -- Convert
S -- SINGLE
M -- Microsoft
B -- Binary
F -- Format
So, what does it do?
It converts a properly formatted string (one stored in Microsoft Binary Format -- which is outdated and obsoleted and thus why I find this to be basically a worthless command, unless one is working with ancient data from the late 70s or early 80s) into a SINGLE precision number.
Let me share an example of this, and its twin function MKSMBF, and then I'll explain a little more about how and where one might use these type commands:
Now you'll notice that I started the above by converting a SINGLE value into a STRING. The reason for this is simple -- I don't know the string representations of the values off the top of my head, so it's just easier to start with a number which I do know how to represent, and then showcase the conversion back and forth.
You'll also notice that, in the example above, I also showcased MKS$ and CVS. These do exactly the same as MKSMBF$ and CVSMBF, with one exception -- they convert to the modern standard SINGLE values and not the antiquated Microsoft Binary Format.
So *WHY* would someone want to convert these values into such odd strings? Why not just use STR$(a!) and be done with it??
STR$() converts a number to a string -- but it basically preserves the formatting of that string. STR$(700.2213) would become " 700.2213" -- an eight digit string.
MKS$ and MKSMBF$ converts a number to a string -- but those strings are *always* going to be 4-bytes in size. The character representation you get is (more or less) going to be exactly the same as that value looks like in memory. (With the exception of MKSMBF which is, as I've said several times, an outdated method of representing the value in memory nowadays.)
123.456789 will convert to a 4-byte string.
1.1 will convert to a 4-byte string.
0 will convert to a 4-byte string.
And why is this 4-byte constant so important for us??
When saving data to the drive FOR BINARY or RANDOM access!!
We can store 100 numbers in a text file, in MKS$ format, and use a total of 400 bytes to store those numbers. Unlike variable length data entries, we can easily access our file and tell instantly where any certain number is in it.
At position 1 in the file is the zero-index number. (Think of my index here as DIM array(0 TO 99), for my 100 numbers.)
At position 5 in the file is the one-index number.
At position 41 in the file is the ten-index number.
At position (p) in the file in the file is the ((p - 1) / 4)-index number.
We convert the value to a set string size, so we can easily track where that value lands inside a larger string or a data file. Set and constant sized data makes data alignment a breeze.
Let's start by talking about how to decipher that long string of random characters, and try and understand what CVSMBF might actually stand for:
CV -- Convert
S -- SINGLE
M -- Microsoft
B -- Binary
F -- Format
So, what does it do?
It converts a properly formatted string (one stored in Microsoft Binary Format -- which is outdated and obsoleted and thus why I find this to be basically a worthless command, unless one is working with ancient data from the late 70s or early 80s) into a SINGLE precision number.
Let me share an example of this, and its twin function MKSMBF, and then I'll explain a little more about how and where one might use these type commands:
Code: (Select All)
a! = 700.2213
Print "Value of a!:"; a!
b$ = MKSMBF$(a!): c$ = MKS$(a!)
Print "Value of a! encoded using MKSMBF$: "; b$
Print "The string above, decoded using CVSMBF:"; CVSMBF(b$)
Print "Value of a! encoded using MKS$: "; c$
Print "The string above, decoded using CVS:"; CVS(c$)Now you'll notice that I started the above by converting a SINGLE value into a STRING. The reason for this is simple -- I don't know the string representations of the values off the top of my head, so it's just easier to start with a number which I do know how to represent, and then showcase the conversion back and forth.
You'll also notice that, in the example above, I also showcased MKS$ and CVS. These do exactly the same as MKSMBF$ and CVSMBF, with one exception -- they convert to the modern standard SINGLE values and not the antiquated Microsoft Binary Format.
So *WHY* would someone want to convert these values into such odd strings? Why not just use STR$(a!) and be done with it??
STR$() converts a number to a string -- but it basically preserves the formatting of that string. STR$(700.2213) would become " 700.2213" -- an eight digit string.
MKS$ and MKSMBF$ converts a number to a string -- but those strings are *always* going to be 4-bytes in size. The character representation you get is (more or less) going to be exactly the same as that value looks like in memory. (With the exception of MKSMBF which is, as I've said several times, an outdated method of representing the value in memory nowadays.)
123.456789 will convert to a 4-byte string.
1.1 will convert to a 4-byte string.
0 will convert to a 4-byte string.
And why is this 4-byte constant so important for us??
When saving data to the drive FOR BINARY or RANDOM access!!
We can store 100 numbers in a text file, in MKS$ format, and use a total of 400 bytes to store those numbers. Unlike variable length data entries, we can easily access our file and tell instantly where any certain number is in it.
At position 1 in the file is the zero-index number. (Think of my index here as DIM array(0 TO 99), for my 100 numbers.)
At position 5 in the file is the one-index number.
At position 41 in the file is the ten-index number.
At position (p) in the file in the file is the ((p - 1) / 4)-index number.
We convert the value to a set string size, so we can easily track where that value lands inside a larger string or a data file. Set and constant sized data makes data alignment a breeze.