[Package] Laz_BCP47

[wp_xyz]

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.

Hier ist die Combobox aber horizontal nicht mehr frei beweglich, weil sie am rechten Ende festgezurrt ist.

Anchoring und Autosizing sind sehr mächtige Tools, allerdings muss man auf Überraschungen gefasst sein, die sich einem nicht immer erschließen. Was habe ich am Anfang geflucht, weil Controls nicht das taten was ich wollte. Gefährlich sind auch rekursive Schleifen, wenn auf ein Control widersprüchliche Bedingungen eingestellt werden sollen. Früher bedankte sich die IDE dafür mit einem Absturz - ist jetzt nicht mehr der Fall, aber dieser fall ist trotzdem sehr lästig. Um das zu vermeiden, versuche ich von links nach rechts und von oben nach unten zu verankern; aber wenn man in der Mitte ein Teil hat, das sich wie alClient verhalten soll, dann muss man auch von unten nach oben laufen, und da muss man vorsichtig sein.

Übrigens: wenn Controls ein Align <> alNone haben, bleibt der Anker-Editor wirkungslos.

[hubblec4]

Hier ist die Combobox aber horizontal nicht mehr frei beweglich, weil sie am rechten Ende festgezurrt ist.

OK. das ist gut zu wissen, und ich kann völlig nachvollziehen warum man da anfangs auch etwas gefrustet sein kann.
Es ist nicht gleich alles super verständlich, dennoch bin ich völlig begeistert, wie es arbeitet und funktioniert.

Danke dir für deine Hilfe und die vielen Tipps.
Ich habe weiter einige Fehler gefixt und auf GitLab alles veröffentlicht.
Werde die Tage da sicher noch einiges machen.

[hubblec4]

Nun ist das Projekt etwas ausgereift und ich habe auch bisschen Text im GitLab repo angefertigt.

Habe einige Sachen noch angepasst und nochmal vielen Dank für deine Hilfe wp_xyz.

[hubblec4]

Ich habe da doch noch mal eine Frage.

