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

[JoelH]

Ich habe einmal

Delphi-Quellcode:

PROCEDURE TMainForm.ColorGridDrawCell(Sender: TObject; ACol, ARow: Integer;
Rect: TRect; State: TGridDrawState);
BEGIN
WITH ColorGrid.Canvas DO
BEGIN
CASE (ACol * ARow) MOD 11 OF
0: Brush.Color := clBtnFace;
1: Brush.Color := clYellow;
2: Brush.Color := clWhite;
3: Brush.Color := clBlue;
4: Brush.Color := clRed;
5: Brush.Color := clNavy;
6: Brush.Color := clMaroon;
7: Brush.Color := clGreen;
8: Brush.Color := clAqua;
9: Brush.Color := clFuchsia;
10: Brush.Color := clPurple;
END;
IF (ColorGrid.Selection.Left = ACol) AND (ColorGrid.Selection.Top = ARow) THEN
Brush.Color := clLime;
FillRect(Rect);
Font.Color := Brush.Color XOR 65535;
TextOut(Rect.Left, Rect.Top, ColorGrid.Cells[ACol, ARow]);
END;
END;

von hier Beispiel

Das geht auch und in meinem Programm geht es so auch aber wenn ich das so umbauen will, weil ich viel Grids hab die unterschiedlich eingefärbt werden sollen hab ich gemacht

Delphi-Quellcode:

procedure Tfrm_Objektuebersicht.stg_patenschaftenDrawCell(Sender: TObject;
  ACol, ARow: Integer; Rect: TRect; State: TGridDrawState);
var reihen : Array od Integer;
begin
  setlength(reihen,1);
  reihen[0] := 1;
  Gridcolor(Sender,ACol, ARow, Rect, State, reihen);
end;

Also quasi einen Parameter dazu gemacht welche Spalten er einfügen soll und dann sieht die GridColor Procedure so aus

Delphi-Quellcode:

procedure Gridcolor(Sender: TObject;
  ACol, ARow: Integer; Rect: TRect; State: TGridDrawState; geldrows : Array of Integer);
var check : boolean;
    i : integer;
begin
  with Sender as TStringgrid do
  begin
    WITH Canvas DO
    BEGIN
      check := false;
      for i := 0 to length(geldrows)-1 do
      begin
        if ARow = geldrows[i] Then check := true;
      end;
      if (ARow <> 0) AND (check) then
        Brush.Color := schriftfarbe
      else
        Brush.Color := gridhintergrund;
      END;
      IF (Selection.Left = ACol) AND (Selection.Top = ARow) THEN
        Brush.Color := clLime;
      FillRect(Rect);
      Font.Color := Brush.Color XOR 65535;
      TextOut(Rect.Left, Rect.Top, Cells[ACol, ARow]);
    END;
  end;
end;

leider mault er dann =>

Zitat:

[Error] U_extra.pas(684): Incompatible types: 'HDC' and 'TRect'

warum nur ?

[jbg]

Zitat:

Delphi-Quellcode:

      if (ARow <> 0) AND (check) then 
        Brush.Color := schriftfarbe 
      else 
        Brush.Color := gridhintergrund; 
      END;

Wo ist den hier das zum END dazugehörende begin ? Hier machst du die with Canvas do Anweisung zu, womit sich FillRect und TextOut auf die Funktionen in Windows.pas beziehen und nicht auf die Canvas Methoden.

[Keldorn]

Zitat:

Zitat von JoelH

Also quasi einen Parameter dazu gemacht welche Spalten er einfügen soll und dann sieht die GridColor Procedure so aus

Delphi-Quellcode:

procedure Gridcolor(Sender: TObject;
  ACol, ARow: Integer; Rect: TRect; State: TGridDrawState; geldrows : Array of Integer);
var check : boolean;
    i : integer;
begin
  with Sender as TStringgrid do
  begin
    WITH Canvas DO
    BEGIN  //1
      check := false;
      for i := 0 to length(geldrows)-1 do
      begin   //2
        if ARow = geldrows[i] Then check := true;
      end;    //2
      if (ARow <> 0) AND (check) then
        Brush.Color := schriftfarbe
      else
        Brush.Color := gridhintergrund;
      END;    //1  --<<<<<<< das end ist zuviel 
      IF (Selection.Left = ACol) AND (Selection.Top = ARow) THEN
        Brush.Color := clLime;
      FillRect(Rect);
      Font.Color := Brush.Color XOR 65535;
      TextOut(Rect.Left, Rect.Top, Cells[ACol, ARow]);
    END;
  end;
