[Package] Laz_BCP47

Rund um die LCL und andere Komponenten
hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

[Package] Laz_BCP47

Beitrag von hubblec4 »

Hallo Lazarusgemeinde

Ich habe versucht ein Package zu basteln für die BCP47.

Den Quellcode habe ich öffentlich gemacht auf GitLab, so dass er für alle zugänglich ist.

Im Laz_BCP47 Package gibt es eine unit die für die BCP47-logik und deren Syntax zuständig ist.
Weiterhin habe ich eine Form eingebaut mit der man die Sprach-Tags bearbeiten kann.

Somit kann man in einem Projekt schnell die BCP47 einbinden und diese den Benutzern zur Verfügung stellen.

Ein Beispielprogramm befindet sich nun ebenfalls im Repository.
Zuletzt geändert von hubblec4 am Fr 29. Okt 2021, 01:21, insgesamt 3-mal geändert.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: [Package] Laz_BCP47

Beitrag von wp_xyz »

Zunächst: Ich habe keine Ahnung, was BCP47 ist und wofür ich das brauchen könnte. Dennoch: Wer's braucht, für den ist es sicher sinnvoll, da sehr viel Arbeit drinsteckt.

Der erste Eindruck: Ich habe das Package geladen und testweise übersetzt. --> ok. Die Hauptunit scheint BCP_47.pas zu sein. Die Hauptarbeit scheint gewesen zu sein, diese riesigen Include-Files zu erstellen. Das allein gibt der Unit schon einen gewissen Wert.

Aber warum braucht das Package dann die LCL? OK - da ist das BCP_47Form. Ich habe das mal geöffnet - oh: das Formular klebt an der rechten Seite des Bildschirms. Nicht jeder hat zwei Monitore vor sich... Ziehe das Formular vor dem Speichern an eine "ein-Monitor-freundliche" Position, damit auch User etwas davon haben, die ihren Schreibtisch nie aufräumen, so dass ein zweiter Monitor drauf passen würde... Das Formular ist mit dem Anchor-Editor designt - schön, allerdings meine ich, dass einige Controls noch floaten, so dass es spätestens unter Linux Probleme geben könnte, da müsstest du nochmals drüberschauen.

Am Package fällt mir auf, dass es für Designtime und Runtime ist. Warum Designtime? Das Package enthält keine registrierte Komponente, keinen Property- bzw. Komponenteneditor, keine IDE-Erweiterung. So ein Package zu "installieren" wäre nur Ballast. Mache es zu "Runtime" oder "Runtime only" (unter "IDE-Integration").

Ich frage mich, muss das Formular im Package sein? Wenn die Unit BCP_47 nur vom GUI-Programmen sinnvoll genutzt werden kann, dann sicher ja. Aber Leute, die BCP_47 in einem Konsolen-Programm nutzen wollen, haben nun plätzlich die ganze LCL im Gepäck... Da wäre es vielleicht sinnvoller zwei Packages zu machen, das erste nur mit BCP_47 ohne LCL-Abhängigkeit, und ein zweites, "Laz_BCP47_GUI" mit dem Formular; das hätte als Abhängikeit LCL und Laz_BCP47.

Evtl. wäre es auch sinnvoll, eine nicht-visuelle Komponente (TBCP47 = class(TComponent)) zu machen, die der User auf sein Projekt-Formular klicken kann, und die intern das Formular erzeugt und aufruft und dessen Properties als eigene Properties weitergibt. Dann müsste sich der User nicht mehr um die Interna des Formulars kümmern. Und du könntest du die ganzen Stringlisten auch direkt im Objekt-Inspektor anzeigen. Oder du könntest einen Komponenten Editor for TBCP47 schreiben, so dass sich mit einem Doppelklick auf derKomponente das Formular öffnet - das wäre dann die hohe Schule der Komponentenentwicklung...

Das Beispiel-Projekt gehört auf keinen Fall mit ins Package. Denn der User hat ja sein eigenes Projekt, auf dem er das Package verwenden möchte.

