Generelles zum Umstieg Lazarus

[TSchnuckenbock]

Ich verfolge die Lazarus-Entwicklung schon seit vielen, vielen Jahren. Was sich da gestan hat seitdem ich das erstmal Lazarus ausprobierte habe ist schon grandios. Alleine OPM (Online Package Manager) und FPCDeluxe sind schon "geile" Features....ach ja, der Debugger (wenigstens unter Windows) war früher auch viel beknackter.
(bei FPCDeluxe baue ich allerdings noch ein bischen Bockmist, wenn es darum geht,. verschiedene Installationen parallel aber autark laufen zu lassen.....das gehört hier aber nicht her und ich hab auch gerade keine Zeit, mich damit zu befassen...ich weiß aber, es geht,. wie Six (?) ja schon schrieb und wp hat sicher auch viele Installationen nebeneinander laufen)

Wenn ich heutzutage vor der Frage stände, mit was ich entwickeln soll, ob Delphi oder Lazarus, dann würde mir die Entscheidung schwer fallen. Delphi hat gefühlt einen schnelleren Compiler, ganz nettes Features in der IDE, die aber auch nicht alle ganz stabil laufen sollen, was man so hört, ist aber recht teuer außer man ist Hobbiest und nutzt die CE-Version.

Lazarus punktet klar mit den Zielplattformen, also Windows und Linux (etc) und es ist Open Source und man kriegst für lau.
Die Community ist hier im deutschen Forum zwar übersichtlich aber hoch-qualifiziert (ich nenne hier jetzt keine Pseudonyme ). Dann gibt's noch das internationale Forum, wo sich Entwickler aus aller Welt tummeln. Bemerkenswert, wo die alle herkommen und ich habe den Eindruck, daß Lazarus immer häufiger in produktiven Umgebungen eingesetzt wird, besonders in Ländern, wo das Budget nicht üppig ist.

TMS bietet nicht ohne Grund inzwischen Komponenten auch für Lazarus an. Letztens meine ich gelesen zu haben, daß Image-Line (Hersteller von FL-Studio) Lazarus auch schon gesponsert hat. Vom Total-Commander-Entwickler C. Ghisler habe ich mal so munkeln gehört, daß er für einige Versionen des TC auf Lazarus gesetzt hat (war da nicht was mit 64-Bit, die Lazarus/FPC eher konnte als Delphi?).

Also für mich ist Lazarus/FPC ein ganz großer Gewinn. Ständig werden Komponenten/Libraries ergänzt und stabilisiert. Herz was willst du mehr?

Und es ist auch mal interessant zu lesen, wie hier im Thread die Sache mal angegangen wird, umfangreichen Delphi-Code zu transferrieren. Wer weiß, ob wir das im Betrieb nicht auch mal machen werden oder ich für ein neues Projekt gleich Lazarus nehme werde.

[Jim Knopf]

Hallo TSchnuckenbock,

jetzt hatte ich schon aus lauter Verzweiflung begonnen, eine TreeList zu schnitzen, dann schreibst du was von TMS. Gleich schauen gegangen und, siehe da, die haben sogar jede Menge an Komponenten!

Jetzt ist es mit Fremdkomponenten immer so eine Sache - man ist schlichtweg abhängig mit dem Zeug und das kann unangenehm bei solchen Portierungen enden, siehe DeveloperExpress, die mit Lazarus nichts am Hut haben wollen. Andererseits denke ich mir, was so Übles passieren soll, wenn man mit Lazarus schon mal auf einer sehr offenen Ebene unterwegs ist und TMS ja ein richtiges Entwicklernetzwerk zu sein scheint.

Danke jedenfalls mal für den Tipp, ich werde mir die TMS-Komponenten gleich näher ansehen.

Viele Grüße
Martin

[af0815]

Für Fremdhersteller hat FPC/Lazarus ein grosses Problem bereit. Sie können keine vorkompilierten Units bereitstellen, da sich jeder seine Varianten kompilieren kann und somit die Prüfsummen nicht zusammenstimmen. Daher kann der Code nur als Source sinnvoll verkauft werden und viele Hersteller von Delphikomponenten schrecken vor diesen Scenario zurück.
Ich habe das mit den Prüfsummen bei einem Hersteller selbst ausprobiert, es geht nicht sinnvoll mit dem FPC. See https://forum.lazarus.freepascal.org/in ... #msg341813

