Optimierung Unverständlich

[venice2]

Wenn ich Debug und Release 64 Bit das Flag Optimieren einschalte dann wird nichts mehr gezeichnet.
Woran kann das liegen?

Ist mir Unverständlich was Delphi dann macht.
Meines Erachtens hat das überhaupt keinen Vorteil.

[venice2]

Zur Veranschaulichung.
Am Code wurde nichts geändert nur die Optimierung eingeschaltet.

[DieDolly]

Sagt die Console irgendetwas, wenn du das Projekt bereinigst und neu kompilierst?

[venice2]

Zitat:

Zitat von DieDolly (Beitrag 1483393)

Sagt die Console irgendetwas, wenn du das Projekt bereinigst und neu kompilierst?

Console? Wie meinst du das.
DCU's lösche ich immer über eine Batch Datei.

Nebenbei ist bei 32Bit das gleiche.

[DieDolly]

Das Fenster "Meldungen" meine ich. Irgendwelche Warnungen oder Informationen, dass dieses oder jenes wegen Optimierung entfernt wurde.
Vielleicht sieht man im Debugger mehr.

[Daniel]

Es ist ja nicht so, dass Programmcode auf magische Weise verschwindet.
Du wirst Deinen Code mit dem Debugger analysieren müssen und prüfen, an welcher Stelle der beabsichtige Programmablauf verlassen wird.

[venice2]

Zitat:

Zitat von DieDolly (Beitrag 1483395)

Das Fenster "Meldungen" meine ich. Irgendwelche Warnungen oder Informationen, dass dieses oder jenes wegen Optimierung entfernt wurde.
Vielleicht sieht man im Debugger mehr.

0 Warnungen, 0 Error.

Zitat:

Es ist ja nicht so, dass Programmcode auf magische Weise verschwindet.
Du wirst Deinen Code mit dem Debugger analysieren müssen und prüfen, an welcher Stelle der beabsichtige Programmablauf verlassen wird.

Ohne Optimierung läuft es doch.
Deshalb ja die frage was macht Delphi btw. der Compiler das mit diesen Flag nichts mehr gezeichnet wird.
Das der Code sich nicht ändert ist klar sagte ich aber schon.. Aber das Flag Optimieren zerschießt irgend etwas. Sieht man ja auch.

Wenn niemand darüber klare aussagen treffen kann dann ist es halt so. Bleibt sie halt aus.
Vorteil habe ich bisher eh noch keinen gesehen.

Mit Optimierung debuggen schlechte Idee.. weil die hälfte vom Linker wegoptimiert wird.

[jaenicke]

Zitat:

Zitat von venice2 (Beitrag 1483397)

Das der Code sich nicht ändert ist klar sagte ich aber schon.. Aber das Flag Optimieren zerschießt irgend etwas. Sieht man ja auch.

Es gibt zwei Möglichkeiten:
- Es ist wirklich ein Bug im Compiler. Gab es schon, ist aber recht selten.
- Die Optimierung sorgt dafür, dass im Speicher etwas anderes steht oder ähnliches, so dass ein Bug dann erst zutage tritt. Das habe ich schon mehrfach, auch in Forenbeiträgen hier, gesehen.

Hast du die Bereichsprüfung aktiv? Sagt FastMM etwas im FullDebugMode?

[venice2]

Zitat:

Zitat von jaenicke (Beitrag 1483401)

Zitat:

Zitat von venice2 (Beitrag 1483397)

Das der Code sich nicht ändert ist klar sagte ich aber schon.. Aber das Flag Optimieren zerschießt irgend etwas. Sieht man ja auch.

Es gibt zwei Möglichkeiten:
- Es ist wirklich ein Bug im Compiler. Gab es schon, ist aber recht selten.
- Die Optimierung sorgt dafür, dass im Speicher etwas anderes steht oder ähnliches, so dass ein Bug dann erst zutage tritt. Das habe ich schon mehrfach, auch in Forenbeiträgen hier, gesehen.

Hast du die Bereichsprüfung aktiv? Sagt FastMM etwas im FullDebugMode?

Ja Always!

Danke für die Info.
Es ist schwer mit eingeschalteter Optimierung das Projekt zu debuggen.
Aber ich habe mit "Windows Detective" das Problem analysieren können.

Die Optimierung gibt falsche werte bei TRect zurück warum auch immer.
Normal!
30,60,900,506

Die Optimierung macht daraus.
32XXX, irgendwas, irgendwas, irgendwas

Bedeutet mein (PopUp)Fenster ist nicht an der Position wo es sein sollte. (gezeichnet wird, nur ich kann es dann nicht mehr sehen) Außerhalb des Bildschirms.
Habe jetzt ein Child Fenster draus gemacht damit geht's. (Muß mir dafür keinen Rect holen)