Auch in dem Beispielprojekt befindet sich das Hauptformular weit vom rechten Rand meines Monitors entfernt...

Dann gibt es noch ein Speicherleck, denn du erzeugst das FormBCP47 mit Owner nil (FormBCP47:=TFormBCP47.Create(nil); in Button1Click). Das heißt, du selbst bist für das Aufräumen des Formulars verantwortlich, tust das aber nicht.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

Erstmal vielen Dank fürs drüberschauen und die vielen Hinweise.
wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Zunächst: Ich habe keine Ahnung, was BCP47 ist und wofür ich das brauchen könnte. Dennoch: Wer's braucht, für den ist es sicher sinnvoll, da sehr viel Arbeit drinsteckt.
Eine Dokumentation kommt dann später noch. Leider ist meine Zeit sehr begrenzt.
Grob gesagt kann man damit einen SprachTag erstellen/bearbeiten, so wie es die BCP47 verlangt.
Das ganze ist gut für Programme die mit Sprachen arbeiten, also ein Video Editor zum Beispiel.

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Der erste Eindruck: Ich habe das Package geladen und testweise übersetzt. --> ok. Die Hauptunit scheint BCP_47.pas zu sein. Die Hauptarbeit scheint gewesen zu sein, diese riesigen Include-Files zu erstellen. Das allein gibt der Unit schon einen gewissen Wert.
Das erstellen der Listen für die SubTags war in der Tat ein wenig Arbeit, aber eigentlich war das zusammen suchen der richtigen Informationen schwieriger.
Dazu hatte ich jede menge email Verkehr mit Moritz Bunkus, dem Author von MKVToolNix.
Dann konnte ich ein paar Parser schreiben und nun werden mir diese Listen(include files) automatisch erstellt.

Schön zu lesen das dies eine gute Arbeit war. Danke.

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Aber warum braucht das Package dann die LCL? OK - da ist das BCP_47Form. Ich habe das mal geöffnet - oh: das Formular klebt an der rechten Seite des Bildschirms. Nicht jeder hat zwei Monitore vor sich... Ziehe das Formular vor dem Speichern an eine "ein-Monitor-freundliche" Position, damit auch User etwas davon haben, die ihren Schreibtisch nie aufräumen, so dass ein zweiter Monitor drauf passen würde...
Ohje..du hast natürlich recht. Das hatte ich gar nicht bedacht.

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Das Formular ist mit dem Anchor-Editor designt - schön, allerdings meine ich, dass einige Controls noch floaten, so dass es spätestens unter Linux Probleme geben könnte, da müsstest du nochmals drüberschauen.
Also das war schon ne menge Arbeit und Hirnschmalz :-).
Hatte mit dem Anchor-Editor bisher nur ganz einfache Sachen gemacht. Aber nach einer Weile klappte es dann und ich bin stark beeindruckt wie das ganze funktioniert und anzuwenden ist.

