Unterschiedliche Darstellung mit und ohne laufendem Delphi

[Alucard]

Hallo zusammen.

Sorry, wegen des folgenden konfusen Texts, aber ich bekomme es einfach nicht besser auf die Reihe und weiß noch nicht mal, wo ich richtig anfangen soll -.-

alte Situation: Windows 10, Delphi 11 CE, "normal" DPI ohne Skalierung
neue Situation: Windows 11, Delphi 12 CE, "high" DPI mit 200% Skalierung

Nach dem Wechsel hatte ich die scheinbar üblichen Probleme mit High-DPI, aber weitestgehend habe ich das irgendwie hinbekommen. Mit einer Ausnahme: eins meinter Programm wird nur vernünftig dargestellt solange im Hintergrund Delphi läuft! Ich muss es nicht über den Compiler starten, auch "extern" reicht schon.

Hat irgendwer eine Idee was hier bei mir gerade los ist?


Edit: Bilder...

Zur Erklärung: Bis auf die beiden GroupBoxes zusammen mit ihrer jeweiligen ScrollBox und dem einen LabeledEdit werden alle Komponenten zur Laufzeit erzeugt. In der oberen (horizontalen) Box funktioniert (unabhängig von laufendem Delphi oder nicht) alles wie gedacht, in der vertikalen Box funktioniert es nur mit laufendem Delphi.

Die grundlegende Frage lautet: Warum hängt die Darstellung überhaupt von einem laufenden oder eben nicht laufenden Delphi ab?

[Redeemer]

Was heißt "nicht vernünftig"? Bilder!

[Alucard]

Siehe Edit im originalen Post.

Aus irgendwelchen Gründen wird in der unteren ScrollBox nur ein Teil der Komponenten erzeugt, während in der oberen alles wie vorgesehen funktioniert.

[Uwe Raabe]

Es wäre vielleicht hilfreich wenn wir wüssten, wie diese Listen zusammengestellt werden. Also nicht die Darstellung, sondern der Weg wie die Elemente ermittelt werden.

[jaenicke]

Erstens wäre Code hilfreich wie Uwe geschrieben hat.

Zweitens könntest du aber vielleicht auch selbst debuggen:
Was passiert denn, wenn du Delphi nach dem Programm startest und den Filter verwendest (wobei die Liste ja neu aufgebaut werden dürfte)? Ist die Liste dann vollständig?

Wenn dann der Fehler immer noch passiert, könntest du Delphi an den laufenden Prozess anhängen (Menü Start --> Mit Prozess verbinden).
https://docwiki.embarcadero.com/RADS...zess_verbinden
Dann kannst du normal debuggen.

Außerdem könntest du einen Button einbauen, der einfach mal die vorhandenen Komponenten und ihre Positionen auflistet. Und du könntest beim Erzeugen der Komponenten diese Information in eine Datei schreiben. Das lässt sich dann leicht vergleichen.

[gubbe]

Vielleicht nur ein Problem mit dem Dateipfad? Wo kommt denn die Liste mit den Bookmarks unten her? Wird die aus einer Datei geladen?
In den Screenshots sieht es so aus, als wären das ganz andere EInträge.

[jaenicke]

Zitat:

Zitat von gubbe (Beitrag 1545415)

Vielleicht nur ein Problem mit dem Dateipfad?

Daran habe ich zuerst gedacht, aber wenn der Start immer genauso erfolgt und nur Delphi mal läuft und mal nicht (laut Beschreibung ist das ja der einzige Unterschied bei den Starts), dürfte das nicht das Problem sein.

Auf jeden Fall sollte es sich mit dem Debugger oder Debugausgaben klären lassen.

[Redeemer]

Eins ist Release und eins ist Debug.

[Alucard]

Erstmal sorry für die arg verspätete Antwort und vielen Dank für euren Input. Leider habe ich hier im Forum ständig Login- und Passwort-Probleme. Eigentlich hatte ich die gleich folgende Antwort direkt nach Uwes Post abgesetzt, aber die hatte es irgendwie zerhagelt und ich hatte seitdem keine Zeit mehr.


