Wiki improvements

Forum for discussion about the documentation project.
Post Reply
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

I consider these articles as just a collection of drafts and more generally some material for a future addition in the documentation, and that any formalism should be applied only when converting these articles to new wiki pages.
The principle of this approach was precisely to avoid imposing a formalism to the eventual writers, in order to reach the largest number and get articles in the shortest time.
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

Thank you very much MrSwiss for this new article.
I just slightly shortened the title:
How and Why to make Abstraction by Object Encapsulation, with FB Syntax in UDTs (basics)

I hope the example of MrSwiss will push many other users to also offer articles!
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

Following the MrSwiss article:
"How and Why to make Abstraction by Object Encapsulation, with FB Syntax in UDTs (basics)"
I plan to continue by writing a second article on a more advanced abstraction technique:
"How and Why to make high Abstraction by Subtype Polymorphism, with FB Syntax in UDTs"

What do you all think?
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Wiki improvements

Post by MrSwiss »

I'd say, go for it! (this was intended, right from the start, and the reason to call the first one: "basics")

However, I'd sort of stick, with that "model":
"How and Why to make Abstraction by Subtype Polymorphism, with FB Syntax in UDTs (advanced)"
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

Okay.
I gave myself a release goal for next week.
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

Correction:
I have already made good progress on this new article!
=> Release before the end of this week.


[edit]
Done.
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

Imortis wrote:Perhaps another tutorial should be made show how to make proper use of Screenlock/Screenunlock. I know I had trouble with that when I first started working with graphics screens in FB.
fxm wrote:There is already this article: How to Solve the Flickering Issue when Refreshing a Window in FB Graphics Mode.
But if it is desirable to write an additional article more generally on "When must implement an anti-flickering process", .....I am not in the best position to write such an article!
Would anyone be interested in writing of such an article?
Why and When must to Implement an Anti-Flickering process

Or even to propose any other subject of article?
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Wiki improvements

Post by MrSwiss »

Yes, I think (based on your last Article) another one is badly needed:
When to implement (or NOT implement): default ctor/dtor, and HOW ... (advanced 2) <-- debatable title
The reasons are:
  • 1) you've once (ever so slightly) touched on that (reason for Protected: implementation)
    2) sometimes they seem to be *required* (by inheritance?)/(by polymorphism?)
    3) sometimes they don't even need to be declared, nor implemented
All this seems (currently) a bit *nebulous*, *foggy* ... (aka: not clearly defined behaviour).

What do you think?
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

Indeed, this topic is a little complex, but a fact stated in my first article may explain most of the behaviors you reported in your article above (specially point 2).
I think we need to start from single UDT, then add the UDT composition, then the UDT inheritance.
But it is not an easy article to write.
Maybe there are other specialists of this topic among the users?

Proposed title:
Why, When and How to Declare / Implement Constructors, Destructor, for UDTs in FB (advanced)
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

fxm wrote:Proposed title:
Why, When and How to Declare / Implement Constructors, Destructor, for UDTs in FB (advanced)
I started working on the subject (starting with the most difficult: inheritance)!

I think the 2 error messages:
186 Missing default constructor implementation (base UDT without default constructor requires manual initialization)
188 Missing UDT.constructor(byref as const UDT) implementation (base UDT without default constructor requires manual initialization)
should be merged into one (XXX), because even in the configuration of error 186, one can get away with also defining a copy constructor as proposed in error message 188:
XXX Missing base UDT default constructor or UDT.constructor(byref as const UDT) implementation (base UDT without default constructor requires manual initialization)

As for the error message:
187 Missing UDT.constructor(byref as UDT) implementation (base UDT without default constructor requires manual initialization)
I think it is no longer called.
(implicit copy-constructor and implicit copy-assignment operator now both defined as "Byref As Const UDT" since fbc 1.00.0)

Examples:

1) Error 186:

Code: Select all

Type Parent
  Dim As Integer I
  Declare Constructor (Byval As Integer)
End Type

Type Child Extends Parent
  Dim As Integer J
