When looking over the registered commands and function list in file \source\subs_functions\subs_functions.bas I found a command, which obviously never got real public attention.

It's _FPS, either be called with a SINGLE number designating the desired fps in the range 1-200 or the keyword _AUTO. The command gets not syntax highlighted yet, has no help page in the IDE nor a Wiki entry or anything else.

After deeper investigation I found, that it was first available in v1.0 build 51. It's purpose is to set the maximum frame refresh rate of the _AUTODISPLAY mode. While this is working for given numeric values in the valid range, the _AUTO keyword otherwise is just resetting it to the regular 30fps, but according to the comments in libqb.cpp it was planned, that the _AUTO mode should also dynamically adjust the refresh rate depending on the current CPU load, which obviously never got implemented.

I'm currently fixing stuff, also taking the opportunity to improve things.

Need to know if the following code works on all QB64 supported platforms, but I've only Windows systems to test on, so this is a call on all Mac/Linux users.

The following code does expand a relative path into a fully qualified absolut path, it works on Windows 32- and 64-bit, but what about Mac/Linux?

On Windows:

When I save a website in Firefox, eg. the QB64 Wiki Main page (Menu: File -> Save As / or respectively Ctrl-S), then Firefox does create a .html file with the actual site contents and a folder which contains all files (such as linked images, css etc.) required to properly show that site offline.

This .html file and the respective folder are linked in such a way, so that every action done to either in the Explorer does automatically do the same with the other. Ie. if I select the .html only and delete it, then it will automatically delete the folder too. If I move the folder to a new location, then the .html file will automatically follow that move. Same with copy.

Now I'm curious how this connection is done, as I could really use this feature for one of my programs. I looked at the properties of both, the .html and the respective folder, but there is nothing obvious telling how it's done.

The MKLINK command line instruction does not do this type of interconnection, and searching the internet for things like "file/folder interconnection", "file bindings", "file/folder link" and several similar phrases do not show up any useful stuff, but points always back to the MKLINK type linking.

So somehow this .html file and the folder must be magically connected, so that every action done on the one, does magically trigger the same action for the other. Is anybody here who could point me into the right direction?, maybe our WinAPI Guru @SpriggsySpriggs?

Any way to do such connections would be acceptable, SHELLing command line, powershell, vbs or even making a C-header directly using the WinAPI.

This is a mini-version of my BinClock screen blanker. I made it to replace the old windows sidebar.exe based Clock, which is not available on Win10 anymore.

However, I mainly post it here to showcase how to achive antialiasing in QB64 programs by using Gauss or Average blurring filters.

Note you also need my Libraries Collection for this (see signature) and if you're not on Windows, then you may have to change the LOCALAPPDATA environment folder, which is used to save the current clock window position.

You may change the month abbreviations in lines 77-79 and assemble the date format (d$) in line 144 for your country if you want to.

Feel free to play with different filters in line 166 (see QB64Library\IMG-Support\docs\imageprocess.bm\ApplyFilter.html for available filters), the magnifying glass may help you to inspect the effects in detail.

I'am currently working on a fix for Github issue #124 to allow type suffixes for numeric values in DATA/READ constructs. However, the current implementation does impose some limits, so I'd like to ask for some opinions on how far the implementation of type suffixes should go here.

In general there are two very similar functions in libqb.cpp called "n_inputnumberfromdata" and "n_inputnumberfromfile". The interresting thing here is, that the "file" function simply ignores any invalid chars, where the "data" function will throw an "Syntax Error", so my first thought was just to ignore those conditions for the "data" function too, but the second thought was: Wait a moment!! - A file may usually be seen as an external 3rd party resource not under control of the application developer, hence it is absolutely legitimate to just ignore any misformatted file data and try to interpret the read number as good as possible (best guess). - In DATA/READ constructs otherwise the application developer can be held responsible for any nonsense he enters into the DATA lines, hence kickin' his ass with a "Syntax Error" is absolutely legitimate here too.