Alright, das ist jetzt peinlich :oops:

Kurzfassung: Der Fehler lag gänzlich woanders und - was wichtiger ist - in meiner Verantwortung :pale:

Die Listen werden aus zwei Text-Dateien gelesen (je eine für die obere und die untere Box) und im Falle der unteren noch nach einigen Kriterien geprüft. Bei bestandener Prüfung wird das Element angezeigt, sonst halt nicht. Da ich seit der Umstellung ausschließlich Probleme im Zusammenhang mit High-DPI hatte, bin ich blöderweise betriebsblind geworden und habe übersehen, dass in dieser Prüfung der Name des Rechners auf Übereinstimmung mit einer (hart-codierten) Liste untersucht wird - ggf. schaut diese Prüfung auch, ob Delphi läuft :evil:

Delphi-Quellcode:

procedure LadenWebTools;
var User : string;
    Delphi : boolean;
    Data : TStringList;
   i : integer;
const EntryLength : integer = 6;
begin
User   := GetEnvironmentVariable('Computername');
Delphi := FindWindow('TAppBuilder', nil) <> 0;

Data := TStringList.Create;
Data.LoadFromFile('WebTools.txt');

i := 0;
SetLength(WebTools, 0);

While i <= Data.Count - 1 do
      begin
      SetLength(WebTools, Length(WebTools) + 1);

      With WebTools[High(WebTools)] do
           begin
           Name := Data[i];
           { mehr Daten... }
           Tag  := Data[i + 4];
           { mehr Daten... }

           Inc(i, EntryLength);

           { Eintrag wieder löschen, wenn
              -- kein Icon gefunden
              -- keine User Übereinstimmung
              -- bei laufendem Delphi User ignorieren }
           If (FileExists('WebTools\' + Name + '.png') = false) Or
              ( (Tag = 'Home') And (Delphi = false) And (User <> 'User_Home_1')
                                                    And (User <> 'User_Home_2')
                                                    And (User <> 'User_Home_n')  ) Or
              ( (Tag = 'Work') And (Delphi = false) And (User <> 'User_Work'  )  )
              then SetLength(WebTools, Length(WebTools) - 1);
           end;
      end;

Data.Free

For i := 0 to High(WebTools) do
    begin
    WebTools[i].Panel     := TPanel.Create(Self);
    WebTools[i].Image     := TImage.Create(Self);
    WebTools[i].Text      := TPanel.Create(Self);
    WebTools[i].BtnOpen   := TButton.Create(Self);
    WebTools[i].BtnSearch := TButton.Create(Self);

    { Design... }
    end;
end;

[jaenicke]

Das passiert. Das wichtigste ist ja, dass es nun funktioniert.

Einen Tipp habe ich aber noch. Du machst das ganze ziemlich umständlich. Einfacher und übersichtlicher wäre es so:

Delphi-Quellcode:

procedure LadenWebTools;

  function ReadNextWebTool(const ADataList: TStringList; const AIndex: Integer): TWebTool;
  begin
    Result.Name := ADataList[AIndex];
    { mehr Daten... }
    Result.Tag := ADataList[AIndex + 4];
    { mehr Daten... }
  end;

var
  User: string;
  Delphi: Boolean;
  Data: TStringList;
  CurrentTool: TWebTool;
  i : integer;
const 
  EntryLength: Integer = 6;
begin
  User := GetEnvironmentVariable('Computername');
  Delphi := FindWindow('TAppBuilder', nil) <> 0;

  Data := TStringList.Create;
  try
    Data.LoadFromFile('WebTools.txt');

    i := 0;
    SetLength(WebTools, 0);

    while i <= Data.Count - 1 do
    begin
      CurrentTool := ReadNextWebTool(Data, i);
      Inc(i, EntryLength);
      if FileExists('WebTools\' + Name + '.png')
        and CurrentTool.Tag ... then
      begin
        SetLength(WebTools, Length(WebTools) + 1);
        WebTools[High(WebTools)] := CurrentTool;
      end;
    end;
  finally
    Data.Free;
  end;
[...]

Dann hast du eine Funktion, die dir den nächsten Eintrag liest und kannst mit dessen Daten zur Prüfung arbeiten. Daher kannst du das Array dann nur erweitern, wenn du den Eintrag möchtest und musst nichts wieder löschen.
Und du brauchst das leidige with nicht.

[Uwe Raabe]

Die ReadNextWebTool Implementierung sieht aber nicht wirklich gesund aus...

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1545614)

Die ReadNextWebTool Implementierung sieht aber nicht wirklich gesund aus...

Ups, ja, ich habe den Parameternamen nicht angepasst. Danke!

[Uwe Raabe]

Na ja, auch der Index I ist dort nicht wirklich bekannt.

[jaenicke]

Ja gut, wenn es sein muss... :P
So sollte es besser passen.

[Alucard]

Zitat:

Zitat von Uwe Raabe (Beitrag 1545614)

Die ReadNextWebTool Implementierung sieht aber nicht wirklich gesund aus...

Das hatte ich mir zur ersten Version der Antwort auch gedacht, aber wenigstens war das ein offensichtlicher Schnitzer und nicht einer von den fiesen versteckten, die einen Ewigkeiten aufhalten :lol:


Was anderes: Sowohl Jaenicke als auch Uwe (iwo bei Stackoverflow...) haben ihre Abneigung gegen das

Code:

With {...} do {...};

geäußert - Warum? Ich finde, das schafft echt Übersicht im Code. Tatsächlich baue ich das sogar nachträglich noch in alte Projekte ein, wenn ich ne passende Stelle sehe :|

[jaenicke]

Zitat:

Zitat von Alucard (Beitrag 1545632)

Was anderes: Sowohl Jaenicke als auch Uwe (iwo bei Stackoverflow...) haben ihre Abneigung gegen das

Code:

With {...} do {...};

geäußert - Warum? Ich finde, das schafft echt Übersicht im Code. Tatsächlich baue ich das sogar nachträglich noch in alte Projekte ein, wenn ich ne passende Stelle sehe :|

• Du kannst an der Stelle den Debugger nicht gut verwenden. Der weiß nicht, was wohin gehört und kann daher keine Tooltips mit dem Wert anzeigen. Und du kannst einen Wert auch nicht einfach mit Strg + F7 auswerten, sondern musst immer den Ausdruck aus with dazu kopieren.
• Bei einem Upgrade auf eine neue Delphiversion oder auf neue Versionen externer Komponenten können sich schwer zu findende Fehler einschleichen.
  Beispiel: TRect hat in XE2 Width und Height bekommen. Wenn irgendwo ein with auf ein TRect verwendet wurde, was z.B. bei den VirtualTrees der Fall war, gab es im besten Fall einen Fehler beim Kompilieren, aber es gab auch Fälle, in denen plötzlich das TRect geändert wurde statt des Formulars oder der Komponente, die eigentlich gemeint war. Das war dann bei komplexeren Projekten auf den ersten Blick gar nicht zu sehen und führte teilweise zu längerer Fehlersuche.
• Man sieht nicht auf den ersten Blick, welcher Identifier zu dem Element in with gehört und welcher eigenständig ist, was die Lesbarkeit erschwert. Wenn du selbst in einem Jahr auf den Quelltext schaust oder gar jemand anderes, braucht das Verständnis des Quelltextes entsprechend länger.
• Du kannst Teile des Quelltextes nicht einfach kopieren oder überarbeiten, weil du auf das with Rücksicht nehmen muss, was die Wartbarkeit reduziert.
• Der LSP und damit die Codevervollständigung funktionieren damit schlechter. Kreuzbeziehungen und with sind da sehr schlecht.

Tatsächlich kenne ich Hooks in Quelltextrepositories, die ein Einchecken verhindern, wenn darin ein with enthalten ist.

[himitsu]

Abgesehn davon: relative Pfade