Wiki improvements

[Tourist Trap]

I am still waiting for any article proposed by users:
- either provided already written (perhaps only a final formatting to be done for a better integration with the existing articles),
- or provided in the form of a list of references to posts/topics with enough material to be able, after synthesis, to constitute a complete article in itself.

Hi fxm,

Would an example of an UDT that shows how to do something like a button with mouseover, mouseclick, and mousedrag, be useful? It's something that I always use and that I didn't find in the doc. So maybe it could be worth sharing. Or not. Let me know.

By the way I want to say that your articles have improved a lot. They are still technical, but you provide all the logic and the examples in good order, so that's perfectly reachable for anyone that is curious of the topic described.

[fxm]

Would an example of an UDT that shows how to do something like a button with mouseover, mouseclick, and mousedrag, be useful? It's something that I always use and that I didn't find in the doc. So maybe it could be worth sharing. Or not. Let me know.

Yes, it seems interesting as an article on FreeBasic, especially if the proposed code is multi-platform and fully written in FB.
Can you output something?
(we will see after if it is necessary to enrich it with some other method/example and explanations)

By the way I want to say that your articles have improved a lot. They are still technical, but you provide all the logic and the examples in good order, so that's perfectly reachable for anyone that is curious of the topic described.

If you find that some of my previous articles could be much improved by reorganizing their content, do not hesitate to tell me (with your critics). I'll see what I can do.

[Tourist Trap]

Yes, it seems interesting as an article on FreeBasic, especially if the proposed code is multi-platform and fully written in FB.
Can you output something?

My idea was something like that:
viewtopic.php?f=7&t=24907&p=222768&hilit=drag#p222768

Not the same as in this tip&trick, but something simpler that would be built step by step, starting with a simple button, then adding to it simple interactivity, and the drag&drop feature with dropzones at the end.

I always wanted to rewrite it for myself anyway so I could work at it and share it without any problem, as soon as I have time.

[fxm]

Yes, more simple and more logic when using properties versus directly using their data fields, suppressing the useless operators and even some macros...
Big work for all this!

[Tourist Trap]

Yes, more simple and more logic when using properties versus directly using their data fields, suppressing the useless operators and even some macros...
Big work for all this!

If it takes long it doesn't matter since it's better to have something rather than nothing at the end :)

[fxm]

coderJeff, dkl,

I updated my old bug report:
Operator Let() (Assignment) incompatible with inheritance
because I've come to understand now how this operator behaves in the case of a Type that Extends a Base:

When the Type Extends a Base, the first variable (in the list of variables) assigned by the operator Let() (Assignment) then corresponds to a Base instance (only the other variables are those to receive the values of the data fields of the Type).

Is this present behavior wanted or definitely accepted?
- If so, we should update the documentation page.
- If not, should we report (by a 'note') this current behavior in the documentation page?

[coderJeff]

CHM contents are html files, string sin CHM internal files are UCS2/UTF16. I happen to be fixing the FPC chm doc tool and compiler this weekend, and it turns out the MS hhc compiler replaces things like ' from HTML topic titles when moving them into indexes, so maybe it does with 4 char escapes too.

I don't think we have any unicode usage in topic titles yet so probably haven't seen that problem in our wiki yet.

I did some testing, and the on line wiki supports UTF8 storage and rendering very well. And with our doc generator the UTF8 passes through to HTML also very well, using <meta charset="UTF-8"> in the HTML output, even in CHM reader.

So I was baffled, as I could not remember why we are using HTML escapes in first place. Took me a while to figure out: the first versions of the on line wiki did not support UTF8; only iso-8859-1 encoding (I think) was used initially. So as a work around to get specific characters to show in a browser, the HTML escapes were used.

[coderJeff]

coderJeff, dkl,

I updated my old bug report:
Operator Let() (Assignment) incompatible with inheritance
because I've come to understand now how this operator behaves in the case of a Type that Extends a Base:

When the Type Extends a Base, the first variable (in the list of variables) assigned by the operator Let() (Assignment) then corresponds to a Base instance (only the other variables are those to receive the values of the data fields of the Type).

Is this present behavior wanted or definitely accepted?
- If so, we should update the documentation page.
- If not, should we report (by a 'note') this current behavior in the documentation page?

I think updating the documentation that the present behaviour is expected is a good resolution for the bug report.

[fxm]

Done:
KeyPgOpLetlist → fxm [Added the inheritance case (description + example)]

[fxm]

KeyPgInputnum → fxm [Added: string type suffix "$" is forbidden in -lang fb dialect]

@coderJef,

• About this, can you solve the bug report:
  Typo in error message 148

[coderJeff]

Fix for #893 Typo in error message 148 is now merged in to fbc/master.
Thanks, fxm.

Do you mind having a look at:
#455 Number lexing allows much bad input
#491 precision denotation suffix char returns syntax error

I think parts of those bug reports could be resolved by verifying or adding to documentation. Only parts not fixed by documentation would be a fbc compiler change (or decision not to fix).

[fxm]

Do you mind having a look at:
#455 Number lexing allows much bad input
#491 precision denotation suffix char returns syntax error

I think parts of those bug reports could be resolved by verifying or adding to documentation. Only parts not fixed by documentation would be a fbc compiler change (or decision not to fix).

In addition to the updates made after the date of the bug reports, I made some clarifications in the 'Floating Point Literals' paragraph on the Literals documentation page:

Floating point numbers are specified in decimal digits, may be positive or negative, have a fractional portion, and optionally an exponent. The format of a floating point literal is as follows (without space or parenthesis added):

number[.[fraction]][((D|E) [+|-] exponent)|(D|E)|][suffix]
number[.[fraction]][(D|E)[+|-][exponent]][suffix]
or
.fraction[((D|E) [+|-] exponent)|(D|E)|][suffix]
.fraction[(D|E)[+|-][exponent]][suffix]

By default, floating point numbers that do not have either an exponent or a suffix are considered as a double precision floating point value, except in the -lang qb dialect, where numbers of 7 digits or fewer are considered to be single precision.

Code: Select all

Dim a As Double = 123.456
Dim b As Double = -123.0

The letter "D" or "E", placed after the number/fraction part, allows the number to be given an exponent. The exponent may be specified as either positive or negative with a plus ("+") or minus ("-") sign. Exponents that do not have a sign are positive.
An exponent value is not required after the letter (or even after the sign), so the letter can be used on its own just to specify the type. "D" specifies a double-precision floating-point number. "E" specifies a floating-point number using the default precision. When the letter is used on its own in combination with a suffix (see below) the type denoted by the suffix overrules the type specified by the letter.

Code: Select all

Dim a As Double = -123.0d
Dim b As Double = -123e
Dim c As Double = 743.1e+13
Dim d As Double = 743.1D-13
Dim e As Double = 743.1E13
Dim f As Single = 743D!

A suffix of "!" or "F" on a number specifies a single precision (32 bit total) floating point value. A suffix of "#" or "D" specifies a double precision float.
Note that the letter suffixes and exponent specifiers are all case-insensitive.

Code: Select all

Dim a As Single = 3.1!
Dim b As Single = -123.456e-7f
Dim c As Double = 0#
Dim d As Double = 3.141592653589e3#

See also my comments in the two bug reports.

[fxm]

Fix for #893 Typo in error message 148 is now merged in to fbc/master.

Thank you.

[dodicat]

Maybe the Wiki is improved with the suffix change, but fb hasn't.
Large chunks of forum code no longer compile.
Why was that particular change made anyway?

[fxm]

Maybe the Wiki is improved with the suffix change, but fb hasn't.
Large chunks of forum code no longer compile.
Why was that particular change made anyway?

This is one of the last fixes of dkl in the rev 1.06.0:
[fixed] (rev 1.06.0)
- #832: Fix bug allowing QB style suffixes on all keywords, regardless of -lang