Was meinst du mit "einige Controls noch floaten"?
Stimmt unter Linux habe ich es noch nicht getestet. Und leider verhalten sich dort die GUI-Elemente immer etwas anders als unter Windows.

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Am Package fällt mir auf, dass es für Designtime und Runtime ist. Warum Designtime? Das Package enthält keine registrierte Komponente, keinen Property- bzw. Komponenteneditor, keine IDE-Erweiterung. So ein Package zu "installieren" wäre nur Ballast. Mache es zu "Runtime" oder "Runtime only" (unter "IDE-Integration").
Erwischt...von sowas habe ich leider noch keine Ahnung. Jedoch verstehe ich worum es geht und werde das noch ändern. Oder fragen wenn ich nicht weiter komme.

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Ich frage mich, muss das Formular im Package sein? Wenn die Unit BCP_47 nur vom GUI-Programmen sinnvoll genutzt werden kann, dann sicher ja. Aber Leute, die BCP_47 in einem Konsolen-Programm nutzen wollen, haben nun plätzlich die ganze LCL im Gepäck... Da wäre es vielleicht sinnvoller zwei Packages zu machen, das erste nur mit BCP_47 ohne LCL-Abhängigkeit, und ein zweites, "Laz_BCP47_GUI" mit dem Formular; das hätte als Abhängikeit LCL und Laz_BCP47.
Mmhh, das klingt auch gut. Muss ich mal drüber nachdenken.
In der Tat könnte ein Konsolen-Programm nur die BCP_47 nutzen um SprachTags zu validieren und möglicherweise auch erstellen. Da wäre dann keine BCP47_Form nötig.

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Evtl. wäre es auch sinnvoll, eine nicht-visuelle Komponente (TBCP47 = class(TComponent)) zu machen, die der User auf sein Projekt-Formular klicken kann, und die intern das Formular erzeugt und aufruft und dessen Properties als eigene Properties weitergibt. Dann müsste sich der User nicht mehr um die Interna des Formulars kümmern. Und du könntest du die ganzen Stringlisten auch direkt im Objekt-Inspektor anzeigen. Oder du könntest einen Komponenten Editor for TBCP47 schreiben, so dass sich mit einem Doppelklick auf derKomponente das Formular öffnet - das wäre dann die hohe Schule der Komponentenentwicklung...
Das ist definitiv noch zu hoch für mich.
wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Das Beispiel-Projekt gehört auf keinen Fall mit ins Package. Denn der User hat ja sein eigenes Projekt, auf dem er das Package verwenden möchte.
OK. Stimmt.

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Auch in dem Beispielprojekt befindet sich das Hauptformular weit vom rechten Rand meines Monitors entfernt...
Oh man, ich Dussel... :-)

wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Dann gibt es noch ein Speicherleck, denn du erzeugst das FormBCP47 mit Owner nil (FormBCP47:=TFormBCP47.Create(nil); in Button1Click). Das heißt, du selbst bist für das Aufräumen des Formulars verantwortlich, tust das aber nicht.
Stimmt. Das Owner=(nil) war noch aus test-zwecken und ich habe es nicht zurückgesetzt.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: [Package] Laz_BCP47

Beitrag von wp_xyz »

hubblec4 hat geschrieben:
Fr 15. Okt 2021, 22:25
Was meinst du mit "einige Controls noch floaten"?
Du packst immer ein Label und eine Combobox in ein Panel und verankerst die Panel vertikal untereinander. Das sieht im aktuellen Layout gut aus, aber schon wenn der User die Schriftgröße nicht über deine Routine ChangeFontSize, sondern einfach über FormBCP47.Font.Size ändert, kann's eng werden. Um das zu verhindern, würde ich das AutoSize jedes Panels aktivieren - damit kannst du dir auch die ChangeFontSize-Prozedur sparen. Allerdings können unverankerte Controls dabei in der Regel nach links oben fliegen - das ist ein Heidenspaß die wieder auseinanderzusortieren... Bei dir sind die Labels in der x-Richtung frei, vertikal allerdings an die Mitte der entsprechenden Combobox verankert. Wenn Panel.AutoSize=true wird, fliegen die Labels daher nur an den linken Rand der Panels. Glück gehabt... Aber wenn du jetzt versuchst, die Labels wieder an Ort und Stelle zu verschieben, fangen plötzlich die Comboboxen an, mitzuwandern. Um das alles zu vermeiden, habe ich mir zur Regel gesetzt, die Controls in der Regel so zu verankern, dass man sie mit der Maus nicht mehr verschieben kann.