end;

da ist ein end zuviel.

//eidt: zu langsam ;)

Mfg Frank

[JoelH]

upps, dank euch. Tolle Fehlermeldung, so schön passend :( Das END; ist wohl noch von der Caseanweisung hängen geblieben :(

[Tom]

Klage nicht ...
Du wolltest Canvas.FillRect aufrufen, hast aber tatsächlich - durch das fehlende End - die API-Funktion FillRect aufgerufen. Die hat nun mal andere Parameter.

Nebenbei: Die Fehlermeldung stand doch nicht alleine, oder? Spätestens am Ende der Fehlermeldungen muss doch irgendetwas von einem fehlenden End gestanden haben, bzw. dass "End." nicht korrekt ist.

[jbg]

Nicht "fehlend" sondern zuviel.

[JoelH]

@Tom
nicht wirklich, k.a. , ich hab in dem Projekt 87 Hints und 43 Warnings, da guck man nimmer so genau ;)

[Tom]

Dann solltest Du als erstes mal dafür sorgen, dass die Meldungen sich auf Null reduzieren. Schließlich möchte Dir der Compiler mit diesen etwas mitteilen.

[JoelH]

Delphi-Quellcode:

[Warning] dlg_arbeitstagekalender.pas(45): Method 'Create' hides virtual method of base type 'TCustomForm'

was soll ich gegen sowas machen ?

Und die Hints sind meist von Variablen die in Proceduren nimmer gebraucht werden etc.. Das übliche halt, damit hab ich keine Probleme.

[jbg]

Zitat:

Zitat von JoelH

Delphi-Quellcode:

[Warning] dlg_arbeitstagekalender.pas(45): Method 'Create' hides virtual method of base type 'TCustomForm'

was soll ich gegen sowas machen ?

Schreib ein override hinter den Konstruktor.

Zitat:

Und die Hints sind meist von Variablen die in Proceduren nimmer gebraucht werden etc.. Das übliche halt, damit hab ich keine Probleme.

Deine Anwendung aber eine Zeitbombe.

[Tom]

Zitat:

Zitat von JoelH

Das übliche halt,

Üblich ist das nicht. Normal sind Null Meldungen/Warnungen, wenn man vernünftig arbeitet. Die Meldung "Bla bla ist plattformspezifisch ..." nimmt ggf. eine Sonderstellung ein.

Zitat:

damit hab ich keine Probleme.

Doch hast Du. Hättest Du nämlich normalerweise Null Meldungen/Warnungen hättest Du im konkreten Fall den Hinweis auf das überflüssige End nicht übersehen.

Ansonsten: Tick, Tick, Tick ...

[JoelH]

@jbg
Geht net, das Create ist überladen, also ist nix mit Override ;) Iss ja ein OVERLOAD.

@Tom

Zitat:

[Warning] dlg_auszahlung_anweisen.pas(615): Variable 'mwst' might not have been initialized

Ich weiss dass es initialisiert wird, der Compiler weiss es nicht, er vermutet dass es nicht initialisiert sein könnte. Warum sollte ich diese Warning abfangen ?

Ich weiss, es geht um Prinzip aber nicht alles was der Compiler sagt muss auch wirklich schädlich sein sondern ist einfach eine Fehleinschätzung !

[Tom]

Zitat:

Zitat von JoelH

Ich weiss dass es initialisiert wird, der Compiler weiss es nicht, er vermutet dass es nicht initialisiert sein könnte.

Das ist zunächst einmal eine Behauptung von Dir. Liefer doch mal einen Beweis (Source).

[jbg]

Zitat:

Zitat von JoelH

Geht net, das Create ist überladen, also ist nix mit Override ;) Iss ja ein OVERLOAD.

Da gibt es auch noch reintroduce. Aber ob das nötig ist, kann ich nur mit dem Konstruktor(en) Deklarationen (nicht Inhalt) sagen.

Zitat:

Ich weiss, es geht um Prinzip aber nicht alles was der Compiler sagt muss auch wirklich schädlich sein sondern ist einfach eine Fehleinschätzung !