So what "n_inputnumberfromdata" basically does, is not more than copying the chars found in DATAs into a temporary buffer and while doing so is just checking, if there are number related chars only (such as -, +, ., digits 0-9 etc.). It will, however, in no way evaluate the read number yet, as that is just done one step further using the functions "func_read_float", "func_read_int64" and "func_read_uint64". Which of these 3 functions is called depends on the variable types you give at the READ statement. These functions take the chars from the temporary buffer (see above) and evaluate it into the actual number, but as you can see they simply use the biggest possible variable type to do so, hence using type suffixes on the numbers it only easily allow us to distinguish between integer types %%,%,&,&& and floating point types !,#,## and unsigned ~ for integers, but we can't distinguish between the actual size/precision of the variable types. To implement that, it would need a massive intervention into the whole function calling chain involved in reading numbers from DATA, respectively files, which use the same evaluation functions.

I'd prefer to waive to this massive interventions, as we would risk a whole bunch of new number related bugs, so I'll let you know what I have so far and listen to your thoughts, if that is enough type suffix support or not.

1.) Any type suffixes in DATA numbers are ignored in general doesn't matter of their kind or count, ie. you could write any combination of suffixes, even non existing or ambiguous ones like %~&!, ###&~ etc.. However, here I personally tend to improve it to allow real suffixes only, which would be not that big deal to do from the point I'm right now.

2.) If unsigned (~) is found, but the number is obviously entered as a negative number (leading -) in the DATAs, it's an error.

3.) If an integer type (%,&) is found, and the number would obviously evaluate into a floating point value, it's an error. Eg. 1.111&, 1E-5%, but not 1.111E+3& or 1E+5%. Hence, if the exponent (implied or explicitly given) is positive and equal to the number of digits after the decimal dot, then the
integer condition is fulfilled.

4.) If more digits, dots or exponents follow after the first type symbol, it's an error, eg. 125&.45, 125%E+5 etc..

5.) Now for given HEX/OCT/BIN numbers, those are introduced with & and need to be followed by either letter of H/O/B (case ignored), otherwise it's an error, further see 1.), but allowing integer suffixes only is an option.

6.) HEX/OCT/BIN is always evaluated as unsigned value unless it's in the _INTEGER64 range, where it would be signed, if the most significant bit is set (this all is imposed by the fact that the evaluation functions operate on int64/uint64 only). Changing this behaviour would require a lot of intervention, as the type suffixes are known to "n_inputnumberfromdata" only, but the size/sign of the evaluation would need to go into the "func_read_int64/uint64" functions. Also an explicit sign precheck on bits 63/31/15/8 need to be put into "n_inputnumberfromdata" then.

---

And even if this would all work as expected, then it would impose a new rule how to write HEX/OCT/BIN DATAs correctly, eg. &Hff, &H8000, &H81f2a000 would then evaluate into negative numbers unless they are given with explicit types eg. &Hff&, &H8000~%, &H81f2a000&&, which certainly would again confuse many people, I know we had such discussions several times in the forum already.

So now it's time for you guys, what do you think?? - Done as is, or what??

As the title says,
this is a Format$ function (PRINT USING style), which allows for explicit argument indexing in the given format template. The indexing feature lets you change the template being processed while keeping the arguments stream the same.

This can be an invaluable tool in some situations, just think about different date formats. With PRINT USING alone you would probably need to reorder your day, month, year, weekday etc. arguments for every date format to match the order of the respective format tokens in the template, but not so with this function. Another example is when it comes to localizing your programs, where it helps when translating template strings to different languages and the sentence structure and thus the order of the arguments changes.

Beside the indexing, which this function got its name from, it has a couple other useful extensions compared to the regular PRINT USING conventions, such as bin/hex/oct formatting, use of escape sequences to insert control or extended ASCII chars and more. All of this is detailed in the comprehensive HTML Documentation available for download below the example code block.

An example using the new IndexFormat function:
Save as: FormatExample.bas (or whatever)

As it is required to preserve the UTF-8 encoding of the HTML Documentation and some preformatted examples, it is packed into an 7-zip archive file attached below. The archive does also contain the example from the codebox above.