FillRect(Rect) geht und in der Unterprocedure geht es nicht

[JoelH]

welche Gefahren drohen mir wenn ich das weg lassen ?

Ich meine nicht dass ich es mir nicht merken würde aber warum das ganze ? Es ist doch total wurscht, der Constructor hat null nachteile durch meine Deklaration. Ich sehe nicht wie man mich bescheissen könnte :(

Vor allem macht dieses OVERRIDE mich eher stutzig, ich will das nicht wirklich OVERRIDEN, ich will verschiedene Konstruktoren haben die auch alle aufgerufen werden im Projekt.Da ist mir Delphi noch etwas suspekt aber ich mach es ja auch erst 3 Monate.

[jbg]

Das hat 2 Gründe.

• 1. Du hast eine Warnung weniger
• 2. Du bringst Delphi nicht durcheinander. Der virtuelle Konstruktor von TComponent hat schon seinen Nutzen und Zweck. Wenn du nun diesen nicht mit override überschreibst, fügt der Compiler automatisch das reintroduce ein. Wird deine Klasse dann von irgendwem oder irgendetwas (<= VCL) automatisch erzeugt, dann kracht es, da nicht dein Konstruktor aufgerufen wird, sondern, der virtuelle, den du ja nicht überschrieben hast.

[edit=Daniel B]List-Tags korrigiert. Mfg, Daniel B[/edit]

[JoelH]

@jbg
zu 1)
*gg*

zu 2)
versteh ich jetzt nicht. Das ist doch das Prob des COmpilers und nicht des Programmierers. Wenn ich Create zuerstmal überschreibe, was anderes mache ich ja nicht mit

Delphi-Quellcode:

 constructor Create(Aowner:Tcomponent);OVERLOAD;

Denkt euch das OVERLOAD weg und ersetzt es durch OVERRIDE !!
Wenn ich jetzt aber auch einen anderen aufruf brauche , dann überschreib ich das ganze einfach, denn IMHO sichert im Konstruktor

Delphi-Quellcode:

constructor Tfrm_dlg_Arbeitstagekalender.Create(Aowner:Tcomponent);
begin
  inherited create(Aowner);
  aufrufart := 0;
end;

das

Delphi-Quellcode:

inherited create(Aowner)

eh dass der ursprüngliche Konstruktor zum Einsatz kommt !


Wo ich allerdings noch nicht klar Delphi verstehe ist dass man wohl Konstruktoren vererben kann oder wie, dass ist natürlich ein Killer denn Sinn macht es nicht. Kein Konstruktor kann seine Childclass konstruieren, das wiederspricht ja den Sinn der Vererbung, denn dann ist die CHildclass ja nix anderes wie eine Instanz der Elternklasse .

Meine Meinung aber die Diskussion ist interessant auch wenn Tom nimmer antwortet, ist Wochenende !?

[Tom]

Zitat:

Zitat von JoelH

Meine Meinung aber die Diskussion ist interessant auch wenn Tom nimmer antwortet,

Ich finde die Diskussion müßig. Da es ansich nun einen richtigen Weg gibt entfällt ein bißchen der Sinn dieser Diskussion. Wenn Du einen anderen Weg gehen möchtest, mache das. Ich halte diesen Weg einfach für falsch und vom Gegenteil wirst Du mich nicht überzeugen können.

Ignoriere weiter Deine Meldungen/Warnungen und sei glücklich. Ich kümmer mich drum und bin auch glücklich :roll:

Zitat:

ist Wochenende !?

Ja.

[JoelH]

schad.

Denn wo ist denn de Falle bei erner Variable die nie gebracuht wird ?? Ich verstehe es echt nicht. Wenn man vielleicht mit globalen Variablen hantiert kannes zum Killer werden aber wer Globale verwendet gehört eh gesteinigt !

[Tom]

Zitat:

Zitat von JoelH

Denn wo ist denn de Falle bei erner Variable die nie gebracuht wird ??

Das Du den Wald vor lauter Bäumen nicht mehr siehst. Oder anders, Du bekommst nicht mehr kurz und knapp mitgeteilt was Sache ist und übersiehst im Wust der Meldungen die wichtigen Meldungen. So ist ja auch dieser Thread zustande gekommen.

Zitat:

aber wer Globale verwendet gehört eh gesteinigt !

Zumindest ist es besser nicht drüber zu reden ...

[jbg]

Zitat:

Zitat von JoelH

Wo ich allerdings noch nicht klar Delphi verstehe ist dass man wohl Konstruktoren vererben kann oder wie, dass ist natürlich ein Killer denn Sinn macht es nicht. Kein Konstruktor kann seine Childclass konstruieren, das wiederspricht ja den Sinn der Vererbung, denn dann ist die CHildclass ja nix anderes wie eine Instanz der Elternklasse.

Delphi-Quellcode:

function NewComponent(ComponentClass: TComponentClass): TComponent;
begin
  Result := ComponentClass.Create(nil);
end;

// ...
var
  C: TComponent;
begin
  C := NewComponent(TMyComponent);
  try
    // ...
  finally
    C.Free;
  end;
end;

Dafür braucht man virtuelle Konstruktoren. Und das wird von der VCL intern sehr stark genutzt.

[edit=Luckie]Quate-Tags gefixet. Mfg, Luckie[/edit]

[JoelH]

@Tom
wieso versinke ich, ich ignoriere einfach.

@jbg
das muss ich erst nachlesen, da bin ich ehrlich da komm ich gerade nicht mit. Aber wen ich es sehe dann verstehe ich dein Argument nicht. Ich bin der Gott und nicht der Compiler, also hat der Compiler zu verstehen was ich will und nicht umgekehrt. Ich bin kein meister der virtuellen Funktionen aber ich sehe das so, wenn der Compiler es nicht versteht dann sollte es nicht angeboten werden denn die untergräbt die Konsistenz des gesamten gGebildes !

[Tom]

Zitat:

Zitat von JoelH

wieso versinke ich, ich ignoriere einfach.

Wie schon gesagt: Ich halte die Diskussion für müßig. Du hast rund 120 Meldungen/Warnungen, übersiehst die wichtigste (Hinweis auf zuviele Ends) und siehst nicht ein, dass dieses ein Fehler ist. Wir können uns so noch 100 Jahre weiter unterhalten.

[JoelH]

falsch, ich habe nicht die verbindung zwischen der Fehlermeldung und der Ursache gesehen, natürlicvh kann man sagen dass ich der Fehler im System bin, bin ich ja auch. Aber das liegt nicht an den anderen Fehlern, denn wie gesagt, es wurden keine weiteren Folgefehler gezeigt, wie auch ?

Wenn ein End fehlt dann kommt das ein ; expected sit und ein Procedure kam, aber wenn ein END; zuviel ist wird dei folgeNachricht zur HDC expected TRect found oder wie auch immer. Das ist IMHO ein himmelweiter unterschied !

Wie auch immer, wenn es dir eh müssig ist warum ahst du dann nicht meine Fragen beantwortet ?