Package installieren bricht ab

[braunbär]

Hallo,

ich habe jetzt meine Komponenten so weit, dass sie zumindest fehlerfrei kompilieren (ein paar Features habe ich dazu provisorisch auskommentieren müssen), aber das Kompilieren der Lazarus IDE schlägt fehl:

Kompiliere Package CodeTools 1.0.1: Erfolg, Warnungen: 58, Hinweise: 1
...
...
Kompiliere Package InstantFPCLaz 1.0: Erfolg
Kompiliere Package DBFLaz 0.1.1: Erfolg
IDE erstellen: Exit code 2, Fehler: 2
Error: Duplicate resource: Type = 24, Name = 1, Lang ID = 0000
lazarus.pp(154,1) Error: Error while compiling resources -> Compile with -vd for more details. Check for duplicates.

Hilfe!!!!

[wp_xyz]

Duplicate resource heißt: Eine Resource-Datei wird mehrfach eingebunden ({$R...}), oder der Name einer Resource ist bereits in einem anderen Package verwendet. Letzteres kann man weitgehend verhindern, indem man dem Resourcenamen ein Kürzel als Kennung für das Package voranstellt. Genaueres kann ich ohne den Quelltext nicht sagen.

Teste das Laufzeitverhalten der Komponente(n) ausgiebig, bevor du sie in die IDE einbindest. Installiert sind sie ein Bestandteil von Lazarus, und jeder Absturz deiner Komponenten reißt Lazarus mit. Dazu musst du das Package nicht "installieren", sondern nur "kompilieren". Schreibe ein Testprogramm, in dem das Package als Anforderung aufgeführt wird, und erzeuge hier die Komponenten einfach zur Laufzeit.

[braunbär]

Lazarus scheint es offenbar nicht zu mögen, wenn in einem Package, das in die IDE kompiliert wird, Formulare verwendet werden, die via
{$R *.lfm}
initialisiert werden. Ich verwende eine Debugging Unit, die nichts als eine formularfüllende Listbox enthält, die ich bei Bedarf mit Ausgaben beschicke. Das ist für die Fehlersuche manchmal praktischer als Breakpoints zu setzen. Die Unit ist in alle anderen Units eingebunden, auch wenn ich dieses Debugging gerade nicht verwende.

Nachdem ich die lfm Datei rausgeworfen und das Formular manuell erzeugt habe, klappt es jetzt.

[wp_xyz]

Irgendwas machst du da falsch. Hab' ein passendes Beispiel dafür gefunden: Schau dir das Package lazdbexport an (im Ordnder components/dbexport). Das ist ein Design/Runtime-Package, bei dem drei lfm-Dateien im Package vorhanden sind, und bei dem es keine Resourcen-Probleme gibt. Schau dir das mal an, vielleicht findest du den Fehler. Ich könnte mir vorstellen, dass du in der Registrierungs-Unit die lfm-Dateien nochmals aufgeführt hast - das ist falsch, das [$R *.lfm} darf nur in der Unit stehen, die zur lfm-Datei gehört (so wie bei einem "richtigen" Programm auch).

[braunbär]

Hmmm...

Dann verstehe ich es nicht ganz. Aber es war in dem Fall kein Problem, die lfm Datei zu entsorgen, die Form hat ja nur eine einzige Komponente, die kann ich genauso gut manuell beim Create der Form erzeugen. Ich habe jetzt noch einmal geschaut, {$R *.lfm} kommt sonst in dem Package nirgends vor.

Es ist gut, zu wissen, dass es (irgendwie) doch auch mit lfm-Files geht, aber mit der Frage werde ich mich erst dann wieder beschäftigen, wenn ich es brauche. Mit dem kompletten Entfernen der Resourcendatei sollte das Problem jedenfalls "radikal" gelöst sein. Im Moment habe ich noch genügend andere akute Baustellen

