Hallo DPler,

ich habe ein merkwürdigen Fehler manchmal wird nach Start meiner Anwendung ein Fehler in der Bereichsprüfung ausgelöst
und manchmal kann ich die Anwendung so oft starten wie ich will es kommt kein Fehler.

Und zwar werden nach dem Start Daten aufbereitet und dies soll durch ein blinkendes Icon in der Statuszeile (TStatusBar)
angezeigt werden, dazu wird ein Timer gestartet der alle paar Millisekunden eine Prozedur aufruft die ein Icon in der
Statusbar anzeigen soll.

Das Icon wird aus einer ImageList geladen und dann via SendMessage in eine StatusBar eingebunden, hier jedoch tritt dann
gelegentlich der Fehler in der Bereichsprüfung auf, ich habe nur keinen Schimmer wie und was ich machen muß damit der
Fehler nicht mehr kommt.

Ich hab einen Beitrag Link gefunden der evtl. ein ähnliches Problem enthält wie meins, jedoch ohne Lösung.
In dem Beitrag wird was von einer geänderten Handle größe gesprochen.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TfrmMain.pShowStatusBarIcon(IconIdx: Byte; bShow: Boolean; Panel: Byte);
begin
  if (IconIdx < imlStatusBar.Count) then begin
  
    if bShow then begin
      //Icon holen...
      imlStatusBar.GetIcon(IconIdx, AnimatedIcon);

      //Icon anzeigen
      try
        SendMessage(barStatus.Handle, SB_SETICON, Panel, AnimatedIcon.Handle);
      except
        on E: exception do begin
          ShowMessage(E.Message);
        end;
      end;

    end
    else begin
      //Icon wieder löschen
      SendMessage(barStatus.Handle, SB_SETICON, Panel, 0);
    end;{else}

  end;{if IconIdx Ok}

end;

Hmm niemand eine Idee was den Fehler in der Bereichsprüfung auslöst, bzw. wie man diesen verhindert!?

Hallo,

was ich hier vermisse sind ein paar Asserts,

z.B.

Assert(barStatus.Handle>0);
Assert(AnimatedIcon.Handle>0);


Heiko

WParam und LParam sind idiotischerweise von CodeGear als Integer (LongInt) deklariert worden und von daher könnte AnimatedIcon.Handle einen Wert > MaxInt haben, so dass er ein Problem bekommt. Gleiches für das Fensterhandle...

Zitat von Muetze1:

WParam und LParam sind idiotischerweise von CodeGear als Integer (LongInt) deklariert worden und von daher könnte AnimatedIcon.Handle einen Wert > MaxInt haben, so dass er ein Problem bekommt. Gleiches für das Fensterhandle...

Ich habe mal etwas versucht, ob es damit nun klappt weiß ich noch nicht, zur Zeit erhalte ich den Fehler nicht.
Ich bin mir nicht sicher ob mit der Zeit die Handle immer höher indiziert werden und somit erst später und nicht
"kurz" nach Rechner start auftreten.

Was ich mich jetzt nur Frage der Compiler meldet: "Warnung: Vorzeichenbehaftete und -lose Typen werden verglichen - beide Operanden werden erweitert"
wie ich diese Warnung wieder weg bekomme.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TfrmMain.pShowStatusBarIcon(IconIdx: Byte; bShow: Boolean; Panel: Byte);
begin
  if (IconIdx < imlStatusBar.Count) then begin
  
    if bShow then begin
      //Icon holen...
      imlStatusBar.GetIcon(IconIdx, AnimatedIcon);

      //Icon anzeigen
      try
        if (barStatus.Handle <= MaxInt) and (AnimatedIcon.Handle <= MaxInt) then
          SendMessage(barStatus.Handle, SB_SETICON, Panel, AnimatedIcon.Handle);
      except
        on E: exception do begin
          ShowMessage(E.Message+': '+IntToStr(barStatus.Handle)+' '+IntToStr(Panel)+' Icon: '+IntToStr(AnimatedIcon.Handle));
        end;
      end;

    end
    else begin
      //Icon wieder löschen
      if (barStatus.Handle <= MaxInt) then
        SendMessage(barStatus.Handle, SB_SETICON, Panel, 0);
    end;{else}

  end;{if IconIdx Ok}

end;

Zitat von hoika:

Hallo,

was ich hier vermisse sind ein paar Asserts,

z.B.

Assert(barStatus.Handle>0);
Assert(AnimatedIcon.Handle>0);


Heiko

Also das man mit "Assert" etwas prüfen kann, habe ich ja soweit verstanden jedoch nicht so ganz wie ich das einsetzen soll
in der OH steht auch das man "Assert" nicht in einer Fertigen Anwendung einsetzen soll, ich verstehe das eher als Debug
Möglichkeit.

