Wiki improvements
Re: Wiki improvements
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.
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.
Re: Wiki improvements
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!
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!
Re: Wiki improvements
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?
"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?
Re: Wiki improvements
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)"
However, I'd sort of stick, with that "model":
"How and Why to make Abstraction by Subtype Polymorphism, with FB Syntax in UDTs (advanced)"
Re: Wiki improvements
Okay.
I gave myself a release goal for next week.
I gave myself a release goal for next week.
Re: Wiki improvements
Correction:
I have already made good progress on this new article!
=> Release before the end of this week.
[edit]
Done.
I have already made good progress on this new article!
=> Release before the end of this week.
[edit]
Done.
Re: Wiki improvements
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.
Would anyone be interested in writing of such an article?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!
Why and When must to Implement an Anti-Flickering process
Or even to propose any other subject of article?
Re: Wiki improvements
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:
What do you think?
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
What do you think?
Re: Wiki improvements
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)
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)
Re: Wiki improvements
I started working on the subject (starting with the most difficult: inheritance)!fxm wrote:Proposed title:
Why, When and How to Declare / Implement Constructors, Destructor, for UDTs in FB (advanced)
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
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
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
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
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
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
Re: Wiki improvements
Not certain, that this is the "way to go", its similar to "build a house, roof first".fxm wrote:I started working on the subject (starting with the most difficult: inheritance)!
IMHO, start from "the ground", going upwards ... aka: a simple Type, then
adding functionality, in a step by step manner ... (explanations along he way).
Re: Wiki improvements
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.
(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.
Re: Wiki improvements
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!)
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!)
Re: Wiki improvements
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.
Re: Wiki improvements
fxm, thank you very much, for this. (Cleared up, quite a lot of questions!)fxm wrote:'Why, When and How to Declare / Implement Constructors, Destructor, ..., for UDTs in FB (advanced)'
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)?
I'll re-read it again today, since the subject is rather 'heavy', as stated by you ...