Edit: Vorteil ist somit das man den Source braucht.

BTW, ich habe früher bei Delphi nur Komponenten eingekauft, wo der Source dabei ist. Nur binaries zu kaufen kann für Projekte mit längeren Horizont teuer werden. Weil mit Source kann man notfalls selbst fixen, wenn der Hersteller doch nicht so stabil aufgestellt war oder nicht mehr weitermacht, oder die Komponente komplett verkauft.

[fliegermichl]

jetzt hatte ich schon aus lauter Verzweiflung begonnen, eine TreeList zu schnitzen ...

Hast Du dir den VirtualTreeView mal angeschaut? Ich bin mir hundertprozentig sicher, daß der alles an Funktionalität hat, die du brauchst.

[Jim Knopf]

Hallo Fliegermichl,

jetzt hatte ich schon aus lauter Verzweiflung begonnen, eine TreeList zu schnitzen ...

Hast Du dir den VirtualTreeView mal angeschaut? Ich bin mir hundertprozentig sicher, daß der alles an Funktionalität hat, die du brauchst.

Hab ich mir sehr grob angesehen, danke. Allerdings war ich vermutlich zu dämlich, es sinnvoll zu testen oder die Komponente ist zu unintuitiv. Allein dass ein Record pro Instanz nötig sein soll, kommt mir suspkt vor. Hab wohl drei Stunden herum probiert, nach Infos und Beispielen gesucht, bin aber nicht ansatzweise soweit gekommen, dass ich ein Verwendbarkeitslicht am Horizont gesehen hätte. Unten ein Screenshot, wie es aussehen können muss.

Bin es vom DeveloperExpress-TreeList her gewohnt, dass es mit wenigen Handgriffen so ist, wie ich es brauche. Zudem verwende ich in der Anwendung, für die ich TreeLists benötige, mindestens 150 teils komplexe Instanzen - und das dann alles so kompliziert? Da werde ich vielleicht 2025 fertig.

Ich gehe nach dem Prinzip vor, dass ich lieber etwas Zeit ins Vorfeld investiere, um dann dafür bei der Massenarbeit schnell zu sein. Also denke ich, dass es weniger Arbeit unterm Strich ist, ein Grid selbst zu machen.

Die Installation des TMS-Packages hat übrigens eh nicht funktioniert. Nun warte ich auf Antwort des Supports und hoffe auf Hilfe, sonst habe ich 245 Euro in den Sand gesetzt. Das sind eben diese dummen Abhängigkeiten, die ich so gar nicht mag, weil damit viel nicht sinnvoll verbrachte und vor allem unabsehbare Zeit einhergeht.

Viele Grüße
Martin

[af0815]

Die Installation des TMS-Packages hat übrigens eh nicht funktioniert. Nun warte ich auf Antwort des Supports und hoffe auf Hilfe, sonst habe ich 245 Euro in den Sand gesetzt. Das sind eben diese dummen Abhängigkeiten, die ich so gar nicht mag, weil damit viel nicht sinnvoll verbrachte und vor allem unabsehbare Zeit einhergeht.

TMS ist normalerweise als kompetent und hilfreich bekannt.

Ad VT:
Ich nehme an das kennst du:
https://wiki.freepascal.org/VirtualTree ... or_Lazarus

Das vielleicht nicht, in Lazarus unter Tools->Example Projekts.. findet man mitgelieferte Beispiele zu sehr vielen Themen. Dort dann einmal 'vi' unter Projects eingeben und es werden 3 Beispiele zu Virtualtreeview angezeigt.

Ansonsten, ein kleines Beispiel machen und erklären, was man gerne hätte aber nicht funktioniert und hier posten.

[Jim Knopf]

Danke, af0815, ich werd mir das noch einmal ansehen.

Viele Grüße
Martin

[grl]

Ich gestehe - ich hab jetzt nicht den ganzen Thread durchgelesen.

Aber trotzdem hier einige persönliche Erfahrungen zum Umstieg von Delphi (hier: 7.0) auf Lazarus.

