Delphi: EReadError with message ‘Property PageNr does Not Exist’

I get SOMETIMES error message: EReadError with message 'Property PageNr does Not exist', when I try to run my own project. I am really desperate, because I see simply nothing what is the cause. The devilish is that it comes up sometimes but often. It concerns of my own component TPage. Here is declaration>

TPage = class(TCustomControl)   //
   private
      FPaperHeight, FPaperWidth:Integer;
      FPaperBrush:TBrush;
      FPaperSize:TPaperSize;
      FPaperOrientation:TPaperOrientation;
      FPDFDocument: TPDFDocument;
      FPageNr:integer;

      procedure PaintBasicLayout;
      procedure PaintInterior;
      procedure SetPapersize(Value: TPapersize);
      procedure SetPaperHeight(Value: Integer);
      procedure SetPaperWidth(Value: Integer);
      procedure SetPaperOrientation(value:TPaperOrientation);
      procedure SetPaperBrush(Value:TBrush);
      procedure SetPageNr(Value:Integer);
   protected
      procedure CreateParams(var Params:TCreateParams); override;
      procedure AdjustClientRect(var Rect: TRect); override;
   public
      constructor Create(AOwner: TComponent);override;
      destructor Destroy;override;
//      function GetChildOwner:TComponent; override;
      procedure DrawControl(X,Y :integer; Dx,Dy:Double; Ctrl:TControl;NewCanvas:TCanvas);
//      procedure GetChildren(Proc:TGetChildProc; Root:TComponent); override;
      procedure Loaded; override;
      procedure MouseDown(Button: TMouseButton; Shift: TShiftState; X, Y: Integer);  override;
      procedure Paint; override;
      procedure PrintOnCanvas(X,Y:integer; rX,rY:Double; AC开发者_Go百科anvas:TCanvas);
      procedure PrintOnPDFCanvas(X,Y:integer);
      procedure PrintOnPrinterCanvas(X,Y:integer);
      procedure Resize; override;
      procedure SetPrintKind(APrintKind:TPrintKind; APrintGroupindex:Integer);
   published
      property PageNr:integer read FPageNr write SetPageNr;
      property PaperBrush: TBrush read FPaperBrush  write SetPaperBrush;
      property PaperHeight: integer read FPaperHeight write SetPaperHeight;
      property PaperWidth: integer read FPaperWidth write SetPaperWidth;
      property PaperSize: TPaperSize read FPaperSize write SetPaperSize;
      property PaperOrientation:TPaperOrientation read FPaperOrientation write SetPaperOrientation;
      property PDFDocument:TPDFDocument read FPDFDocument write FPDFDocument;
      property TabOrder;
   end;

I thoroughly read the similar topic depicted here:

Delphi: EReadError with message 'Property Persistence does Not exist'

But here it is my own source code. No third party. Interesting: when I delete PageNr property in my dfm file (unit1.dfm), then pops up : EReadError with message 'Property PaperHeight does Not exist'. when I delete PaperHeight then it will claim PaperWidth and so on...

Here is piece of dfm file:

 object pg1: TPage
    Left = 128
    Top = 144
    Width = 798
    Height = 1127
    PageNr = 0
    PaperHeight = 1123
    PaperWidth = 794
    PaperSize = psA4
    PaperOrientation = poPortrait
    TabOrder = 0
    object bscshp4: TBasicShape
      Left = 112
      Top = 64
      Width = 105
      Height = 105
      PrintKind = pkNormal
      PrintGroupIndex = 0
      Zooming = 100
      Transparent = False
      Repeating = False
      PageRepeatOffset = 1
      ShapeStyle = ssVertical
      LinePosition = 2
    end
    object bscshp5: TBasicShape
      Left = 288
      Top = 24
      Width = 105
      Height = 105
      PrintKind = pkNormal
      PrintGroupIndex = 0
      Zooming = 100
      Transparent = False

What the hell happens ??????? I have never seen that. I compiled the unit several times... Encoutered no problem. Maybe the cause is beyond this. I feel completely powerless.

What you are experiencing here is a type name clash.

There is a class called TPage in ExtCtrls. If ExtCtrls is listed in the uses clause in the interface section of your unit, Delphi will "assume" that you are referring to the last declared TPage - which will have totally different properties.

If you were to add some code that to interact with a TPage object, class completion would show the methods and properties for ExtCtrls.TPage, rather than your TPage. This is why renaming to TBookPage has solved the problem.

It is can be a good practice to use a short prefix on your own controls to avoid this (e.g. use TLyPage). This is why most 3rd party controls use a similar scheme.

This can be used as quick-and-dirty way to re-implement a control - see Deltics Blog entry for an example.

Check for multiple copies of the .DFM file on your hard disk. This usually happens when the .DFM that's actually being linked into your executable isn't the one you're seeing in the IDE.

Also, are you building with runtime packages? It could also be the case that your application is being built with a different version of a package than the one loaded at runtime, as well. The error loading the .DFM's properties could come from the package looking for something not in the app (or more likely, vice versa - the app's expecting something that doesn't exist in the package when the .DFM is loaded from it).