Wollte das Package nun in einem Projekt nutzen wo ich aber Lazarus 2.02 verwende (Lazarus updaten ist da nicht möglich),
Dort kommt nun eine Fehlermeldung für das Variants array was in der Variants.inc definiert ist.
" Expected "nil" but "(" found "

Das Field "Prefixes" ist als TStringArray definiert und es scheint wohl nicht möglich zu sein dieses Array "vorzudefinieren".

In meiner aktuellen Lazarus version 2.12 ist dies kein Problem.
Sieht wohl so aus als gabs da ein Update wodurch das nun doch geht?

Gibt es eine Möglichkeit dieses Array auch in Lazarus 2.02 vorzudefinieren?
Oder muss ich das für die Lazarus 2.02 version anders angehen?

[wp_xyz]

Das kann ich jetzt nicht testen, weil ich keinen Lazarus mit FPC 3.0 mehr auf der Platte haben. Ich vermute, es handelt sich um die Elemente "prefixes" des TVariant-Records, die du mit FPC 3.0 nicht mehr direkt in der Record-Deklaration belegen kannst.

Naheliegend wäre, die TVariant.Prefixes als String zu reklarieren, statt als TStringArray, und die Elemente durch ein Trennzeichen zu trennen, z.B. bei {017} wäre dann die Deklaration

Code: Alles auswählen

{017} (Code:'baku1926';	Deprecated:False;	Name:'Unified Turkic Latin Alphabet (Historical)';	Prefixes:('az,ba,crh,kk,krc,ky,sah,tk,tt,uz')),

Als Folge müsstest du natürlich dann zur Laufzeit jedesmal den String in die Elemente aufspalten (über string.Split(',') oder eine temp-StringList mit CommaText oder DelimitedText). Falls sich das in der Performance bemerkbar machen sollte, würde ich dem Record doch noch ein StringArray spendieren, das du in der Initalization der Unit mit den Elementen der o.g. Prefixes füllst.

Das sind die Freuden des Komponenten-Schreibers, wenn er mehrere Versionen unterstützen will/muss.

[hubblec4]

Danke. und ich hatte es mir auch genauso überlegt wie du schreibst.
war mir aber nicht sicher ob das "guter" Stil ist.

Dann würde ich das ganze mit einer Direktive machen
also so in der Art {$ifdef FPC.300}

Wie sieht der Switch für FPC aus, oder wo finde ich diese?

EDIT: OK, denke habs gefunden.
Wäre jetzt nur noch interessant zu wissen ab welcher FPC version das mit dem TStringArray funktioniert.

[wp_xyz]

Da habe ich mich getäuscht, du brauchst FPC 3.2.0+, die 3.0.x-Versionen können mit dem initialisierten StringArray noch nicht umgehen. Das ist dokumentiert (https://wiki.freepascal.org/FPC_New_Fea ... ialization), aber ich habe es auch ausprobiert.

Die Direktive ist

Code: Alles auswählen

{$IF FPC_FullVersion = xyyzz}... {$IFEND}

wobei x für die Haupt-Version, yy und zz für die Unterversionen stehen. Bei FPC 3.2.0 wäre das "30200". Statt = kann auch <, >,>= oder <= verwendet werden.

Analog gibt es auch eine Direktive für die Lazarus-Versionen, die allerdings noch eine "Patch-Versions"-Nummer mit in der Zahl enthält, also Laz_FullVersion = xyyzzpp bzw. LCL_FullVersion = xyyzzpp, z. 2030000 für Version 2.3.0. Im Unterschied zu FPC muss man eine Unit mit einbinden, LazVersion bzw. LCLVersion.

Gut Stil hin oder her, bei einer über 100 Zeilen langen Deklaration würde ich mir 2x überlegen, ob ich da wirklich mit Ungetümen wie folgt herumhantieren will:

Code: Alles auswählen

array[0..105] of TVariant = (
{000} (Code:'1606nict';	Deprecated:False; Name:'Late Middle French (to 1606)'; {$IF FPC_FullVersion >= 30200}Prefixes:(['fm']){$ELSE}Prefixes:('frm'){$IFEND} ),
{001} (Code:'1694acad'; Deprecated:False; Name:'Early Modern French'; {$IF FPC_FullVersion >= 30200}Prefixes:(['fr']){$ELSE}Prefixes:('fr'){$IFEND}),
  ...
  

[hubblec4]

Supi, das hilft mir weiter. Danke.

[hubblec4]

Gut Stil hin oder her, bei einer über 100 Zeilen langen Deklaration würde ich mir 2x überlegen, ob ich da wirklich mit Ungetümen wie folgt herumhantieren will:

Code: Alles auswählen

array[0..105] of TVariant = (
{000} (Code:'1606nict';	Deprecated:False; Name:'Late Middle French (to 1606)'; {$IF FPC_FullVersion >= 30200}Prefixes:(['fm']){$ELSE}Prefixes:('frm'){$IFEND} ),
{001} (Code:'1694acad'; Deprecated:False; Name:'Early Modern French'; {$IF FPC_FullVersion >= 30200}Prefixes:(['fr']){$ELSE}Prefixes:('fr'){$IFEND}),
  ...
  

Also dies wäre eine Möglichkeit. Da diese .inc Datei automatisch erstellt wird, wäre das auch kein großer Aufwand.
Allerdings sieht es dann im Code auch nicht sonderlich toll aus.

Eine andere Möglichlkeit wäre es, das man 2 Variant.inc Datein hat und diese dann nur dementsprechend nutzt.

Code: Alles auswählen

VariantArray          : {$IF FPC_FullVersion >= 30200} {$i variants.inc} {$ELSE} {$i variants_old.inc} {$IFEND};

Was die Performance angeht, das sollte eigentlich fast egal sein. Dieser Subtag wird eher sehr selten verwendet, Und selbst wenn, ruft man ja nicht tausende mal die Validierung auf(dort wird dieses TStringArray verwendet).

Ich könnte sogar immer gleich einen String für die Prefixes verwenden und wenn benötigt eben ein StringArray draus machen.
Ich vermute mal das sowas recht schnell von statten geht und keine große CPU Last auslösen wird.

Was verbraucht denn weniger Speicher: Der String typ oder der TStringArray typ?

[wp_xyz]

Eine andere Möglichlkeit wäre es, das man 2 Variant.inc Datein hat und diese dann nur dementsprechend nutzt.

Code: Alles auswählen

VariantArray          : {$IF FPC_FullVersion >= 30200} {$i variants.inc} {$ELSE} {$i variants_old.inc} {$IFEND};

Ja, ist übersichtlicher, aber ich meine, auch fehleranfälliger, denn du musst nun zwei Dateien synchron halten (falls es mal etwas zu ändern gibt). Das trifft zwar auch auf meine Variante zu, aber da stehen die zu ändernden Stellen unmittelbar beisammen in derselben Datei.

Ich könnte sogar immer gleich einen String für die Prefixes verwenden und wenn benötigt eben ein StringArray draus machen.
Ich vermute mal das sowas recht schnell von statten geht und keine große CPU Last auslösen wird.

Genau, da hatte ich im Sinn.

Was verbraucht denn weniger Speicher: Der String typ oder der TStringArray typ?

Das wird sich nicht viel nehmen, aber jedes StringArray wird um ein paar Byte größer sein (zusätzlicher Pointer und Verwaltungsinformation für die nun einzelnen Strings), für das Array mit 100 Einträgen also vielleicht weniger als 1 KB.

[hubblec4]

OK. Soweit so gut.
Bleibt nur noch mich zu entscheiden was ich da nun mache

[hubblec4]

Ich habe mich für die Änderung des Types der Variant Prefixes entschieden.
Das spart sogar 2 Zeilen Code und an der Performance hat sich auch nichts geändert.

Die Änderungen sind im GitLab repo hochgeladen und ich habe den 1.Post etwas angepasst(altes Beispiel Programm entfernt).