Laz IDE, SVN und AnchorDockingDsng 1.0
Laz IDE, SVN und AnchorDockingDsng 1.0
Hi,
wir haben ein seltsames Verhalten:
Die Projekt Sourcen liegen auf einem SVN (lokaler Server).
Änderungen werden von meinem Kollegen und mir dorthin übertragen.
Mein Kollege hat KEIN Docking in der IDE!
Ich habe AnchorDockingDsgn 1.0 Edit on: und DockedFormEditor Edit off installiert.
folgendes Spiel:
1) ich spiele meine Projekt Files zum SVN
2) Kollege holt die Sourcen vom SVN, öffnet, ändert irgend etwas und spielt die Änderungen auf den SVN
3) Ich hole mir die geänderten Sourcen vom SVN und bekomme sämliche .lfm erneut geladen, obwohl mein Kollege da nichts dran geändert hat!
Jetzt kommt noch hinzu, dass mein Kollege eine 120% Displayeinstellung hat, ich nicht.
LCL Skalierung und DPI Anpassung ist im Projekt auf "ON"
Das Ergebnis:
Die Komponenten in den Fenstern (.lfm) sind "verstellt". Also die Anordnungen sind verschoben.
Ein Treeview z.B. geht um einiges über den rechten Fensterrand hinaus.
Kann dies mit dem Anchordocking zusammenhängen?
Eine echt blöde Sache...
wir haben ein seltsames Verhalten:
Die Projekt Sourcen liegen auf einem SVN (lokaler Server).
Änderungen werden von meinem Kollegen und mir dorthin übertragen.
Mein Kollege hat KEIN Docking in der IDE!
Ich habe AnchorDockingDsgn 1.0 Edit on: und DockedFormEditor Edit off installiert.
folgendes Spiel:
1) ich spiele meine Projekt Files zum SVN
2) Kollege holt die Sourcen vom SVN, öffnet, ändert irgend etwas und spielt die Änderungen auf den SVN
3) Ich hole mir die geänderten Sourcen vom SVN und bekomme sämliche .lfm erneut geladen, obwohl mein Kollege da nichts dran geändert hat!
Jetzt kommt noch hinzu, dass mein Kollege eine 120% Displayeinstellung hat, ich nicht.
LCL Skalierung und DPI Anpassung ist im Projekt auf "ON"
Das Ergebnis:
Die Komponenten in den Fenstern (.lfm) sind "verstellt". Also die Anordnungen sind verschoben.
Ein Treeview z.B. geht um einiges über den rechten Fensterrand hinaus.
Kann dies mit dem Anchordocking zusammenhängen?
Eine echt blöde Sache...
Zuletzt geändert von six1 am So 23. Jan 2022, 01:06, insgesamt 1-mal geändert.
Gruß, Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6198
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Schon einmal ein diff der lfm gemacht ? Damit man sieht was sich ändert. Damit müsste klar sein, welcher Lazarus welche Änderungen macht.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Welche Lazarus/FPC-Version haben die beiden Rechner?
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Beide Rechner haben Laz 2-3 FPC 3-2-2
Einen diff habe ich noch nicht gemacht (mach ich nächste Woche). Ist aber schon seltsam, dass alle .lfm des Projektes betroffen sind und keine .pas
Ich denke durch das Anordnen der Form im docked Form-Window gibt es da "Kuddelmuddel"
Einen diff habe ich noch nicht gemacht (mach ich nächste Woche). Ist aber schon seltsam, dass alle .lfm des Projektes betroffen sind und keine .pas
Ich denke durch das Anordnen der Form im docked Form-Window gibt es da "Kuddelmuddel"
Gruß, Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6198
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Deswegen das diff.
Entweder beim Lazarus deines Kollegen muss was wegen der 120% geändert werden oder fügt der was hinzu, das dein Lazarus versucht auszugleichen/adaptieren.
Im schlechtesten Fall sieht man beim Checkin vom Kollegen Änderung und bei dir
Anchordocking Design sollte ja nur den Editor zusammenkleben, das grafische Editieren der Form sollte ja gleich bleiben. Das wird ja erst mit dem Paket DockedFormEditor in das AnchordockingDsg eingebunden.
Wenn du den DockedFormEditor installiert hast, so kannst du es mal ohne probieren. Lazarus selbst bleibt dann zusammengeklebt, nur das Editierfenster der Form muss man sich mit F12 oder anders nach vorne holen.
Entweder beim Lazarus deines Kollegen muss was wegen der 120% geändert werden oder fügt der was hinzu, das dein Lazarus versucht auszugleichen/adaptieren.
Im schlechtesten Fall sieht man beim Checkin vom Kollegen Änderung und bei dir
Anchordocking Design sollte ja nur den Editor zusammenkleben, das grafische Editieren der Form sollte ja gleich bleiben. Das wird ja erst mit dem Paket DockedFormEditor in das AnchordockingDsg eingebunden.
Wenn du den DockedFormEditor installiert hast, so kannst du es mal ohne probieren. Lazarus selbst bleibt dann zusammengeklebt, nur das Editierfenster der Form muss man sich mit F12 oder anders nach vorne holen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
ja, du hast absolut Recht! Ich habe DockedFormEditor installiert.
Das ist der erste "Docked Form Zusammenbau", mit welchem ich ganz gut arbeiten kann und eben nicht ständig nach der Form suchen muss
Also ohne DockedFormEditor ist no go...
Ich schau mir das am Montag mal genauer an; Danke für die Idee!
Das ist der erste "Docked Form Zusammenbau", mit welchem ich ganz gut arbeiten kann und eben nicht ständig nach der Form suchen muss
Also ohne DockedFormEditor ist no go...
Ich schau mir das am Montag mal genauer an; Danke für die Idee!
Gruß, Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6198
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Das mit dem NoGo hängt davon ab, wie ich arbeite. Auf einem 2 Monitorsystem ist es gar nicht so schlecht, die Forms am 2ten Monitor zu haben.
Der DockedFormEditor macht ja virtuelle Positionen um das Form in Position zu halten. Ich würde auf die DPI Skalierung tippen. Kontrolliere auch ob ihr gleiche DPI Einstellungen habt.
Der DockedFormEditor macht ja virtuelle Positionen um das Form in Position zu halten. Ich würde auf die DPI Skalierung tippen. Kontrolliere auch ob ihr gleiche DPI Einstellungen habt.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
tja, also ich habe so einen Monster LG curved mit 100%, mein Kollege FullHd 27" mit 120%... da geht es schon los...
Das sind nicht identische Systeme.
Eine Lösung habe ich, zumindest für mich: Ich bin Mitte des Jahres fertig und muss nicht mehr arbeiten. Dann gebe ich meinem Kollegen einfach meinen Monitor Aber eigentlich habe ich vor, dass Problem vorher zu lösen.
Das sind nicht identische Systeme.
Eine Lösung habe ich, zumindest für mich: Ich bin Mitte des Jahres fertig und muss nicht mehr arbeiten. Dann gebe ich meinem Kollegen einfach meinen Monitor Aber eigentlich habe ich vor, dass Problem vorher zu lösen.
Gruß, Michael
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Ich glaube nicht, dass Anchordocking etwas mit der Änderung der lfm-Dateien zu tun hat, sondern das LCL-Scaling.
Ich habe im folgenden versucht, das nachzustellen. Mein PC hat Win 11/96ppi, darauf läuft eine VM mit Win 7/144ppi. Keine Machine verwendet AnchorDocking. Ich habe eines meiner Projekte von sourceforge (SVN) auf beiden Systemen ausgecheckt und einige Experimente gemacht.
Was letztendlich bei dir das falsche Skalieren des Treeview verursacht kann ich nicht sagen.
Ich habe im folgenden versucht, das nachzustellen. Mein PC hat Win 11/96ppi, darauf läuft eine VM mit Win 7/144ppi. Keine Machine verwendet AnchorDocking. Ich habe eines meiner Projekte von sourceforge (SVN) auf beiden Systemen ausgecheckt und einige Experimente gemacht.
- Projekt auf dem 144ppi-Sytem geladen: Da ich denselben Monitor für beide System benutze, erscheint alles viel größer, aber das ist ja gerade der Zweck der LCL-Skalierung. Die Proportionen der Controls untereinander erscheinen so wie gewohnt. (Screenshot "ekst-144ppi")
- Projekt auf dem 144ppi-System übersetzt, gestartet, ansonsten keine Änderungen --> das TortoiseSVN zeigt keine Änderungen an.
- Auf dem 144ppi-System im Code des Mainform eine Leerzeile gelöscht, gespeichert, übersetzt, gestartet --> das TortoiseSVN markiert owohl pas-Datei (das war zu erwarten) als auch lfm-Datei als geändert. In der lfm-Datei sind Koordinaten, Größen, Spacings usw. neu geschrieben, und es wurde die Zeile mit DesigntimePPI = 144 eingefügt. Klar - der ursprüngliche Code war mit 96ppi im Repository, das 144-ppi-System musste umskalieren.
- Nun das Projekt committet. Auf den Win 11-Rechner mit 96ppi gewechselt, svn update. Wenn ich die lfm-Datei mit einem Editor öffne, sehe ich das eingefügte DesigntimePPI =144. Nun das Projekt in Laz geöffnet - das Formular erscheint in der für diesen Rechner gewohnten Größe. Alles wurde korrekt skaliert (bis auf die Achsentitel im Chart, aber das ist eine mir bekannte Baustelle). - Siehe Screenshot "ekst-96ppi"
Was letztendlich bei dir das falsche Skalieren des Treeview verursacht kann ich nicht sagen.
- Dateianhänge
-
- ekst-96ppi.png (30.89 KiB) 2063 mal betrachtet
-
- ekst-144ppi.png (60.46 KiB) 2063 mal betrachtet
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Wahnsinn wp_xyz, hast du ja gleich alles durchgetestet! Was soll ich jetzt am Monatg noch machen?
Danke!
Also die DPI sind ja an einem Monitor Hardwareseitig festgelegt, anders als die Anzeigeneinstellung/Skalierung, welche jeder Anwender frei wählen kann.
Es wird wohl an der Skalierung liegen.
Ich werde am Montag einen Beschaffungsantrag schreiben:
Das geht durch; bestimmt!
Danke!
Also die DPI sind ja an einem Monitor Hardwareseitig festgelegt, anders als die Anzeigeneinstellung/Skalierung, welche jeder Anwender frei wählen kann.
Es wird wohl an der Skalierung liegen.
Ich werde am Montag einen Beschaffungsantrag schreiben:
Code: Alles auswählen
Lieber Chef,
wp_xyz hat festgestellt, dass wir die Monitore der Entwickler durch einheitliche 4k Modelle in mind. 38" ersetzen müssen,
da wir eine einheitliche DPI und Skalierungseinstellung benötigen.
Gruß, Michael
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Ich glaube für den DockedFormEditor gibt es dazu schon einen Bugreport, zumindest hat Mathias mir mal geschrieben, daß die .lfm immer beim öffnen und schließen eines Formulars gespeichert wird, selbst wenn daran nichts verändert wurde. Damals konnte ich dies nicht nachstellen, oben genanntes gibt aber einen neuen Ansatz. Danke dafür. Wird leider eine Weile dauern, bis ich mich dem widmen kann. Bis dahin sind Patches willkommen
Code: Alles auswählen
type
TLiveSelection = (lsMoney, lsChilds, lsTime);
TLive = Array[0..1] of TLiveSelection;
-
- Beiträge: 572
- Registriert: Mi 25. Mär 2009, 21:12
- OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
- CPU-Target: mostly 32 bit
Re: Laz IDE, SVN und AnchorDockingDsng 1.0
Ich kann jetzt nicht sagen ob das relevant ist, aber in einer IDE ohne Anker gibt es die Option "Open Designer on open unit" (Tools > Options > Environment > Form Editor).
Wenn das nicht gesetzt ist, wird die Form gar nicht erst geöffnet, und dann auch nicht verändert wenn man die Unit speichert.
Keine Ahnung ob das mit dem "embedded" Form Editor eine Wirkung hat. (Weil so lange Du den Designer-Tab unter dem Editor nicht aktivierst, muss die Form ja nicht geladen werden.
Dein Kollege könnte die Option auch "setzen" (abschalten). Wenn er ja in den meisten Fällen eh nix an der Form ändert, dann muss er die Form wahrscheinlich auch nicht laden.
Ist natürlich keine endgültige Lösung, denn sobald jemand die Form doch öffnen muss, ist das Problem wieder da. Aber ggf reduziert es ja die Häufigkeit des Problems. Zumindest bis es eine echte Lösung gibt.
Wenn das nicht gesetzt ist, wird die Form gar nicht erst geöffnet, und dann auch nicht verändert wenn man die Unit speichert.
Keine Ahnung ob das mit dem "embedded" Form Editor eine Wirkung hat. (Weil so lange Du den Designer-Tab unter dem Editor nicht aktivierst, muss die Form ja nicht geladen werden.
Dein Kollege könnte die Option auch "setzen" (abschalten). Wenn er ja in den meisten Fällen eh nix an der Form ändert, dann muss er die Form wahrscheinlich auch nicht laden.
Ist natürlich keine endgültige Lösung, denn sobald jemand die Form doch öffnen muss, ist das Problem wieder da. Aber ggf reduziert es ja die Häufigkeit des Problems. Zumindest bis es eine echte Lösung gibt.