ich bin das schon vor einigen Jahren angegangen und habe Schritt für Schritt portiert - zuerst die hauseigenen Libraries und Komponenten, dann die kleineren Projekte, dann langsam immer größere.
Vorteil hier: ich habe immer schon mit abgeleiteten Klassen für die wesentlichen Komponenten gearbeitet - sogar dann, wenn sie keine neue Funktion hatten. Einfach nur, damit sie einen eigenen Klassennamen bekamen.
Dadurch konnte ich viel über compiler-defines abfangen und/oder Dinge dazuschnitzen, die's in Lazarus nicht oder anders gab.

Jetzt läuft hier praktisch nur noch Lazarus - entwickelt unter Linux, kompiliert für Linux, Windows und ab und zu OSX.

Was mir dabei extrem hilft ist der Anker-Editor. Keine Ahnung ob ein moderneres Delphi sowas auch hat - das Teil ist auf alle Fälle genial, wenn man mit verschiedenen UI-Backends arbeitet.

Wermutstropfen: Der Debugger von Lazarus ist noch bei weitem nicht so gut und praktisch wie der von Delphi 7. Aber mit ein bischen knowhow kann man ganz leicht workarounds finden.

Fazit nach einigen Jahren Arbeit: Der Umstieg ist einiges an Aufwand, aber mir ist Lazarus um vieles lieber als Delphi, große Projekte sind überhaupt kein Problem und die Plattform-unabhängigkeit ist nicht nur ein Werbespruch wie bei vielen kommerziellen Dingern...

Gruß
Luggi

[fliegermichl]

Hab ich mir sehr grob angesehen, danke. Allerdings war ich vermutlich zu dämlich, es sinnvoll zu testen oder die Komponente ist zu unintuitiv. Allein dass ein Record pro Instanz nötig sein soll, kommt mir suspkt vor. Hab wohl drei Stunden herum probiert, nach Infos und Beispielen gesucht, bin aber nicht ansatzweise soweit gekommen, dass ich ein Verwendbarkeitslicht am Horizont gesehen hätte. Unten ein Screenshot, wie es aussehen können muss.

Ja das mit dem Datenmanagement hat mir so auch nicht gefallen. Ich habe sowieso fast immer alles in Klasseninstanzen. Deswegen habe ich den VirtualTreeView für mich etwas erweitert. TVirtualNode hat ein zusätzliches Feld Daten: Pointer bekommen.
Ausserdem habe ich zwei neue Methoden gemacht:

Code: Alles auswählen

function TBaseVirtualTree.AddChildObject(Parent: PVirtualNode;
  UserData: Pointer): PVirtualNode;
begin
 Result := AddChild(Parent);
 Result.Daten := UserData;
end;

function TBaseVirtualTree.InsertObject(Node: PVirtualNode;
  TheData: Pointer; Mode: TVTNodeAttachMode): PVirtualNode;
begin
 Result := InsertNode(Node, Mode);
 if Assigned(Result) then Result.Daten := TheData;
end;

Alle meine Klassen werden von einer Basisklasse abgeleitet, die eine virtuelle Methode

Code: Alles auswählen

function GetText(Column : integer; TextType : TVSTTextType) : string; virtual;

definiert. So kann ich ganz einfach z.B. bei OnGetText darauf zugreifen.

Code: Alles auswählen

procedure TMyForm.TreeGetText(Sender: TBaseVirtualTree;
  Node: PVirtualNode; Column: TColumnIndex; TextType: TVSTTextType;
  var Text: WideString);
begin
 if Assigned(Node) then
  if Assigned(Node.Daten) then 
   Text := TMyBaseClass(Node.Daten).GetText(column, TextType);
end;

So kann jede abgeleitete Klasse diese GetText Methode überschreiben und die Ausgabe abhängig von ihrer Funktion gestalten.
Analog dazu auch die entsprechenden Farben usw.

Ausserdem habe ich eine Reihe von Klassen definiert (basierend auf den Vorlagen von Manfred Fuchs), welche ein einfaches Inlineediting ermöglichen (string / float / integer / time / date / boolean)

Eine Optik/Funktion wie in Deiner Grafik ist problemlos machbar.

In dem Repository, daß wp_xyz auf Seite 2 verlinkt hat, gibt es ein Verzeichnis demos, wo einige auch erweiterte Beispiele drin sind.

[wp_xyz]

