Codeoptimierung verursacht probleme

[EWeiss]

Warum verursacht die Code Optimierung wenn eingeschaltet unterschiedliche
Ansichten der Grafischen Oberfläche?

Wenn ausgeschaltet sieht alles normal aus wenn ein wird es Unansehnlich nicht so wie es soll.
Wenn nötig hänge ich zwei Bilder an.

gruss

[Zacherl]

Wenn die Code-Optimierung Probleme verursacht, dann liegt meiner Erfahrung nach zu 99% irgendwo ein Programmierfehler vor (Ausnahmen bestätigen natürlich die Regel). Insbesondere Buffer-Overflows werden manchmal erst durch die Optimierung enttarnt. Schalte am besten mal alle Überlaufprüfungen an - vielleicht hast du ja Glück und stößt direkt auf die verantwortliche Stelle.

[EWeiss]

Zitat:

Schalte am besten mal alle Überlaufprüfungen an

Ok Danke werde ich mal machen.

Nebenbei die DLL ist dann auch kleiner wenn die Optimierung eingeschaltet ist.
Bringt mir nur nichts wenn sich dadurch die Ansichten verändern.

Hänge mal die Bilder an.
Ausgeschalteter zustand ist korrekt.

EDIT:
Er gibt mir einen ErangeError sagt aber nicht wo. :wall:

gruss

[hoika]

Hallo,
MadExcept zeigt dir die Stelle an.
Das muss aber auch mit der IDE gehen,
wenn der RangeError kommt, F7 drücken.

[EWeiss]

Zitat:

Zitat von hoika (Beitrag 1359372)

Hallo,
MadExcept zeigt dir die Stelle an.
Das muss aber auch mit der IDE gehen,
wenn der RangeError kommt, F7 drücken.

Danke.
Wenn der Dialog erscheint zeigt er mir nichts wenn ich F7 drücke mit D2010

gruss

[EWeiss]

Beispiel..

Delphi-Quellcode:

SetRect(pr^[pData^.rdh.nCount], M, J, I, J + 1);

nCount ist DWORD die Übergabe muss aber Integer sein.

Es kracht wenn die Werte minus enthalten

Das

Delphi-Quellcode:

SetRect(pr^[Integer(pData^.rdh.nCount)]

bringt nichts.
Das ist der Grund warum ich keine Bereichs Prüfung einschalte.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1359340)

EDIT:
Er gibt mir einen ErangeError sagt aber nicht wo. :wall:

Weiß ja nicht, ob das früher anderes war, aber wenn man das Programm aus der IDE heraus im Debugger laufen lässt, kommt in der Regel eine Messagebox hoch, wo man auf Break/Anhalten klicken kann.
Außer natürlich, du hast ERangeError irgendwann mal ganz klugerweise auf ignorieren gestellt.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1359384)

Zitat:

Zitat von EWeiss (Beitrag 1359340)

EDIT:
Er gibt mir einen ErangeError sagt aber nicht wo. :wall:

Weiß ja nicht, ob das früher anderes war, aber wenn man das Programm aus der IDE heraus im Debugger laufen lässt, kommt in der Regel eine Messagebox hoch, wo man auf Break/Anhalten klicken kann.
Außer natürlich, du hast ERangeError irgendwann mal ganz klugerweise auf ignorieren gestellt.

Nö nur wo man OK klicken kann.
Und nein bei mir werden alle Native BS Exceptions behandelt.

Mit MadExcept geht's aber ich kann die ERangeError's nicht behandeln.
Ich speicher verschiedene Datentypen in propertys wenn dieses Property den Bereich eines Integer verlässt also minus wird
kracht es das kann ich aber nicht ändern.

Delphi-Quellcode:

procedure TSkinEngine.SetProperty(WinHandle: HWND; Item: integer; V: integer);
begin
  if (Item > 0) and (Item < EXTEND_EXTRA + 1) and (WinHandle <> 0) then
    SetWindowLong(WinHandle, (Item - 1) * 4, V);

end;

Delphi-Quellcode:

function TSkinEngine.GetProperty(WinHandle: HWND; Item: integer): integer;
begin
  Result := 0;

  if (Item > 0) and (Item < EXTEND_EXTRA + 1) and (WinHandle <> 0) then
    Result := GetWindowLong(WinHandle, (Item - 1) * 4);

end;

Sagen wir mal das Property das gelesen wird ist ein HDC und dieses hat einen negativen wert -123134345
Dann tritt ein ERangeError auf.

Ich kann aber bei GetWindowLong kein DWORD zurückgeben und es erwartet einen Integer für Index.
Ich wüsste jetzt nicht wie ich das behandeln sollte.

Erweitertes Beispiel:

Delphi-Quellcode:

SkinEngine.SetProperty(Handle, PROP_TEXT_COLOR, TextCol);

TextCol wird jetzt in das Property gespeichert.
TextColor ist COLORREF also DWord kann minus werte enthalten und das verletzt die Untergrenze (Integer). outofbounds

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1359379)

Beispiel..

Delphi-Quellcode:

SetRect(pr^[pData^.rdh.nCount], M, J, I, J + 1);

nCount ist DWORD die Übergabe muss aber Integer sein.

Es kracht wenn die Werte minus enthalten

Das

Delphi-Quellcode:

SetRect(pr^[Integer(pData^.rdh.nCount)]

bringt nichts.
Das ist der Grund warum ich keine Bereichs Prüfung einschalte.

gruss

Wenn du das ein bisschen entzerren würdest, wäre dir auch klarer woher der Fehler kommt.

Delphi-Quellcode:

var 
  KlugbenanntesRect: TRect;
  RectCount: DWORD;
...
begin 
  
  SetRect(KlugbenanntesRect, M, J, I, J + 1);
  RectCount := pData^.rdh.nCount; 
  if (RectCount > 0) and (RectCount < Length(pr^)) then
  begin
    pr^[RectCount] := KlugbenanntesRect;
  end;
end;

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1359388)

Zitat:

Zitat von EWeiss (Beitrag 1359379)

Beispiel..

Delphi-Quellcode:

SetRect(pr^[pData^.rdh.nCount], M, J, I, J + 1);

nCount ist DWORD die Übergabe muss aber Integer sein.

Es kracht wenn die Werte minus enthalten

Das

Delphi-Quellcode:

SetRect(pr^[Integer(pData^.rdh.nCount)]

bringt nichts.
Das ist der Grund warum ich keine Bereichs Prüfung einschalte.

gruss

Wenn du das ein bisschen entzerren würdest, wäre dir auch klarer woher der Fehler kommt.

Delphi-Quellcode:

var 
  KlugbenanntesRect: TRect;
  RectCount: DWORD;
...
begin 
  
  SetRect(KlugbenanntesRect, M, J, I, J + 1);
  RectCount := pData^.rdh.nCount; 
  if (RectCount > 0) and (RectCount < Length(pr^)) then
  begin
    pr^[RectCount] := KlugbenanntesRect;
  end;
end;

Mag ja sein das ich damit den Fehler behandeln könnte aber es gibt noch genug andere die nicht zu beheben sind.
Der Datentypen mismatch halt.
Siehe die anderen Beispiele weiter oben.

gruss