1. Was soll die Abfrage bringen? Sende die Daten doch - du musst dem Compiler nur sagen, er sollte es bitte als LongWord bzw. Cardinal übertragen und nicht die Datentypanpassung vornehmen zu einem Integer.
2. Assert() als Befehl einfügen und gut. Ob diese beachtet werden legst du in den Projektoptionen unter Compiler fest. Sprich: Beim Release Build kannst du die Assertions abwählen und schon sind die Abfragen alle nicht umgesetzt. Ich für meinen Teil habe diese auch in der Release Version aktiviert, da diese nur Werte und Bedingungen prüfen die absolut nicht sein sollten und damit bei auftreten zu weitreichenden und schweren Fehlern führe (u.a. Datenänderung/-verfälschung). Lieber um die Stelle wissen und entsprechend beheben als dies niemals zu erfahren und defekte Daten zu haben.

Und wenn der Kunde mal einen Datensatz nicht schreiben kann, dann ist es ihm wohl lieber als das die ganze DB zerschossen wäre. Und so hat er nach dem Fehler die Gewissheit, dass du vom Code her diesen entsprechend beachtest, behandelst - und wenn möglich - die Ursache behoben hast. Dafür sind die Assertions da.

@Muetze.
Du solltest aber Assertions und Exceptions nicht durcheinanderbringen.

Zitat von Muetze1:

1. Was soll die Abfrage bringen? Sende die Daten doch - du musst dem Compiler nur sagen, er sollte es bitte als LongWord bzw. Cardinal übertragen und nicht die Datentypanpassung vornehmen zu einem Integer.

Naja ich dachte wenn ich verhinder das SendMessage ausgeführt wird wenn das Handle größer MaxInt ist dann der Fehler
in der Bereichsprüfung nicht mehr auftaucht. Das hatte ich wohl falsch verstanden.

Und wie sag ich dem Compiler das er das als LongWord bzw. Cardinal senden soll, ich dachte die Handle sind vom Typ Cardinal!?

Ich versteh das alles noch nicht so recht. Und mit den "Assertions" is ja in Ordnung wenn man dadurch herrausfindet das ein
Fehler vorliegt und wo er ist, jedoch wäre es doch besser man verhindet das überhaupt ein Fehler auftritt. Ich mein im Release
Build kann man auch die Bereichsprüfung abschalten dann ist auch alles mehr oder weniger in Ordnung und es tritt kein Fehler
auf, aber nur weil man etwas nicht sieht heißt es nicht das es nicht doch da ist.

Zitat von sirius:

@Muetze.
Du solltest aber Assertions und Exceptions nicht durcheinanderbringen.

Dito, habe ich nämlich nicht! Ich habe nichts von Exceptions geschrieben oder beschrieben. Anscheinend verwechselst du Exceptions und Assertions.

Zitat von TUX_der_Pinguin:

Naja ich dachte wenn ich verhinder das SendMessage ausgeführt wird wenn das Handle größer MaxInt ist dann der Fehler in der Bereichsprüfung nicht mehr auftaucht. Das hatte ich wohl falsch verstanden. :gruebel:

Der Fehler würde dann nicht mehr auftauchen, aber die Message auch nicht versandt - und die ist bestimmt nicht an der Codestelle, weil es so schöner aussieht...

Zitat von TUX_der_Pinguin:

Und wie sag ich dem Compiler das er das als LongWord bzw. Cardinal senden soll, ich dachte die Handle sind vom Typ Cardinal!?

Senden tut er 32 Bit für den WParam und LParam, also inklusive des 31. Bits. Ob dies aber nun als Vorzeichen oder nicht interpretiert wird, definiert der Datentyp. Die Funktion will einen Datentyp wo das 31. Bit ein Vorzeichen ist. Also direkt casten, also Delphi sagen, er soll die 32 Bits als Integer sehen. Bisher sieht er es als Cardinal an und sieht er braucht integer. Somit wandelt er es um, aber löst eine exception aus, wenn der Wert nicht in das Ziel passt, was bei Werten > MaxInt der Fall ist. Um diese Umwandlung (damit die Prüfung) zu umgehen, einfach hart sagen: Delphi, das ist kein Cardinal, das siehst du falsch - das ist ein Integer. Also nix machen, das passt doch...

SendMessage(barStatus.Handle, SB_SETICON, integer(Panel), integer(AnimatedIcon.Handle));

Hallo,

Zitat:

Was ich mich jetzt nur Frage der Compiler meldet: "Warnung: Vorzeichenbehaftete und -lose Typen werden verglichen - beide Operanden werden erweitert"
wie ich diese Warnung wieder weg bekomme.

Ich hoffe, die Warnung wurde nicht schon von Anfang angezeigt ???
Wenn ja, hättest du usn das mal sagen können.


Heiko