Momentan überlege ich gerade, wie ich das Delphi TTextformat in einem Grid am besten in Lazarus so umsetze, dass ich es als property in die published section bekomme. Das Lazarus Gegenstück TTextStyle funktioniert da nicht, das ist kein Set, sondern ein record. Wahrscheinlich werde ich das inklusive neuem Aufzähltyp als Set nachbauen müssen und dann über einen Setter die Felder von einem private record vom Typ TTextStyle befüllen. Aber erst schau ich mir noch die Grid-implementierung von Lazarus genauer an, vielleicht komme ich dann noch auf eine bessere Lösung.

[wp_xyz]

Momentan überlege ich gerade, wie ich das Delphi TTextformat in einem Grid am besten in Lazarus so umsetze, dass ich es als property in die published section bekomme. Das Lazarus Gegenstück TTextStyle funktioniert da nicht, das ist kein Set, sondern ein record. Wahrscheinlich werde ich das inklusive neuem Aufzähltyp als Set nachbauen müssen und dann über einen Setter die Felder von einem private record vom Typ TTextStyle befüllen. Aber erst schau ich mir noch die Grid-implementierung von Lazarus genauer an, vielleicht komme ich dann noch auf eine bessere Lösung.

Ich wusste gar nicht, dass Delphi sowas inzwischen hat. Ich würde TTextFormat in einer deiner zentralen Units deklarieren, so wie in Delphi (das folgende habe ich aus StackOverflow), und dann Konvertierungsfunktionen von TextFormat zu TextStyle schreiben, etwa so

Code: Alles auswählen

type
  TTextFormats = (tfBottom, tfCalcRect, tfCenter, tfEditControl, tfEndEllipsis,
    tfPathEllipsis, tfExpandTabs, tfExternalLeading, tfLeft, tfModifyString,
    tfNoClip, tfNoPrefix, tfRight, tfRtlReading, tfSingleLine, tfTop,
    tfVerticalCenter, tfWordBreak, tfHidePrefix, tfNoFullWidthCharBreak,
    tfPrefixOnly, tfTabStop, tfWordEllipsis, tfComposited);
 
  TTextFormat = set of TTextFormats;
 
procedure TextFormatToTextStyle(AFmt: TTextFormats; var ATextStyle: TTextStyle);
begin
  if tfBottom in AFmt then
    ATextStyle.Layout := tlBottom;
  if tfVerticalCenter in AFmt then
    ATextStyle.Layout := tlCenter;
  if tfTop in AFmt then
    ATextStyle.Layout := tlTop;
 
  if tfLeft in AFmt then
    ATextStyle.Alignment := taLeftJustify;
  if tfCenter in AFmt then
    ATextStyle.Alignment := taCenter;
  if tfRight in AFmt then
    ATextStyle.Alignment := taRightJustify;
 
  ATextStyle.EndEllipsis := tfEndEllipsis in AFmt;  // PathEllipsis, WordEllipsis ??
  ATextStyle.SingleLine := tfSingleLine in AFmt;
  ATextStyle.WordBreak := tfWordbreak in AFmt;
  ATextStyle.Clipping := not (tfNoClip in AFmt);
  ATextStyle.RightToLeft := (tfRtlReading in AFmt);
  ATextStyle.ExpandTabs := (tfExpandTabs in AFmt);
  ATextStyle.ShowPrefix := AFmt * [tfNoPrefix, tfHidePrefix] = [];  // ???
end;