Denke nicht das TRect ein Problem bei der Bereichsprüfung auslösen könnte. (wird auch nichts gemeldet)
Ohne Optimierung geht es ja.

Qualität ist besser wird hier wieder nach *.jpg konvertiert.

[himitsu]

Wie schon gesagt, entweder ist dein Code so ungünstig/fehlerhaft, wo der Fehler so aber erst "richtig" auffällt,
oder es ist wirklich ein Compiler-Fehler.

So oder so, kann es nicht schaden den Fehler zu finden
* entweder bei Emba melden, damit er behoben werden kann
* oder den eigenen Code raparieren, denn es kann auch gut sein, dass er bisher unbemerkte Fehler verursacht oder es später auch durch was Anderes wieder so auffällt

[venice2]

Zitat:

So oder so, kann es nicht schaden den Fehler zu finden

Theoretisch ja, Praktisch nein.

Sage mir wie ich TRect das ja in den jeweiligen Units nehme ich an, korrekt definiert ist für die Optimierung (einen Fehler beheben soll) ?

Delphi-Quellcode:

var
  rc: TRect;
begin
  GetWindowRect(WinHandle, rc);

end;

Wie oder wo soll ich jetzt "rc" korrigieren wenn hier falsch werte bei der Optimierung übergeben werden.
Ist wohl unmöglich denke ich mal.

Wenn also GetWindowRect mit eingeschalteter Optimierung undefinierte Werte für "rc" liefert was soll ich dann tun?
Denke mal ebenfalls nichts.

Wenn man solche Werte wie auf den Bildern bekommt wird man wohl von seinem Fenster nichts sehen. ;)

[KodeZwerg]

Nuja. Delphi ist halt nicht gleich Delphi.
Man kann komplett WinApi oder auf integrierte Fassungen zurückgreifen, was dich dann enttäuschen mag.
Als erfahrener api Anwender rate ich dir, Schuster bleib bei dein leisten.
Du weißt was du tust, bleib dabei:-)

[venice2]

Zitat:

Zitat von KodeZwerg (Beitrag 1483411)

Nuja. Delphi ist halt nicht gleich Delphi.
Man kann komplett WinApi oder auf integrierte Fassungen zurückgreifen, was dich dann enttäuschen mag.
Als erfahrener api Anwender rate ich dir, Schuster bleib bei dein leisten.
Du weißt was du tust, bleib dabei:-)

Willst du mir etwas bestimmtes sagen?
Dein Beitrag ist undefiniert genauso wie das Problem mit dem Optimieren.

Es trägt nichts zu meinen Problem bei! Hauptsache kommentiert wie auch immer.

[Daniel]

Naja, Du hast den Fehler ja bereits lokalisieren und korrigieren können. Damit kommen doch gar nicht mehr so viele Stellen in Frage. GetWindowRect ist eine boolsche Funktion. Du könntest also den Rückgabewert prüfen. Vermutlich wird dieser „false“ sein, wenn Dein Rect falsch befüllt wird. Das wäre ein Indiz dafür, dass das Fenster-Handle zu diesem Zeitpunkt ungültig ist.
//Edit: Aus der Dokumentation: „To get extended error information, call GetLastError.“
Es gibt also schon Dinge, die man tun könnte, wenn falsche Werte zurückkommen.

[venice2]

Zitat:

Zitat von Daniel (Beitrag 1483413)

Naja, Du hast den Fehler ja bereits lokalisieren und korrigieren können. Damit kommen doch gar nicht mehr so viele Stellen in Frage. GetWindowRect ist eine boolsche Funktion. Du könntest also den Rückgabewert prüfen. Vermutlich wird dieser „false“ sein, wenn Dein Rect falsch befüllt wird. Das wäre ein Indiz dafür, dass das Fenster-Handle zu diesem Zeitpunkt ungültig ist.

Es ist nicht ungültig da es direkt davor erstellt wird.
Das WinHandle selbst ist dieses von der Anwendung die läuft ja im Hintergrund und das Fenster das ich öffne ist ein Dialog darüber.
Und das schlägt bei der Optimierung fehl.

Wäre das Handle falsch würde es auch ohne Optimierung falsche Werte liefern tut es aber nicht. :)
Deshalb verstehe ich das auch nicht.

