Only tested with 2.4.4; so if changed in 2.6 ....

in unit2

   TFoo = class(TObject)
   private
     FBar: integer;
   public
     property Bar: integer read FBar write FBar;
   end;

which means in unit1, it is not allowed to access
TFoo.FBar

But it can be done:
     property Num: Integer read FFoo.FBar;

see attached....

Martin wrote

Only tested with 2.4.4; so if changed in 2.6 ....

http://wiki.freepascal.org/User_Changes_2.6.0#Inaccessible_symbols_and_properties

Jonas

I just upgraded to 2.6.0 - It still compiles (recompiling fpc trunk now, may test that later)

Note, that I am not accessing a private field of the parent class (like in the link).

   TForm1 = class(TForm)
   public
     FFoo: TFoo;
     property Num: Integer read FFoo.FBar;
   end;

TForm1 and TFoo are not related.

Just a 'for your info' note: Kylix doesn't allow the above. Nor does it allow accessing the property FFoo.Bar as a parameter to the read. This makes sense to me, though, because FFoo may very well be nil when code tries to read Form1.Num.

Here are my foo and form units, as well as the command line compiler's complaint about them:

~/tmp/k3tests/access_private_class_member $dcc Project1.dpr Borland Delphi for Linux Version 14.5
Copyright (c) 1983,2002 Borland Software Corporation main_unit.pas(13) Error: Record, object or class type required main_unit.pas(25)
Project1.dpr(6) Fatal: Could not compile used unit 'main_unit.pas'

Sorry if this is "old news". :) Here are the files:

unit foo_unit;
interface
uses
  Classes;
type
  TFoo = class
  private
    FBar : Integer;
  public
    property Bar : Integer read FBar write FBar;
  end;
implementation
end.
unit main_unit;
interface

uses
SysUtils, Types, Classes, Variants, QTypes, QGraphics, QControls, QForms,

  QDialogs, QStdCtrls, foo_unit;

type
  TForm1 = class(TForm)
  public
    Foo : TFoo;
    property Num: Integer read Foo.Bar;
  end;
var
  Form1: TForm1;
implementation
{$R *.xfm}
end.

Best regards,
Pete C.

Well the property is rejected by fpc too. But then a property is always treated as if it was a function (or procedure for the setter). So that is more than referring to a field.

To be honest I discovered this by accident, it was meant to use a field from a record...

the nil situation is not a concern here, a programmer can always write code that can fail on nil pointers. FFoo could well have the same live time as the Form...

When FFoo is a pointer or reference, it IMO should not be possible at all, to select a member of it in a property. AFAIR Delphi only allows for access to Record (or Object) members, which reside inside the instance.

DoDi