Hello,
After some testing and fixing minor installation and other issues,
RC2 for version 2.2.2 is available for testing. Downloads for major
platforms (Linux/Windows/FreeBSD/Mac OS X/Dos) are available from
ftp://ftp.freepascal.org/fpc/beta/2.2.2rc2
(this should propagate to mirrors soon)
> On Tue, 15 Jul 2008, Marco van de Voort wrote:
>
> > because there are several bugreports asking for an iconv header
> > translations, and one contained a patch from Whitewind which I tried to
> > cleanup and get working.
> >
> > I now have a bit of an odd problem with it that it seems to decod
Hi,
- snip --
Include(WindowAttributes, waStayOnTop); // <== doesn't compile with FPC 2.3.1
WindowAttributes:=WindowAttributes +[waStayOnTop]; // <== this does
- end --
As far as I understood,
Graeme Geldenhuys wrote:
WindowAttributes are defined as follows:
...
property WindowAttributes: TWindowAttributes read FWindowAttributes
write FWindowAttributes;
...
It's the same thing as mentioned before, FPC now guarantees you can
change that into GetWindowAttributes function. If this i
Graeme Geldenhuys wrote:
Hi,
- snip --
Include(WindowAttributes, waStayOnTop); // <== doesn't compile with FPC 2.3.1
WindowAttributes:=WindowAttributes +[waStayOnTop]; // <== this does
- end
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys:
It compiles without issues under FPC 2.2.3 and prior. What is wrong
with using Include() to add to a set? I do it all the time, plus
WindowAttribute is a read/write property, unlike the compiler error in
2.0.4 where you could use Include() with
Op Wed, 16 Jul 2008, schreef Daniël Mantione:
2.3 prevents you form taking the address of a property, because that way you
can read/write its value directly, circumventing the getter/setter. So you
cannot use the @ operator, but neither can you pass properties to var
parameters. Include is a
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
> I think there can be two visions here:
> - Include is not a real procedure, so this internal implementation detail
> should be hidden and this can/should be allowed; the
> compiler internally should convert it into set:
2.3 prevents you form taking the address of a property, because that
way you can read/write its value directly, circumventing the
getter/setter. So you cannot use the @ operator, but neither can you
pass properties to var parameters. Include is an internal procedure
that calls an rtl function
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys:
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
I think there can be two visions here:
- Include is not a real procedure, so this internal implementation detail
should be hidden and this can/should be allowed; the
c
On 16 Jul 2008, at 10:01, Graeme Geldenhuys wrote:
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
I think there can be two visions here:
- Include is not a real procedure, so this internal implementation
detail
should be hidden and this can/should be allowed; th
2008/7/16 Jonas Maebe <[EMAIL PROTECTED]>:
>>
>> I think this would be ideal. Using Include() is much cleaner than set
>> := set + [member]. And yes I understand that as it was implement, you
>> could circumvent the getter/setter, but I believe it's something the
>> compiler must handle correctly
Hi,
just to add another opinion. Personally, I would thing that it was nice
to allow (write-able) Properties to any var-param (even out-param).
Write-able include properties with a setter-procedure.
IMHO the way it could be done would be for the compiler to create a
temporary variable. This c
> On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
> <[EMAIL PROTECTED]> wrote:
>> I think there can be two visions here:
>> - Include is not a real procedure, so this internal implementation detail
>> should be hidden and this can/should be allowed; the
>> compiler internally should convert it
I think this is also same in Delphi, but I agree that passing pure
properties (without getter/setter) to var should possibly be reduced to
warning or even hint.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
Op Wed, 16 Jul 2008, schreef Ales Katona:
I think this is also same in Delphi, but I agree that passing pure properties
(without getter/setter) to var should possibly be reduced to warning or even
hint.
This was discussed before and rejected.
The reason is that a change in implementation o
On 16 Jul 2008, at 11:58, Graeme Geldenhuys wrote:
OK, I understand you point over the long term. So would the following
still be okay?
set += [member];
Not that I ever use the C style operators like '+=', but it does act
as nice shorthand for code - replacing the need for Include().
It s
On 16 Jul 2008, at 12:16, Martin Friebe wrote:
IMHO the way it could be done would be for the compiler to create a
temporary variable. This could be passed in as var/out-param, and
then be assigned to the property, using the proper setter-procedure.
That results in semantics than a var/out
Hi,
After our discussion about not being able to use Include() with a
class property, I thought I would then use the C Style += operator.
After all that boils down to: i += 2;> i := i + 2;
I tried it, and yes I did add the -Sc compiler parameter...
The error message
Free Pascal C
> After our discussion about not being able to use Include() with a
> class property, I thought I would then use the C Style += operator.
> After all that boils down to: i += 2;> i := i + 2;
Suspect that it gets translated to inc(i,2); not i:=i+2; and then it makes
sense again, for the
On Wed, Jul 16, 2008 at 4:29 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> After our discussion about not being able to use Include() with a
>> class property, I thought I would then use the C Style += operator.
>> After all that boils down to: i += 2;> i := i + 2;
>
> Suspect tha
On Wed, Jul 16, 2008 at 4:29 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> After our discussion about not being able to use Include() with a
>> class property, I thought I would then use the C Style += operator.
>> After all that boils down to: i += 2;> i := i + 2;
>
> Suspect tha
On Wed, Jul 16, 2008 at 2:43 PM, Jonas Maebe <[EMAIL PROTECTED]> wrote:
>> OK, I understand you point over the long term. So would the following
>> still be okay?
>>
>> set += [member];
>>
>> Not that I ever use the C style operators like '+=', but it does act
>> as nice shorthand for code - repl
On 16 Jul 2008, at 16:23, Graeme Geldenhuys wrote:
So it seems I can't use the += operator with properties either!! :-(
Indeed. I've checked the code and properties are explicitly not
allowed for the C-style operators. The reason is that the x+=y is
translated into "x:=x+y" at the parser
Is there a way to separate unicode letters from punctuation and the like?
The reason is simple: I would like to separate words in a text for a
spell-checker.
I see there are tables which list unicode categories
http://www.sql-und-xml.de/unicode-database/#kategorien
Is there already something for fr
I'm getting a Error: Incompatible Types: got "untyped" expected
" when compiling
the following code. This happens when using default parameter values.
Here is an example:
var Callback: procedure(Data: Pointer);
procedure Proc(AData: Pointer = nil);
begin
end;
initialization
Callback := Pr
On Wed, 16 Jul 2008 15:05:44 -0500
Sean McIlwain <[EMAIL PROTECTED]> wrote:
> I'm getting a Error: Incompatible Types: got "untyped" expected
> " when
> compiling the following code. This happens when using default
> parameter values.
>
>
> Here is an example:
>
>
> var Callback: procedure(D
Apparently the new Delphi version (Tiburon) will change the way strings are
handled by the rtl and the compiler, this changes affects Unicode characters
specially. Surely the code created with the new Delphi version shouldn't
compile with FPC.
Is somebody addressing the changes to make them co
The following code fails to compile in Delphi mode but successfully
compiles in objfpc mode:
type
TEnum = (a, b, c);
var
AValue: TEnum;
AObject : TObject;
implementation
initialization
AObject := TObject(AValue);
Could this be supported in the Delphi mode as well?
Thanks,
Sean
___
Leonardo M. Ramé wrote:
Apparently the new Delphi version (Tiburon) will change the way
strings are handled by the rtl and the compiler, this changes affects
Unicode characters specially. Surely the code created with the new
Delphi version shouldn't compile with FPC.
Why shouldn't ?
Is somebo
Graeme Geldenhuys wrote:
On Wed, Jul 16, 2008 at 4:29 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
After our discussion about not being able to use Include() with a
class property, I thought I would then use the C Style += operator.
After all that boils down to: i += 2;> i := i +
In hebrew (at least) the punctuation is a different char that comes
after the letter, but painted like it was part of the letter, so you
can parse each word and ignore non letter value (it arrives in
different range in the unicode table).
Ido
On Wed, Jul 16, 2008 at 10:09 PM, theo <[EMAIL PROTECT
On Thu, Jul 17, 2008 at 2:55 AM, Joao Morais <[EMAIL PROTECTED]> wrote:
> Just if you want to know my humble opinion: your statement isn't fair. You
> know a property isn't a variable, so don't assume it will behave like that.
> If you want a property function as a variable, eg reading and writing
On Wed, Jul 16, 2008 at 5:37 PM, Jonas Maebe <[EMAIL PROTECTED]> wrote:
> Indeed. I've checked the code and properties are explicitly not allowed for
> the C-style operators. The reason is that the x+=y is translated into
> "x:=x+y" at the parser level rather than at the lexical level. This means
>
34 matches
Mail list logo