Als Beispiel nehme ich Pan_ScriptRegion:
- Panel AutoSize -> LblScript und LblRegion werden nach links geschoben.
- Klicke LblScript an und setze im Anker-Editor die linke Verankerung auf den parent des Label, Pan_ScriptRegion. Nun sitzt das Label fest und kann nicht mehr verschoben werden
- Dasselbe mit dem LblRegion
- Um den Abstand vom linken Rand einzustellen, könntest du bei beiden Labels 12 als BorderSpacing.Left eintragen. Oder du machst das gleich für das Panel, also Pan_ScriptRegion.BorderSpacing.Left = 12. Das kann man auch im Anker-Editor eintragen (linkes Edit-Feld in der Mitte); der Anker-Editor sollte bei solchen Arbeiten immer offen bleiben.
-----------
Ich habe noch einige Speicherlecks gesehen: du erzeugst im FormCreate diverse StringListen, sowie ein FLangBCP47-Objekt, die nirgendwo freigegeben werden. Dafür ist das OnDestroy-Ereignis des Formulars da.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

Einiges von deinen Vorschlägen und Fehler die du gefunden hast habe ich beseitigt. Auf GitLab ist der Code aktuallisiert und das BCP47Form Progg werde ich erneuern und/oder auch noch auf GitLab hochladen.

wp_xyz hat geschrieben:
Sa 16. Okt 2021, 00:25

Du packst immer ein Label und eine Combobox in ein Panel und verankerst die Panel vertikal untereinander.

......

Als Beispiel nehme ich Pan_ScriptRegion:
- Panel AutoSize -> LblScript und LblRegion werden nach links geschoben.
- Klicke LblScript an und setze im Anker-Editor die linke Verankerung auf den parent des Label, Pan_ScriptRegion. Nun sitzt das Label fest und kann nicht mehr verschoben werden
- Dasselbe mit dem LblRegion
- Um den Abstand vom linken Rand einzustellen, könntest du bei beiden Labels 12 als BorderSpacing.Left eintragen. Oder du machst das gleich für das Panel, also Pan_ScriptRegion.BorderSpacing.Left = 12. Das kann man auch im Anker-Editor eintragen (linkes Edit-Feld in der Mitte); der Anker-Editor sollte bei solchen Arbeiten immer offen bleiben.
Ich dachte mir schon das ich noch nicht alles optimal mit dem Anchor-Editor eingestellt habe.
Jedoch denke ich, ich komme um die eigene ChangeFontSize-Prozedur nicht drumherum. Da die Comboxen nicht mit einem Control verankert werden können was ausserhalb des jeweiligen Panels liegt.
Ich werde mir das aber noch mal anschauen und deinen Vorschlag berücksichtigen.

wp_xyz hat geschrieben:
Sa 16. Okt 2021, 00:25
Ich habe noch einige Speicherlecks gesehen: du erzeugst im FormCreate diverse StringListen, sowie ein FLangBCP47-Objekt, die nirgendwo freigegeben werden. Dafür ist das OnDestroy-Ereignis des Formulars da.
Stimmt. das sollte ich noch tun.
Zuletzt geändert von hubblec4 am Sa 16. Okt 2021, 01:38, insgesamt 2-mal geändert.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

Wenn ich das package aufsplitte, eins für die Form und eins für die BCP47-Logik,
dann hätte ich auch zweimal .po-Dateien, für jedes Package eben, richtig?

Und beide .po-Dateien müssten dann auch ins jewilige Projekt mit eingebunden werden(ins language Verzeichnis kopieren)?
Zuletzt geändert von hubblec4 am Sa 16. Okt 2021, 01:40, insgesamt 2-mal geändert.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

Ich habe im ersten Post den Anhang erneuert. Die Form des Hauptfensters sollte nun im ersten Monitor erscheinen.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: [Package] Laz_BCP47

Beitrag von wp_xyz »