Ich habe mich mal hingesetzt und versucht ein paar Nodes deines Screen-Shots mit VirtualTreeView zu realisieren. War etwas eingerostet, und hat etwas gedauert. Aber ich könnte mir vorstellen, wenn du das Prinzip verstanden hast, kannst du die Änderungen recht schnell anwenden, und die 150 Trees durchaus vor 2025 schaffen (will aber nicht verleugnen, dass es doch etwas dauern wird...).

Zur Erläuterung: Ich kenne deine Datenstruktur nicht und habe mir einfach einen Record TKapitel deklariert, in dem alles drinsteht, was ich irgendwie in dem Screenshot identifizieren konnte. Die Icons habe ich aus dem Screenshot extrahiert. Alles wesentliche, was im Vergleich zum Standard-VTV zu ändern ist, habe ich im FormCreate von Hand eingetragen.

Der Daten-Record wird von VTV hinten an den intern verwendeten TVirtualNode-Record angehängt. Daher muss man als erstes die Größe des Datenrecords angeben (Eigenschaft DataSize). Und am Ende braucht man einen Handler für OnFreeNode - weil der Record selbst im VirtualNode enthalten ist, muss man nichts groß freigeben, bis auf den String "Titel", den ich im Kapitelrecord aufgenommen habe (das ist ja eigentlich ein Pointer!).

Die Zeiger auf den Beginn des Datenblocks im TVirtualNode erhält man immer durch den Aufruf von GetNodeData(Node) für den abzufragenden Node. Das ist eigentlich ein allgemeiner "Pointer", aber indem ich die Zwischenvariable gleich als PKapitel (= ^TKapitel) deklariere, kann ich direkt auf die Elemente des Kapitel-Records zugreifen.

Dann werden Handler für diverse Ereignisse implementiert, du kannst ja spaßeshalber einmal den Code zwischen "begin" und "end" auskommentieren, damit du siehst, was das jeweils bewirkt.

Das ist alles ziemlich Standard, bis auf die Info-Spalte (Titel "i"). Hier habe ich einfach eine zweite ImageList verwendet und durch die kompletten Extrakte aus dem Screenshot gespeichert. Im OnAfterCellPaint habe ich das jeweilige Bild dann über die leere Zelle gemalt. Wahrscheinlich ist es aber sinnvoller, die Einzelbilder in einer ImageList zu halten und durch mehrere Aufrufe zum Gesamtbild zusammenzubauen. Das wollte ich nicht mehr implementieren, da ich keine Ahnung habe, was die Bilder bedeuten.

Wenn du Laz 2.0.x verwendest, brauchst du nichts zu installieren. Ab Laz 2.2 heißt die in Lazaraus integrierte Version aber anders (Vorsilbe "Laz"). Um denselben Quellcode zu haben, müsstest du hier die Version aus dem Online-Package-Manager installieren.

[Jim Knopf]

Hallo grl, Fliegermichl und wp_xyz,

danke für die Lazarus-Erfahrungen, grl. Noch bin ich ja nicht wirklich im Lazarus-Echtbetrieb, sondern in der Erfahrungssammelphase, für die mir deine Informationen helfen.

Danke dir, wp_xyz, für dein tolles Beispiel! Sieht ja wirklich sehr ähnlich aus. Und ein sehr anschauliches und schön dokumentiertes Beispiel - nochmals danke!
Die Applikation spuckt mir aber beim Beenden Fehlercode ins Gesicht. Vielleicht habe ich mit der Lazarusversion 2.2.0RC1 ja auch den Fehler gemacht, was zu Neues zu nehmen. Gibt es irgendeine Daumenregel, welche Version üblicherweise stabil sind und wo man nicht ständig updaten muss?



@Fliegermichl und wp_xyz: Noch kann ich es drehen und wenden, ich finde das Handling von dieser TreeView superkompliziert. Wenn ich das mit dem DevExpress-Grid vergleiche, dann kommt mir das viel einfacher vor. Aber vielleicht habe ich dazu einfach auch die Anfänge vergessen und damals ging es mir auch so. Was braucht man denn mehr als Columns und Nodes, alles in der Hauptkomponente verpackt, ein paar Eigenschaften und wenige Events. Es mag sicher sehr leistungsfähig sein, das bezweifle ich nicht. Aber die Philosophie ist mir sehr fremd. Und das hat den blöden Nebeneffekt - abseits des Hineindenkens - dass auch die Konvertierung der rund 150 grids sehr aufwändig ist. Also sehe ich mal mit einem eigenen TreeView dazu, setze mir eine Deadline von zwei Wochen füs Gröbste.