Speziell beim Grid würde ich das dann in der Methode PrepareCanvas aufrufen, um den TextStyle des Grid-Canvas entsprechend zu setzen - PrepareCanvas wird direkt vor der Ausgabe der Zellen aufgerufen und erspart dir das komplette Selberzeichnen der Zellen. Generell sind die Lazarus-Grids wesentlich flexibler aufgebaut als bei Delphi. Schau dir den Wiki-Artikel über Grids an (http://wiki.lazarus.freepascal.org/Grids_Reference_Page).

[braunbär]

Ja, danke. Ziemlich genau das habe ich mit "inklusive neuem Aufzähltyp als Set nachbauen" gemeint. Das dürfte wohl tatsächlich die beste Lösung sein.

[braunbär]

Code: Alles auswählen

  ATextStyle.EndEllipsis := tfEndEllipsis in AFmt;  // PathEllipsis, WordEllipsis ??
  ATextStyle.SingleLine := tfSingleLine in AFmt;
  ATextStyle.WordBreak := tfWordbreak in AFmt;
  ATextStyle.Clipping := not (tfNoClip in AFmt);
  ATextStyle.RightToLeft := (tfRtlReading in AFmt);
  ATextStyle.ExpandTabs := (tfExpandTabs in AFmt);
  ATextStyle.ShowPrefix := AFmt * [tfNoPrefix, tfHidePrefix] = [];  // ???
end;

Zu den obigen Fragezeichen:
Der Delphi Aufzähltyp TTextformat entspricht direkt den möglichen Options-Werten für den Windows-API-Aufruf DrawTextEx
Die Delphi Runtime macht selbst nichts weiter, als diesen Parameter 1:1 an Windows weiterzugeben.
PathEllipsis und WordEllipsis braucht kein Mensch
Und das "Prefix"-Handling betrifft die Sonderbehandlung des Zeichens & in einem Ausgabestring (& kennzeichnet das darauf folgende Zeichen als Acccelerator, das wird dann unterstrichen angezeigt), das braucht in Stringgrid-Zellen eigentlich auch kein Mensch, das ist nur sinnvoll bei der Ausgabe von Menüs und von Labels.

[wp_xyz]

Mit den Fragezeichen meinte ich eher, dass ich nicht weiß, wie diese Optionen den Lazarus-Record-Elementen zuzuordnen sind.

PathEllipsis könnte ich mir schon vorstellen einmal zu brauchen, nämlich (wahrscheinlich) bei Pfadnamen, wo man die Punkte nicht am Ende des Strings haben möchte, sondern (wahrscheinlich) eher in der Mitte. Mit WordEllipsis kann ich nichts anfangen - das müsste man mal mit Delphi ausprobieren.

Bei den Prefix-Optionen war mir beim Schreiben nicht klar, warum es zwei mögliche Einstellungen gibt, die Unterstreichung des Accelerator-Buchstabens zu verbergen. Aber jetzt denke ich, dass tfNoPrefix die Unterstreichung komplett abschaltet, um z.B. ein Firmen-& im Label anzeigen zu klnnen. tbHidePrefix dagegen ist (wahrscheinlich) die seit vielen Jahren eingeführte (unsinnige) Option, die Unterstreichung erst dann anzuzeigen, wenn ALT gedrückt wird.

[braunbär]

tbHidePrefix dagegen ist (wahrscheinlich) die seit vielen Jahren eingeführte (unsinnige) Option, die Unterstreichung erst dann anzuzeigen, wenn ALT gedrückt wird.

Genau. Es gibt dann ja auch die Option DT_PREFIXONLY, mit der nur das Underline ausgegeben wird, der andere Text sollte schon da stehen, damit das Sinn macht. Aber Sinn macht das ganze trotzdem keinen, allein schon, weil es keine Option gibt, mit der man das Underline wieder löschen könnte, wenn die alt-Taste losgelassen wird, da muss man dann erst wieder den ganzen Text (ohne underline) ausgeben, wenn man das so haben will.

Aber jetzt denke ich, dass tfNoPrefix die Unterstreichung komplett abschaltet, um z.B. ein Firmen-& im Label anzeigen zu klnnen.

Vor allem geht es ja hier um die Ausgabe von Texten in Stringgridfeldern, da machen diese sämtlichen Prefix-Optionen überhaupt keinen Sinn. In einem Datenfeld eines Stringgrids braucht man normalerweise keine Accelerators, da ist tfNoPrefix die einzig sinnvolle Option.