Wiki improvements

Forum for discussion about the documentation project.
Tourist Trap
Posts: 2756
Joined: Jun 02, 2015 16:24

Re: Wiki improvements

Postby Tourist Trap » May 21, 2019 11:45

fxm wrote: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
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » May 21, 2019 13:23

Tourist Trap wrote: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)

Tourist Trap wrote: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
Posts: 2756
Joined: Jun 02, 2015 16:24

Re: Wiki improvements

Postby Tourist Trap » May 21, 2019 13:50

fxm wrote: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
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » May 21, 2019 14:48

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
Posts: 2756
Joined: Jun 02, 2015 16:24

Re: Wiki improvements

Postby Tourist Trap » May 21, 2019 16:38

fxm wrote: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
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » May 22, 2019 7:19

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:
Bug report discussion wrote: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
Site Admin
Posts: 2949
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Wiki improvements

Postby coderJeff » May 24, 2019 1:38

marcov wrote: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
Site Admin
Posts: 2949
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Wiki improvements

Postby coderJeff » May 24, 2019 2:13

fxm wrote: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:
Bug report discussion wrote: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
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » May 24, 2019 5:27

Done:
KeyPgOpLetlist → fxm [Added the inheritance case (description + example)]
fxm
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jun 07, 2019 13:12

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

@coderJef,
coderJeff
Site Admin
Posts: 2949
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Wiki improvements

Postby coderJeff » Jun 09, 2019 15:48

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
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jun 10, 2019 9:25

coderJeff wrote: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
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jun 10, 2019 17:55

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

Thank you.
dodicat
Posts: 5890
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Wiki improvements

Postby dodicat » Jun 10, 2019 18:58

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
Posts: 9076
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jun 10, 2019 20:26

dodicat wrote: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

Return to “Documentation”

Who is online

Users browsing this forum: No registered users and 10 guests