Konstruktor-Aufruf "Too many actual parameters" - warum?

[Bodenseematze]

Zitat von jaenicke:

In Delphi 7 auch. Da fehlt ein komplettes reproduzierbares Beispiel.

Vielleicht wird die falsche Unit verwendet oder ähnliches.

Sowas in der Art muss es wohl sein - ich habe schon 'zig Klassen in der Art ohne Probleme definiert, nur hier macht es komischerweise Probleme.
Ich hatte zuerst die Ableitung von TPersistent im Verdacht, aber das mache ich an anderen Stellen auch

Interessanterweise zeigt mir die kontextabhängige Hilfe bei der Eingabe des Punktes nach "TMyClass" alle drei Create-Methoden an, wenn ich dann aber das "Create" hingeschrieben habe und die "(" eingebe (also insgesamt "TMyClass.Create("), wird nur noch "*No parameters expected*" angezeigt...


Hier habe ich es versucht, nachzuvollziehen in einem Mini-Projekt, bestehend aus zwei Units:
Unit1.pas:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs,
  Unit2;


type
  TForm1 = class(TForm)
  protected
    procedure DoCreate(); override;
  end;

var
   Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.DoCreate();
var
   test  : TMyClass;
begin
   test  := TMyClass.Create( 0.20, 1 );
end;


end.

Unit2.pas:

Delphi-Quellcode:

unit Unit2;

interface

uses Classes;

type
TMyClass             = class( TPersistent )
public
   constructor Create(              dVal_                : Extended;
                                    iDigits_             : ShortInt ); overload; virtual;
   constructor Create(              dVal_                : Extended ); overload; virtual;

protected
   constructor Create(); overload; virtual;
end;

implementation

constructor TMyClass.Create(        dVal_                : Extended;
                                    iDigits_             : ShortInt );
begin
   Create();
end;


constructor TMyClass.Create(        dVal_                : Extended );
begin
   Create();
end;


constructor TMyClass.Create();
begin
   inherited Create();
end;


end.

Project1.dpr:

Delphi-Quellcode:

program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1},
  Unit2 in 'Unit2.pas';

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

[KodeZwerg]

Delphi-Quellcode:

procedure TForm4.FormCreate(Sender: TObject);
var
  test: TMyClass;
begin
  test := TMyClass.Create(2.0, 4);
  try
  finally
    test.Free;
  end;
  test := TMyClass.Create(22.33);
  try
  finally
    test.Free;
  end;
  test := TMyClass.Create();
  try
  finally
    test.Free;
  end;
end;

Keine Probleme in Turbo Delphi 2005.

[Sherlock]

Dann hätte ich jetzt Projekteinstellungen und eventuell noch Bibliothekspfade oder Suchpfade im Verdacht.

Sherlock

[Bodenseematze]

Zitat von KodeZwerg:

  test := TMyClass.Create(); Keine Probleme in Turbo Delphi 2005.

Zumindest der dritte Aufruf sollte ja außerhalb der Unit2 nicht funktionieren, da die Methode ja "protected" ist !

EDIT: zur Info: wenn ich in der IDE beim "test := TMyClass.Create" mit STRG+linke Maustaste auf "Create" klicke, komme ich bei System.Object.Create raus...
und wenn ich die o.a. öffentlichen "Create"-Methoden in "Create2" umbenenne (und dann natürlich auch bei der Instanzierung Create2 verwende), lässt sich das ohne Fehler compilieren!!!

EDIT2: wenn ich alle drei Konstruktoren mit dem Namen "Create" in den public-Bereich schiebe, und den Konstruktor ohne Parameter mit "reintroduce" kennzeichne, lässt es sich ebenfalls ohne Compilerwarnung/-fehler übersetzen...

[Uwe Raabe]

Zitat von Bodenseematze:

Zumindest der dritte Aufruf sollte ja außerhalb der Unit2 nicht funktionieren, da die Methode ja "protected" ist !

Du hast es ja offenbar selbst schob erkannt: Da der protected constructor nicht sichtbar ist, wir stattdessen der von TObject genommen. Das müsste im Debugger auch auffallen.

[himitsu]