Delphi-Quellcode:

  
  GetWindowRect(DialogHandle, rc);
  ClientToScreen(DialogHandle, p);
  
  TMDBInfoDlgCont := CTRL_SpriteContainerCreate;
  TMDBInfoDlgCont.Left := p.x + 30;
  TMDBInfoDlgCont.Top := p.Y + 60;
  TMDBInfoDlgCont.Width := 900;
  TMDBInfoDlgCont.Height := 506;
  TMDBInfoDlgCont.AnchorMode := ANCHOR_HEIGHT_WIDTH;
  TMDBInfoDlgCont.DwStyle := WS_POPUP or WS_CLIPSIBLINGS or WS_CLIPCHILDREN;
  TMDBInfoDlgCont.DwExStyle := WS_EX_TOOLWINDOW;
  TMDBInfoDlgContH := TMDBInfoDlgCont.CreateWindow(DialogHandle, hInstance);

  if TMDBInfoDlgContH <> 0 then // Handle ist gültig
  begin
    bmW := 0;
    bmH := 0;

    GetWindowRect(TMDBInfoDlgContH, lpr); // TRect liefert undefinierbare Werte bei eingeschalteter Optimierung, sonst nicht.

Zitat:

Es gibt also schon Dinge, die man tun könnte, wenn falsche Werte zurückkommen.

Ja. Sinnvoll wenn es bei beiden varianten ein Problem gäbe aber ohne Optimierung ist das Handle sowie der Rect richtig.
Und es werden korrekte werte zurück gegeben.

Ich halte nochmal fest.
Es funktioniert ohne Optimierung mit leider nicht.
Also kann es am Code definitiv nicht liegen denn dann dürfte beides nicht gehn.

[jfheins]

Zitat:

Zitat von venice2 (Beitrag 1483414)

Zitat:

Es gibt also schon Dinge, die man tun könnte, wenn falsche Werte zurückkommen.

Ja. Sinnvoll wenn es bei beiden varianten ein Problem gäbe aber ohne Optimierung ist das Handle sowie der Rect richtig.
Und es werden korrekte werte zurück gegeben.

Ich halte nochmal fest.
Es funktioniert ohne Optimierung mit leider nicht.
Also kann es am Code definitiv nicht liegen denn dann dürfte beides nicht gehn.

Normalerweise wird da eher umgekehrt ein Schuh draus: Die Optimierung ist seit Jahrzehnten verfeinert und verbessert um keine Bugs in korrekt geschriebene Programme einzufügen.
Wenn es also in deinem Programm ein Problem gibt, das nur mit Optimierung auftritt, dann liegt es vermutlich an deinem Programm.

Ein Programm, das manchmal richtig funktioniert, ist noch nicht unbedingt sinnvoll einsetzbar. Erst ein Programm, was immer (oder zumindest fast immer) richtig funktioniert ist wirklich gut ;-)

[jaenicke]

Zitat:

Zitat von venice2 (Beitrag 1483414)

Also kann es am Code definitiv nicht liegen denn dann dürfte beides nicht gehn.

Beispielsweise könnte der Typ von TMDBInfoDlgContH falsch sein und so der Wert abgeschnitten werden, wenn der Variablentyp zu klein für den Wert ist. Wie gesagt, das ist nur ein Beispiel, aber es gibt schon diverse Varianten, bei denen der Code eigentlich gar nicht korrekt ist, aber zufällig doch geht.

Da du nun weißt wo der Fehler auftritt:
Kannst du nicht den ganzen anderen Code rauswerfen um dann hier ein Projekt zu posten, bei dem der Fehler nachvollziehbar ist?
Ich bin mir sicher, dass dann schnell die Ursache klar wäre.

[venice2]

Zitat:

Zitat von jfheins (Beitrag 1483415)

Zitat:

Zitat von venice2 (Beitrag 1483414)

Zitat:

Es gibt also schon Dinge, die man tun könnte, wenn falsche Werte zurückkommen.

Ja. Sinnvoll wenn es bei beiden varianten ein Problem gäbe aber ohne Optimierung ist das Handle sowie der Rect richtig.
Und es werden korrekte werte zurück gegeben.

Ich halte nochmal fest.
Es funktioniert ohne Optimierung mit leider nicht.
Also kann es am Code definitiv nicht liegen denn dann dürfte beides nicht gehn.

Normalerweise wird da eher umgekehrt ein Schuh draus: Die Optimierung ist seit Jahrzehnten verfeinert und verbessert um keine Bugs in korrekt geschriebene Programme einzufügen.
Wenn es also in deinem Programm ein Problem gibt, das nur mit Optimierung auftritt, dann liegt es vermutlich an deinem Programm.

Ein Programm, das manchmal richtig funktioniert, ist noch nicht unbedingt sinnvoll einsetzbar. Erst ein Programm, was immer (oder zumindest fast immer) richtig funktioniert ist wirklich gut ;-)