End Type
error 186: Missing default constructor implementation (base UDT without default constructor requires manual initialization)

Code: Select all

Type Parent
  Dim As Integer I
  Declare Constructor ()
  Declare Constructor (Byval As Integer)
End Type

Type Child Extends Parent
  Dim As Integer J
End Type
OK

Code: Select all

Type Parent
  Dim As Integer I
  Declare Constructor (Byval As Integer)
End Type

Type Child Extends Parent
  Declare Constructor (Byref As Const Child)
  Dim As Integer J
End Type
OK

2) Error 188:

Code: Select all

Type Parent
  Dim As Integer I
  Declare Constructor (Byval As Integer)
End Type

Type Child Extends Parent
  Declare Constructor ()
  Dim As Integer J
End Type
error 188: Missing UDT.constructor(byref as const UDT) implementation (base UDT without default constructor requires manual initialization)

Code: Select all

Type Parent
  Dim As Integer I
  Declare Constructor ()
  Declare Constructor (Byval As Integer)
End Type

Type Child Extends Parent
  Declare Constructor ()
  Dim As Integer J
End Type
OK

Code: Select all

Type Parent
  Dim As Integer I
  Declare Constructor (Byval As Integer)
End Type

Type Child Extends Parent
  Declare Constructor ()
  Declare Constructor (Byref As Const Child)
  Dim As Integer J
End Type
OK
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Wiki improvements

Post by MrSwiss »

fxm wrote:I started working on the subject (starting with the most difficult: inheritance)!
Not certain, that this is the "way to go", its similar to "build a house, roof first".

IMHO, start from "the ground", going upwards ... aka: a simple Type, then
adding functionality, in a step by step manner ... (explanations along he way).
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

I worked directly on this advanced difficulty because the rest is clear enough for me!
(this post was more dedicated to developers)

But do not worry, the article 'Why, When and How to Declare / Implement Constructors, Destructor, ..., for UDTs in FB (advanced)' will go in the increasing order of the difficulties (at least I hope so).
I will probably publish a first draft soon, and then improve it if possible, based on your comments.


[edit]
Done.
fxm
Moderator
Posts: 12066
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Post by fxm »

I strongly encourage all users to follow MrSwiss's example by proposing topics of articles, with material if possible, or altogether the entire article in the best case.
The articles topics proposed by some users could be as well documented or even written by other users.

I do not want to give names, but for the pending article 'Why and When to Set Up an Anti-Flickering process, in FB code', I would think of someone else in particular :-)
(it's not because I am now retired that I have to do everything!)
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Wiki improvements

Post by Imortis »

fxm wrote:I strongly encourage all users to follow MrSwiss's example by proposing topics of articles, with material if possible, or altogether the entire article in the best case.
The articles topics proposed by some users could be as well documented or even written by other users.

I do not want to give names, but for the pending article 'Why and When to Set Up an Anti-Flickering process, in FB code', I would think of someone else in particular :-)
(it's not because I am now retired that I have to do everything!)

If I can, I will.
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Wiki improvements

Post by MrSwiss »

fxm wrote:'Why, When and How to Declare / Implement Constructors, Destructor, ..., for UDTs in FB (advanced)'
fxm, thank you very much, for this. (Cleared up, quite a lot of questions!)

There are, from my point of view, a few additions needed:
  • While (in some cases) the need to Declare, is clearly explained, there isn't anything related to Implementation (do I have to, or not?).
    (this is especially true, when it concerns EMPTY (without body) constructors/operators, since all others 'have to be written' anyhow.)
    Unlike the Singleton Example, where you clearly state: "It may have no implementation because 'it will' never 'be' called." ('...' additions by myself)
    There is another (small, typo) somewhere in floating text, where you write "types" but clearly refer to: instance(s) of the type.
    Question: why use 'Dim As' (in type) as opposed to: 'As' (without Dim)?
This is currently what I've picked up, yesterday, by reading it (may not yet cover it all).
I'll re-read it again today, since the subject is rather 'heavy', as stated by you ...
Post Reply