hubblec4 hat geschrieben:
Fr 15. Okt 2021, 22:25
wp_xyz hat geschrieben:
Fr 15. Okt 2021, 20:09
Das Beispiel-Projekt gehört auf keinen Fall mit ins Package. Denn der User hat ja sein eigenes Projekt, auf dem er das Package verwenden möchte.
OK. Stimmt.
Das Beispiel-Projekt kannst du aber natürlich mit ins git-Repository aufnehmen. Beispielprojekte sind eine wichtige Hilfe, um neue Komponenten kennenzulernen.
hubblec4 hat geschrieben:
Sa 16. Okt 2021, 01:31
Wenn ich das package aufsplitte, eins für die Form und eins für die BCP47-Logik,
dann hätte ich auch zweimal .po-Dateien, für jedes Package eben, richtig?

Und beide .po-Dateien müssten dann auch ins jewilige Projekt mit eingebunden werden(ins language Verzeichnis kopieren)?
Zweimal ja.

-------------

Es gibt noch (mindestens) ein weiteres Speicherleck: Beispiel-Programm starten, "Only often used languages" markieren, Button "Set lang favs", Beenden --> Lange heaptrc-Liste mit Speicherlecks.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

wp_xyz hat geschrieben:
Sa 16. Okt 2021, 12:26
Das Beispiel-Projekt kannst du aber natürlich mit ins git-Repository aufnehmen. Beispielprojekte sind eine wichtige Hilfe, um neue Komponenten kennenzulernen.
Ahja, stimmt. So macht es auch sinn. Nicht ins package aber ins repository.
So wird es beim klonen oder runterladen des Quellcodes mitgeliefert.

wp_xyz hat geschrieben:
Sa 16. Okt 2021, 12:26
hubblec4 hat geschrieben:
Sa 16. Okt 2021, 01:31
....
Und beide .po-Dateien müssten dann auch ins jewilige Projekt mit eingebunden werden(ins language Verzeichnis kopieren)?
Zweimal ja.
Mmh...das ist dann wohl so, obwohl ich das jetzt schon bissl "nervig" empfinde.
Sagen wir mal man hat da 20 Packages eingebunden die mit eigenen .po-Dateien kommen.
Das wird doch ein riesen kuddel-muddel im Projekt, und vorallem für die Leute die später mal das Projekt unterstützen wollen und die Übersetzung machen wollen.
Da müssen dann einige Deutsche .po-Dateien übersetzt werden.
Und sagen wir mal das Projekt hat dann 20 Sprachen, da würden dann mal eben 400 .po-Dateien sein.

Ich vermute mal da gibt es keinen Weg am Ende im Projekt alle .po-Dateien in eine einzige zu vereinen, oder?

wp_xyz hat geschrieben:
Sa 16. Okt 2021, 12:26
Es gibt noch (mindestens) ein weiteres Speicherleck: Beispiel-Programm starten, "Only often used languages" markieren, Button "Set lang favs", Beenden --> Lange heaptrc-Liste mit Speicherlecks.
Stimmt, da sind noch class var's vom Typ TStringlist.
Gibt es eigentlich auch einen class destructor?

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: [Package] Laz_BCP47

Beitrag von wp_xyz »

hubblec4 hat geschrieben:
Sa 16. Okt 2021, 13:18
wp_xyz hat geschrieben:
Sa 16. Okt 2021, 12:26
hubblec4 hat geschrieben:
Sa 16. Okt 2021, 01:31
....
Und beide .po-Dateien müssten dann auch ins jewilige Projekt mit eingebunden werden(ins language Verzeichnis kopieren)?
Zweimal ja.
Mmh...das ist dann wohl so, obwohl ich das jetzt schon bissl "nervig" empfinde.
Sagen wir mal man hat da 20 Packages eingebunden die mit eigenen .po-Dateien kommen.
Das wird doch ein riesen kuddel-muddel im Projekt, und vorallem für die Leute die später mal das Projekt unterstützen wollen und die Übersetzung machen wollen.
Da müssen dann einige Deutsche .po-Dateien übersetzt werden.
Und sagen wir mal das Projekt hat dann 20 Sprachen, da würden dann mal eben 400 .po-Dateien sein.