Das hilft mir nicht weiter. Aber Bitte..

[venice2]

Zitat:

Zitat von jaenicke (Beitrag 1483416)

Zitat:

Zitat von venice2 (Beitrag 1483414)

Also kann es am Code definitiv nicht liegen denn dann dürfte beides nicht gehn.

Beispielsweise könnte der Typ von TMDBInfoDlgContH falsch sein und so der Wert abgeschnitten werden, wenn der Variablentyp zu klein für den Wert ist. Wie gesagt, das ist nur ein Beispiel, aber es gibt schon diverse Varianten, bei denen der Code eigentlich gar nicht korrekt ist, aber zufällig doch geht.

Da du nun weißt wo der Fehler auftritt:
Kannst du nicht den ganzen anderen Code rauswerfen um dann hier ein Projekt zu posten, bei dem der Fehler nachvollziehbar ist?
Ich bin mir sicher, dass dann schnell die Ursache klar wäre.

TMDBInfoDlgContH: HWND;

Nochmal wenn der Code falsch wäre würde es auch ohne Optimierung nicht funktionieren.
Trotz allem Danke.

EDIT:

Zitat:

Es gibt also schon Dinge, die man tun könnte, wenn falsche Werte zurückkommen.

Habe es mal getestet

Delphi-Quellcode:

    if GetWindowRect(TMDBInfoDlgContH, lpr) then
    begin
      //...
    end else
    raise Exception.Create(SysErrorMessage(GetLastError));

Kein Fehler läuft durch aber Koordinaten sind falsch.
Ich lasse es jetzt ohne Optimierung macht keinen sinn.

[jaenicke]

Das ist natürlich deine Entscheidung. Ich kann nur anbieten es zu analysieren. Im Zweifelsfall lohnt ein Vergleich des generierten Assemblercodes.

[KodeZwerg]

Zitat:

Zitat von venice2 (Beitrag 1483418)

Nochmal wenn der Code falsch wäre würde es auch ohne Optimierung nicht funktionieren.
Trotz allem Danke

Genau das ist es was ich oben meinte. Kein ^so gehts also halt dich dran^ Typ, sondern eher der Rebell der weiß was er will Mensch-Typ.

Sorry, bin heute gut drauf und finds gut auch wenn es zur Problemlösung nicht viel weiter hilft und werde mich nun deines alten Wunsches wieder von dir fern halten.

[himitsu]

Zitat:

Nochmal wenn der Code falsch wäre würde es auch ohne Optimierung nicht funktionieren.
Trotz allem Danke.

Nein.

Es kann zufall sein, dass es da grade geht.
Und genauso kann es morgen auch ohne Optimierung nicht mehr funktionieren.

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1483421)

Zitat:

Nochmal wenn der Code falsch wäre würde es auch ohne Optimierung nicht funktionieren.
Trotz allem Danke.

Nein.

Es kann zufall sein, dass es da grade geht.
Und genauso kann es morgen auch ohne Optimierung nicht mehr funktionieren.

Ich melde mich in einem Monat nochmal zu dem Thema und beantworte dir die frage ob es Zufall ist oder nicht. ;)

[jaenicke]

Zitat:

Zitat von venice2 (Beitrag 1483424)

Ich melde mich in einem Monat nochmal zu dem Thema und beantworte dir die frage ob es Zufall ist oder nicht. ;)

Zufall heißt in diesem Fall Pseudozufall. Und das kann heißen, dass es ohne weitere Änderungen am Code immer funktioniert, aber eine andere Änderung dann plötzlich zu Problemen führt, obwohl diese eigentlich gar nichts damit zu tun hat.

Es ist ja nicht so, dass solche Probleme nicht bekannt wären. Ich habe nach solchen Problemen schon viele Stunden gesucht inkl. Analyse von Speicherdumps usw., wobei dann auch schon herauskam, dass das Problem gar nicht im eigenen Code lag. Zum Beispiel musste ich damals bei der BDE Änderungen im Speicher vornehmen damit die BDE unter Windows 7 noch sauber beendet werden konnte (konditionaler Jump in fixen Jump geändert). In solchen Fällen kommt dann erschwerend hinzu, dass man gar nicht weiß wie die Abläufe in dem fremden Code sind, man aber nur den Assemblercode zur Analyse hat.

Das heißt bei solchen Problemen wie bei dir ist die Analyse noch verhältnismäßig einfach...

[Daniel]

Dem stimme ich zu - aber da Email nun mehrfach bestätigt hat, die Sache vorläufig nicht weiter verfolgen zu wollen, sollten wir es auch dabei belassen.