Eine Frage an euch habe ich bezüglich TMS: Die haben mir Folgendes zurückgeschrieben:

We have heard of problems with Lazarus 2.0.12. We are in touch with the Lazarus team about this.
We recommend for now to use Lazarus 2.0.6 or 2.0.8 that should not be affected by this.
We hope the Lazarus team resolves the issues with 2.0.12 as soon as possible with a new release.

Ich habe aber, wie gesagt, 2.2.0RC1 - an wen soll ich mich da wenden ...? Sorry für die viele Fragerei, aber es ist hier alles sehr neu und ich bin es nicht so gewohnt, mich mit diesen Belangen zu beschäftigen. Das hat nämlich früher bei uns jemand anderes gemacht, dem das sehr gelegen ist, doch auf ihn habe ich keinen Zugriff mehr.

Viele Grüße und einen schönen Abend!
Martin

[wp_xyz]

Die Applikation spuckt mir aber beim Beenden Fehlercode ins Gesicht.

Nein, das ist kein Fehler, das ist die Ausgabe von heaptrc, der Speicherprüfung. Ich hatte nämlich vor dem Abschicken noch schnell die Idee, zu prüfen, ob nicht doch noch ein Speicherleck in meinem Beispiel versteckt ist - dazu wird in den Projektoptionen > Compilereinstellungen > Debuggen die Checkbox vor "HeapTrc Unit verwenden" gesetzt. Die Zeile "0 unfreed memory blocks" zeigt, dass beim Programmende keine Speicheranforderungen mehr offen sind. Wenn du das Häkchen wieder wegmachst, ist die Meldung am Ende weg.

Vielleicht habe ich mit der Lazarusversion 2.2.0RC1 ja auch den Fehler gemacht, was zu Neues zu nehmen. Gibt es irgendeine Daumenregel, welche Version üblicherweise stabil sind und wo man nicht ständig updaten muss?

Die letzte "2" in V2.2 ist eine gerade Zahl - das ist eine Release-Version.gerade. 2.3 ist ungerade - das ist die aktuelle Entwicklerversion (="unstabil"). Das RC1 hinter 2.2 bedeutet, dass es sich um den "Relase-Candiate" handelt, also die erste Testversion vor dem Release - es kommt nicht neues mehr dazu, es werden nur noch Fehler behoben. Vielleicht kommt noch ein RC2 oder ein RC3 vor dem endgültigen Release. Also: ein kleines Risiko gibt es noch... Aber natürlich: auch in der endgültigen Release-Version werden noch Fehler stecken, die dann im Fixes-Zweig (v2.2.1) behoben werden, der dann vielleicht zu einem neuen stabilen Relase 2.2.2 führen wird.

Noch kann ich es drehen und wenden, ich finde das Handling von dieser TreeView superkompliziert. Wenn ich das mit dem DevExpress-Grid vergleiche, dann kommt mir das viel einfacher vor.

Klar, bei dem DevExpress-Grid ist vieles in Properties schon fest eingebaut, was du hier noch einzeln über die Events implementieren musst. Du könntest dir aber natürlich eine neue, auf TVirtualStringTree basierende Klasse erzeugen, in der auch mehr schon vorbereitet ist. Leider kenne ich das DevExpress-Grid nicht, und kann dir konkret nicht dabei helfen, wo man genau ansetzen müsste. Auf jeden Fall wird intern in dem DevExpress-Grid etwas ähnliches ablaufen wie bei dem VirtualstringTree.

[siro]

HeapTrc Fenster:
Ich finde das "Error" Fenster übrigens auch immer wieder verwirrend.
Ein "Einzeiler" würde die Verwirrung, grade bei NeuEin/Umsteiger beseitigen.
if unfreed Blocks = 0 then caption:='no error';

Siro

[Ich934]

Das gibt's doch bzw las es gar nicht einblenden wenn es keine Fehler gibt: Show only on leak

[siro]

Oh, das kannte ich noch nicht , Danke für die Info.
Es wäre vielleicht trotzdem sinnvoll eine solch "kleine, einfache" Änderung vorzunehmen.