Ja, eigentlich "darf" man sichtbarkeiten nicht verringern. (wer's doch versucht, muß mit den Konsequenzen leben)

Durch das "overload" an allen Create (was hier aber nöig ist, da mehr als ein Create im Typ), ist/bleibt auch das originale Create des TObject sichtbar.

Man könnte hier mehrfach ableiten.
Einmal nur mit dem Protected-Create, ohne ein Overload,
und davon dann das mit den neuen Create's.
Dann müsste der Compiler beim "protected" aufhören zu suchen und dort meckern, das Jenes nicht verwendet werden kann (wenn man nicht in der selben Unit steht und da dann private und protected wie "public" wirkt, bzw. man arbeit mit "strict protected" und "strict private")

[jaenicke]

Du solltest einfach mal z.B. mit Everything nach Units mit dem gleichen Namen suchen, .dcu oder .pas.

Du kannst aber auch ganz einfach herausfinden, ob die beabsichtigte Unit verwendet wird:
Baue einfach einen Syntaxfehler in die Unit ein. Wenn der nicht bemängelt wird, wird sie auch nicht verwendet.

[Bodenseematze]

Zitat von Uwe Raabe:

Du hast es ja offenbar selbst schob erkannt: Da der protected constructor nicht sichtbar ist, wir stattdessen der von TObject genommen.

ja schon, aber warum wird dann in dem Fall nur noch der (öffentliche) Konstruktor von TObject gefunden und die anderen beiden aus meiner Klasse sind "ungültig"?
Und in dem Augenblick, wo alle öffentlich sind, funktioniert wieder aller wie gehabt? Sehr dubios!

Zitat von Uwe Raabe:

Das müsste im Debugger auch auffallen.

Seufz - noch so ein Reizthema bei mir; der Debugger funktioniert schon seit einer ganzen Weile bei mir nicht mehr (richtig) - ich schiebe es auf irgendwelche Microsoft Betriebssystemupdates...
Sobald ich ein Programm im Debugger versuche zu starten, hängt sich Delphi zu 95% komplett auf (die restlichen 5% funktioniert es).
In vielen Fällen funktioniert es, wenn ich auf der eigenen Maschine Remote-Debugging verwende, aber auch nicht immer...
Aber das ist ein anderes (leidiges) Thema

Zitat von himitsu:

Ja, eigentlich "darf" man sichtbarkeiten nicht verringern.

Das wusste ich nicht - ich dachte, das sei zulässig...

Zitat von himitsu:

(wer's doch versucht, muß mit den Konsequenzen leben)

Da scheinst Du Recht zu haben

Zitat von himitsu:

Man könnte hier mehrfach ableiten.

Sehr gute Idee, das werde ich so machen!

Zitat von jaenicke:

Du kannst aber auch ganz einfach herausfinden, ob die beabsichtigte Unit verwendet wird:
Baue einfach einen Syntaxfehler in die Unit ein. Wenn der nicht bemängelt wird, wird sie auch nicht verwendet.

Es wird schon die Unit verwendet - es scheint tatsächlich an der (versuchten) Sichtbarkeitsänderung des Konstruktors zu liegen...

Vielen Dank für Eure Hilfestellungen!

[himitsu]

[add] OMG, einen vergessenen Tab gefunden und wo Firefox sich so Mühe gegeben hat das Geschriebene im Editor, trotz mehrfacher Abstürze, Neustarts und disableter Tabs zu merken ......... klick ich mal auf Senden
Falls noch was fehlt und ich es noch nicht geschrieben hab ... hab's eh vergessen[/add]

Zitat von Bodenseematze:

Das wusste ich nicht - ich dachte, das sei zulässig...

Nja, es ist möglich,
aber widerspricht den Grundsätzen der OOP.

Durch die Vererbung werden Dinge hinzugefügt, aber niemals nicht entfernt.

Ein TMemoryStream kann alles, was ein TStream kann,
also es macht keinen Unterschied, ob ich VariableAlsTMemoryStream.Write oder VariableAlsTStream.Write ausführe, solange da wirklich ein TMemoryStream drin steckt.

Delphi-Quellcode:

type
  TTest = class(TComponent)
  strict private
    procedure SetName(const NewName: TComponentName); override;
  strict protected
    property Tag;
  end;

procedure TForm4.FormCreate(Sender: TObject);
begin
  Tag := TTest.Create(Self).Tag;



  var Edit: TEdit;
  var Cont: TControl;

  Edit := TEdit.Create(Self);
  Cont := Edit;

  TLabel(Edit).Caption := '';  // Ja, Caption gibt es seit TControl, aber meistens ist es einfach nur im Protected versteckt.
  TLabel(Cont).Caption := '';
  Edit.Caption := '';  // [dcc32 Fehler] E2362 Auf protected-Symbol TControl.Caption kann nicht zugegriffen werden

  Edit.Text := '';
  Cont.Text := '';  // [dcc32 Fehler] E2362 Auf protected-Symbol TControl.Text kann nicht zugegriffen werden
end;

[Bodenseematze]

Zitat von himitsu:

[add] OMG, einen vergessenen Tab gefunden und wo Firefox sich so Mühe gegeben hat das Geschriebene im Editor, trotz mehrfacher Abstürze, Neustarts und disableter Tabs zu merken ......... klick ich mal auf Senden
Falls noch was fehlt und ich es noch nicht geschrieben hab ... hab's eh vergessen[/add]

Ich schmeiß' mich weg - aus den Tiefen des Firefox "gerettet"