Um das Prinzip geht es hier nicht. Es geht eher darum: Wie vermeide ich tickende Zeitbomben. Du kannst nie wissen, welche Abfolgewege deine Anwender bei deinem Programm alles einschlagen. Hast du wirklich alle beachtet?
Und was, wenn mal eine Funktion aus irgendeinem sehr sehr unwahrscheinlichen Grund mal fehlschlägt? Mit GetMem/New/AllocMem kann man schön arbeiten. Aber es kann auch mal vorkommen, dass der Speicher nicht mehr ausreicht und dann kommt das FreeMem/Dispose und man hat die Bescherung.

[JoelH]

@jbg
Der Code :

Delphi-Quellcode:

  public
    { Public declarations }
    constructor Create(Aowner:Tcomponent);OVERLOAD;
    constructor Create(Aowner:Tcomponent;ab:TDate;uetage:integer);OVERLOAD;
  end;

implementation

{$R *.DFM}

uses mdimain;

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

constructor Tfrm_dlg_Arbeitstagekalender.Create(Aowner:Tcomponent;ab:TDate;uetage:integer);
begin
  inherited create(Aowner);
  aufrufart := 1;
  tage := uetage;
  abdatum := ab;
end;

@tom
war ein doofes Beispiel
ein anderes, was ich unsprünglich gemeint hatte
zB.

Zitat:

[Hint] ReportMB.pas(98): Value assigned to 'bres' never used

oder

Zitat:

[Hint] dlg_auszahlung_anweisen.pas(414): Variable 'Prefix_Text' is declared but never used in 'Tfrm_dlg_auszahlung_anweisen.Get_Betreffvorschlag '

Das sind einfach rudimente von älteren Versionen die sich rausgeschossen haben und durch den Compiler entsorgt werden.

[Tom]

Was hindert Dich daran einen Doppelklick auf die Meldung durchzuführen und den Source kurz zu korrigieren? Das sind ein paar Sekunden Arbeit.

Dann kannst Du Dir wenigstens immer alle Meldungen/Warnungen ansehen und mögliche Fehlerursachen beheben. Bei Deiner Vorgehensweise ist es zu aufwendig die echten Meldungen/Warnungen heraus zusortieren. Im Ergebnis korrigierst Du also einige Fehler nicht und Dein Programm ist eine Zeitbombe.

[JoelH]

falsch, ich korrigiere Fehler, ich entferne aber nichts rudimäntäres was man vielleicht mal wieder brauchen könnte, es wurde ja schon einmal gebraucht, warum sollte es also nicht wie in gebrauch kommen ?

[Christian Seehase]

Moin Joel,

Zitat:

Zitat von JoelH

ich entferne aber nichts rudimäntäres was man vielleicht mal wieder brauchen könnte, es wurde ja schon einmal gebraucht, warum sollte es also nicht wie in gebrauch kommen ?

Weil Du Dir dadurch die Übersicht kaputt machst (siehe die Grosse Anzahl Meldungen/Warnings). Wenn Du der Ansicht bist, dass Du es irgendwann einmal noch gebrauchen könntest, dann kommentier es doch aus, statt es zu löschen.

[JoelH]

warum sollte ich zB. Felder aus einem Query entfernen ?

von der Geschwindigkeit abgesehen ?

[jbg]

Zitat:

Zitat von JoelH

Der Code :

Delphi-Quellcode:

  public
    { Public declarations }
    constructor Create(Aowner: TComponent); overload; override;
    constructor Create(Aowner: TComponent; ab: TDate; uetage: Integer); overload;
  end;

[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 ?

[jbg]

Zitat:

Zitat von JoelH

Ich bin der Gott und nicht der Compiler, also hat der Compiler zu verstehen was ich will und nicht umgekehrt.

Der Compiler akzepiert deine Deklaration mit Murren. Also kannst du deinen Willen durchsetzen er beklagt sich nur.

Zitat:

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 !

Damit verdrehst du die ganze Sache. Der Compiler bietet alles an, was er kann. Wenn du nun aber genau dagegen steuerst, wird er eben seine Hinweise und Warnungen ausgeben.



Solange du deine Komponente nur für dich benutzt, keine abgeleitete Klasse davon erzeugst und sie nie in der IDE als Komponente registierst, sie also immer per Quellcode erzeugst, kann nie was passieren. Machst du aber nur eines dieser drei Dinge, so platzt die Zeitbome.

[JoelH]

was könnte denn passieren ?

Wenn ich den Konstruktor überlade und immer mit inherted(Create) den Ursprung mit einpacke ?