Ich vermute mal da gibt es keinen Weg am Ende im Projekt alle .po-Dateien in eine einzige zu vereinen, oder?
Weiß nicht, so ein großes übersetztes Projekt habe ich noch nicht gemacht. Für dich speziell könntest du eine Übersetzungsdatei einsparen, indem du die übersetzten Strings des GUI-Package mit ins Basis-Package aufnimmst, etwa so wie es zur Zeit schon ist. Da die Stringresource-Unit aus dem GUI-Package erreichbar ist, kannst du auf diese strings zugreifen, auch wenn sie in dem anderen Package sind. Das Basis-Package wird natürlich um die paar KByte größer.
hubblec4 hat geschrieben:
Sa 16. Okt 2021, 13:18
wp_xyz hat geschrieben:
Sa 16. Okt 2021, 12:26
Es gibt noch (mindestens) ein weiteres Speicherleck: Beispiel-Programm starten, "Only often used languages" markieren, Button "Set lang favs", Beenden --> Lange heaptrc-Liste mit Speicherlecks.
Stimmt, da sind noch class var's vom Typ TStringlist.
Gibt es eigentlich auch einen class destructor?
Wieder keine Ahnung, Klassen-Methoden setze ich sehr selten ein. Generell habe ich ein Problem mit Konstruktionen wie deinem Parse() bzw. ParseIntern(), die eine TLanguageBCP47-Instanz erzeugen. Nichts im Namen weist darauf hin, dass hier noch die Result-Instanz aufgeräumt werden muss. Und wenn ich das Funktionsergebnis keiner Variablen zuweise, habe ich schon ein Speicherleck, das ich nicht mehr beheben kann. Allein der Sicherheit halber würde ich das zu einer Prozedur machen, der man eine von außen erzeugtes TLanguageBCP47-Objekt übergibt. Sind natürlich zwei Zeilen mehr zu schreiben...

Code: Alles auswählen

class procedure TLanguageBCP47.Parse(AResult: TLanguageBPC47; const LngTag: String);
Ich frage mich dann aber auch, warum das überhaupt eine Klassenprozedur sein muss und du die Ergebnisse nicht direkt in die aktuelle Instanz von TLanguageBCP47 (self) reinschreibst. Aber dazu kenne ich diese Klasse zu wenig.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

wp_xyz hat geschrieben:
Sa 16. Okt 2021, 15:10

Code: Alles auswählen

class procedure TLanguageBCP47.Parse(AResult: TLanguageBPC47; const LngTag: String);
Ich frage mich dann aber auch, warum das überhaupt eine Klassenprozedur sein muss und du die Ergebnisse nicht direkt in die aktuelle Instanz von TLanguageBCP47 (self) reinschreibst. Aber dazu kenne ich diese Klasse zu wenig.
Ich habe den Quellcode an vielen Stellen so übernommen wie er im c++ gecodet ist. MKVToolNix repo.
Und ich hatte da auch erst überlegt wieso er das so gemacht hat. Aber es macht schon Sinn.

Ich denke man könnte das auch nach deiner Überlegung umsetzen das eine Instanz von BCP47 an die Methode Parse() übergeben werden muss/kann.

In der aktuellen Instanz werden mehr oder weniger nur die jeweiligen Subtags entgegengenommen, was noch nicht den fertigen LanguageTag ausmacht.
Würde jetzt Parse() die internen Subtags überschreiben wäre das sehr doof. Da ist es wirklich besser eine neue Instanz liefert mir dann das Ergebnis ob die Subtags gültig sind, sowie den fertigen Sprach-Tag.

Desweiteren gibt es bei Parse() dann noch eine Validier Methode wo Präfixe von bestimmten Subtags(das sind auch Sprach-Tags) gegen den aktuellen SprachTag überprüft werden müssen.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: [Package] Laz_BCP47

Beitrag von wp_xyz »

Wiegesagt, ich kenne die internen Details und Vorgänge nicht, und wenn du meinst, dass es so wie du es machst besser ist, dann ist es schon so richtig.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

