[Lazarus] Some syntax changes

[Mattias Gaertner]

On Sat, 31 Jul 2010 05:38:50 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Mattias Gaertner schrieb:
> 
> >> Perhaps nobody noticed that in the past days the Pascal syntax has 
> >> changed a bit. This leads to wrong behaviour of the code tools :-(
> >>
> >> Now unit properties can follow an "var" block, while this was flagged 
> >> with an error: expected ":" after "property".
> > 
> > Can you give an example or better: the definition?
> 
> I would be happier myself, if I had a valid definition :-(
> 
> Let's postpone this one, until I can be sure that it is not related to 
> my current work on the compiler. A duplicate function of the same name, 
> in different units, and the wrong use of a function result instead of 
> function invocation (recursion) has caused much confusion in the last 
> days. I'm also confused by the compiler versions, now existing on my 
> test system (trunk and branch version).
> 
> A simple example:
> 
> function GetProp: byte;
> var
>    test: integer;
> property
>    prop1: byte read GetProp;
>    prop2: byte read GetProp;

Local properties? I didn't know that this is allowed. And my four
days old fpc 2.5.1 gives a strange error:

Error: Resourcestrings can be only static or global

 
> If this is handled properly for you, I'm sorry for this wrong item.

The compiler can not handle it. I guess it is correct for the
codetools to not support local properties.

 
> >> The usage of an function name instead of the Result variable has been 
> >> restricted. For some reason Lazarus now rejects "Result" in code 
> >> completion, even if it is accepted by the compiler.
> > 
> > Can you give an example or better: the definition?
> 
> This happened to me in a property getter function, i.e. in the GetProp 
> implementation in above example. So it may be related to the above 
> property problem.

I don't know. The above does not compile.

 
> >> It also seems that Lazarus has problems with $IF, even simple 
> >> expressions are not evaluated properly, so that the wrong branch is 
> >> handled as enabled/disabled.
> > 
> > Can you give an example?
> 
> Commandline option: -dMyConst:=1 (may work with local $DEFINE as well)

I implemented it.

> Code: {$IF MyConst>1} ...

This works now.


Mattias