Ich bin gerade dabei das Anchoring zu verbessern so wie es Vorgeschlagen hattest.

Also die Panels auf Autosize:=true; setzen.
Ich setze das Borderspacing bei den Labels und nicht beim Panel.

Das funktioniert für das Panel Pan_ScriptRegion und auch für Pan_ExtLang sehr gut.

Allerdings komme ich beim Pan_Extensions nicht so recht weiter.
Da gibt es ja zusätzlich zur CoB_Extensions und das Edt_Extensions.

Ziel soll sein das die ComboBox nicht ihre Weite ändernt. Das Edit feld soll Breiter werden.
Aber momentan rutscht die ComboBox ganz nach links nach dem aktivieren der AtuoSize für das Panel.

Wenn ich nun die Rechte Verankerung bei der ComboBox setze lässt sie sich nach rechts verschieben.
Allerdings wird dann nicht das Edit Feld breiter wenn die Form breiter wird, sondern die ComboBox.

Was mache ich da nur falsch?

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: [Package] Laz_BCP47

Beitrag von wp_xyz »

Da lag ich mit meiner Anleitung nicht ganz richtig. Ich habe dir gesagt, du solltest den linken Rand des Labels mit dem linken Rand des Panels verankern, indem du Pan_Extensions als linken Sibling im Anker-Editor einträgst. Nur wird damit auch die Auto-Positionierung der anderen Controls im Panel aktiv - warum das so ist, weiß ich nicht. Jedenfalls schiebt sich die Combobox nach links, weil ihr linkes Ende frei ist. Ich mache das dann immer so, dass das linke Ende der Combobox mit dem rechten Ende des Labels verbunden wird (Combobox markieren, als linken Sibling das Label eintragen und den DRITTEN Button für die rechtsseitige Verankerung klicken. Wenn mehrere Componenten untereinander ausgerichtet werden sollen, nehme ich als Verankerungselement das Label mit dem längsten Text, an dem sich alle orientieren.

Nur funktioniert das bei dir nicht, weil alle comboboxen in eigenen Panels sitzen, und eine Verankerung über diese Hierarchiestufe ist nicht vorgesehen.

Aber wir können einen Schritt zurückgehen: Selektiere das Label Lbl_Extensions (wenn du im Formulardesigner nicht rankommst, selektiere es im Objekt-baum über dem Objektinspektor). Im Anker-Editor entfernst du dann die Verankerung des linken Randes mit dem Formula (Silbing auf nil setzen).Nun ist der linke Rand der Combobox wieder frei beweglich und du kannst ihn auf die gewünschte Position zurückschieben.

Die Label und Combobox haben also keine horizontale Verankerung an irgendwelche Controls (Sibling), bei beiden ist der linke Verankerungshaken gesetzt, der rechte aber nicht.

Die Verankerung von Edt_Extensions und SpB_ExtensionsAdd ist richtig.

hubblec4
Beiträge: 341
Registriert: Sa 25. Jan 2014, 17:50

Re: [Package] Laz_BCP47

Beitrag von hubblec4 »

Super vielen dank. Das entfernen des linken Siblings beim Lbl_Extensions hat geholfen.

Schon komisch das es bei der Variants ComboBox funktioniert. Da hat das Lbl_Variants den linken Sibling gesetzt -> Pan_Variants, und dennoch kann ich die ComboBox property Left ändern.

Und ja ich kann nicht einfach das längste Label nehmen um daran die ComboBoxen auszurichten da sie nicht auf einer Ebene liegen.

Ein wenig hat mich das auch gestört, aber mit den separaten Panels war es für mich leichter innerhalb dieser Panels die neuen Componenten zu erzeugen und automatisch ALLE darunter vorkommenden Componenten zuverschieben.
Das Panel größer/höher zu machen ist dabei eben ganz einfach, und alles rutscht weiter runter, oder wieder hoch.

Antworten