Generelles zum Umstieg Lazarus

[wp_xyz]

Hi wp_xyz,

Aber nimm dir eine alte Version von VirtualTreeView; zum einen funktionieren die neuen Versionen nicht mit Delphi 5, und zum anderen unterstützt auch Lazarus nur die Versionen 4 und 5. (Aktuelle ist glaube ich v7).

Habe sowohl bei JAM-Software als auch bei GitHub gesucht, finde aber keine älteren Verionen. Kannst du mir bitte einen Tipp geben, wo ich die 4er oder 5er finde?

Die Version 4.8.7 für Lazarus gibt es auf https://github.com/blikblum/VirtualTree ... lazarus-v4. Für Delphi findest du die Original-Seiten von Mike Lischke (www.delphi-gems.com) noch in der Wayback-Machine, der Download der Version 4.8.7 für Delphi sollte über https://web.archive.org/web/20120624063 ... .php?ID=28 funktionieren (wenn's nicht geht, melde dich nochmals, dann schnüre ich ein Päckchen aus meinen Privat-Archiv).

Ein schnelle Schritt-für-Schritt-Einleitung (ohne Erklärungen) findest du im Lazarus-wiki: https://wiki.freepascal.org/VirtualTree ... or_Lazarus (sollte auch für die Delphi-Version gelten). Ansonsten gibt es noch das sehr gute DelphiTreff-Tutorial (https://www.delphi-treff.de/tutorials/t ... ltreeview/), und sicherlich noch weitere Quellen.

[Jim Knopf]

Hi Winni,

Und verabschiede Dich mal gedanklich von VCL. Das ist alles LCL!

Danke, das ist mir schon klar
Mit dem Ableiten meinte ich natürlich LCL (Gewohnheit ...).

Viele Grüße
Martin

P.S.: Jaa, die Wilde Dreizehn hat was!

[af0815]

Egal, ob du auf die neuen Delphi Versionen umsteigst oder auf Lazarus. Es wird ein Knochenjob von D5 upzugraden. Die Herausforderungen werden ähnlich sein.

Wie schon angesprochen muss man den Code komplett mal durchgehen was ist interne Componentbibliothek und was sind (eingekaufte) Komponenten.

Meiner Erfahrung nach, ein kleines Teilprojekt mit typischen nehmen und mal testen. Etliche inkompatible Spezialitäten lassen sich durch geschicktes Suchen finden, wenn man mal das Muster erkannt hat. Ich selbst stosse da öfters auf die TObjects, die als Integerspeicher missbraucht werden (Mache ich manchmal noch immer, nur halt mit dem richtigen Typ, dann gehts es auch beim Crosscompilieren).

Bezüglich Kompilieren für verschiedene Plattformen. Als Betroffener, kann ich nur sagen, die Unterschiede sind klein, aber oft fies. Das fängt bei den verschiedenen Schriftarten an, geht über Sachen wie zB. das Buttons sich in manchen Widgetsets nicht in der Farbe gut ändern lassen und geht weiter, das eine default Bitmap mal 3 oder 4 Bytes haben kann, je nach default.

Die Liste kann mit etlichen Kleinigkeiten fortgesetzt werden Dazu kann man bei Lazarus auf den verschiedenen Betriebssystemen verschiedene Widgetsets nutzen. Ja auch unter Windows kann man zwischen Windows, Gtk und QT wählen. Das kann schon mal Formular im Design beeinflussen. Da die Darstellung und Verhalten der nativen Widgets auch in der LCL abweichen kann. Die default Schriftarten können da schon abweichen, obwohl jedesmal dasselbe Betriebssystem verwendet wird. Mit Übung ist das nicht das ganz große Problem, allerdings sollte man die Sachen wissen. Mit guter Erfahrung geht es (und die kommt von Schlechter Erfahrung )

Ein riesiger Vorteil von Lazarus ist, die Bugs werden meistens schnell gefixt, wenn man sie richtig Beschreiben kann. Bzw. ist auch das einreichen von Lösungen nicht Verboten, oft werden die Fixes (ev. mit Korrekturen) binnen ganz kurzer Zeiträume ins Projekt eingebracht.
FPC und Lazarus gibt es in mehreren Zustandsstufen (stable, fixes, trunk) das ist ein riesiger Unterschied zu Delphi.

In der Firma muss man sich nur einigen welcher Stand von FPC und Lazarus verwendet wird. Wir verwenden generell fpcupdeluxe und geben dort im erweiterten Setup einen Stand vor. Dieser wurde gegen unsere Software getestet und wird von allen Entwicklern verwendet (für die finalen Kundenprojekte). Das ist bei uns meistens FPC und Lazarus fixes.

[charlytango]

2.Bekommt man z.B. das DevExpress-Grid dann auch für alle machbaren Plattformen gebacken?

Die Antwort weißt du sicher schon --> gar nicht.

Hatte in meinen Delphi-Zeiten und Anfängen die DevExpress Komponenten intensiv verwendet. Hatten auch den Source, doch DevExpress greift da oft direkt auf WindowsAPI zu und benutzt auch andere Tricks die nicht portierbar sind.
Es stimmt zwar dass der Lazarus-Grid um vieles besser ist als der Delphi-Grid, an den Funktionsumfang des DevExpress Grids reicht er bei weitem nicht heran.
Gleiches gilt für die Treeviews.

Bin überzeugt dass man mit VirtualTreeview alles was man sich wünscht auch umsetzen kann -- aber dann muss man das auch reinprogrammieren.
Es gibt die eine oder andere Komponentenbibliothek in der umfangreichere Grid-Implementierungen vorhanden sind, aber da wirst du forschen müssen.

Solltest du eine DevExpress-ähnliche Komponente bauen, könnte ich mir gut vorstellen dass es da auch unter Lazarus Interessenten gibt

[Jim Knopf]

Egal, ob du auf die neuen Delphi Versionen umsteigst oder auf Lazarus. Es wird ein Knochenjob von D5 upzugraden. Die Herausforderungen werden ähnlich sein ... Meiner Erfahrung nach, ein kleines Teilprojekt mit typischen nehmen und mal testen. Etliche inkompatible Spezialitäten lassen sich durch geschicktes Suchen finden, wenn man mal das Muster erkannt hat.

Danke, genauso habe ich es im Sinn.

Ich selbst stosse da öfters auf die TObjects, die als Integerspeicher missbraucht werden (Mache ich manchmal noch immer, nur halt mit dem richtigen Typ, dann gehts es auch beim Crosscompilieren).

Wären da nicht arrays, meinetwegen offene, praktischer ...? Aber auf jeden Fall gut zu wissen, dass in dieser Ecke eventuell Heckenschützen lauern.

Bezüglich Kompilieren für verschiedene Plattformen. Als Betroffener, kann ich nur sagen, die Unterschiede sind klein, aber oft fies. Das fängt bei den verschiedenen Schriftarten an, geht über Sachen wie zB. das Buttons sich in manchen Widgetsets nicht in der Farbe gut ändern lassen und geht weiter, das eine default Bitmap mal 3 oder 4 Bytes haben kann, je nach default.

1. Auch das mit den Schriften ist gut zu wissen. Hast du Erfahrungen, welche Schrifttypen sich am besten eignen? Arial?
2. Was meinst du mit ›Default-Bitmap‹? ImageList-Index? Überhaupt stoße ich öfters auf default. Wo werden diese defaults vorgegeben?

Mit guter Erfahrung geht es (und die kommt von Schlechter Erfahrung )

Wie wahr, wie wahr

FPC und Lazarus gibt es in mehreren Zustandsstufen (stable, fixes, trunk) das ist ein riesiger Unterschied zu Delphi.

Habe gerade gestern auf die aktuellste Version 2.2.0RC1 geupdatet und festgestellt, dass bei SpeedButtons a) eine Fehlermeldung kommt, wenn man die Bezeichnung ändert und b) das Property ›Transparent‹ nur bedingt funktioniert. Ist in solchen Fällen ein Downgrade empfehlenswert?

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

2.Bekommt man z.B. das DevExpress-Grid dann auch für alle machbaren Plattformen gebacken?

Die Antwort weißt du sicher schon --> gar nicht.
Hatte in meinen Delphi-Zeiten und Anfängen die DevExpress Komponenten intensiv verwendet. Hatten auch den Source, doch DevExpress greift da oft direkt auf WindowsAPI zu und benutzt auch andere Tricks die nicht portierbar sind.
Es stimmt zwar dass der Lazarus-Grid um vieles besser ist als der Delphi-Grid, an den Funktionsumfang des DevExpress Grids reicht er bei weitem nicht heran.
Gleiches gilt für die Treeviews.

Das ist natürlich ziemlich frustrierend. Das DevEx-Grid verwenden wir exzessiv, ist ein tolles Tool! Ich habe tatsächlich schon darn gedacht, selbst eines zu machen ... mal sehen. Das große Problem hier ist die Datenkonvertierung bei bestehenden Anwendern. Dass bei einer eventuellen Übernahme einiges anstünde wäre natürlich klar, allein schon die ganzen Strings. Ist halt die Frage, was unterm Strich mehr Aufwand bedeutet: a) Grid versuchen anzupassen = keine Kundendatenkonvertierung und quellcodekompatibel oder b) neues oder bestehendes anderes und beide Vorteile nicht. So betrachtet scheint es Sinn zu machen, sich in den DevEx-Code tiefer einzuarbeiten. Wie siehst du das?

Viele Grüße
Martin

[wp_xyz]

Auch das mit den Schriften ist gut zu wissen. Hast du Erfahrungen, welche Schrifttypen sich am besten eignen? Arial?

Ich würde bei dem Standard-Wert "default" und der Standardfontgröße 0 bleiben - das bedeutet, dass die Standards des Betriebssystem genommen werden.

Dennoch wird bei dem Layout, was unter Windows korrekt aussieht, unter Linux ein Label zu lang werden und ins benachbarte Control hineinreichen. Daher solltest du die Formular-Layouts mit dem Anker-Editor erstellen (https://wiki.freepascal.org/Anchor_Sides) sowie möglichst viel mit AutoSize arbeiten (https://wiki.freepascal.org/Autosize_/_Layout). Damit werden die Controls kontrolliert miteinander verbunden. Also, wenn ein Label länger wird, dann schiebt es das verbundene Edit vor sich her. Und andere Edits, die darunter stehen, wandern mit, wenn alle mit dem linken Ende verankert sind. Das gibt es unter Delphi nicht (soviel ich weiß), aber da du ohnehin die Delphi- und Lazarus-Formulare getrennt halten musst (wegen inkompatibler Properties) spielt das keine Rolle, weil die entsprechenden Änderungen nur in der lfm-Datei stehen (dem Lazarus-Pendent zu dfm).

Habe gerade gestern auf die aktuellste Version 2.2.0RC1 geupdatet und festgestellt, dass bei SpeedButtons a) eine Fehlermeldung kommt, wenn man die Bezeichnung ändert und b) das Property ›Transparent‹ nur bedingt funktioniert. Ist in solchen Fällen ein Downgrade empfehlenswert?

(a) Das mit der Fehlermeldung kommt mir spanisch vor - habe ich noch nicht gesehen. Ohne deinen Code gesehen zu haben, kann ich nicht sagen, wo hier der Fehler liegt - aber ich bin ziemlich sicher: nicht in Lazarus

(b) Das ist auch unter Delphi so. Ist eine Folge davon, dass Windows heute mit Theme-Unterstützung arbeitet - d.h Windows (aber Linux/maxOS genauso) gibt vor wie bestimmte Controls auszusehen haben. Du kannst das für Windows zumindest in den Projekt-Optionen ausschalten - dann sieht dein Programm aber aus wie bei Win95, und deine User werden etwas zu meckern haben.

Ein Grund für ein Downgrade ist keines der beiden.

[Michl]

Habe gerade gestern auf die aktuellste Version 2.2.0RC1 geupdatet und festgestellt, dass bei SpeedButtons a) eine Fehlermeldung kommt, wenn man die Bezeichnung ändert und b) das Property ›Transparent‹ nur bedingt funktioniert. Ist in solchen Fällen ein Downgrade empfehlenswert?

(a) Das mit der Fehlermeldung kommt mir spanisch vor - habe ich noch nicht gesehen. Ohne deinen Code gesehen zu haben, kann ich nicht sagen, wo hier der Fehler liegt - aber ich bin ziemlich sicher: nicht in Lazarus

Das Problem sehe ich auch nicht. Ins Blaue geraten, als Hinweis, das Umbenennen von Bezeichnern von Komponenten muss im Objektinspektor erfolgen. Umbenennen mittels Taste <F2> im Sourcecode geht bei Komponenten auf einem Formular, welches im IDE-Formular-Designer bearbeitett wird, (z.Zt.) nicht.

[Jim Knopf]

Ich würde bei dem Standard-Wert "default" und der Standardfontgröße 0 bleiben - das bedeutet, dass die Standards des Betriebssystem genommen werden.

1. Ich gebe bei mehreren Orten dem Anwender die Möglichkeit, sich Schriften selbst einzustellen. Ist das dann obsolet?
2. Kann man irgendwo sehen, was die diversen Defaultwerte sind?

Danke für den Hinweis bezüglich des Ankerzeugses. Da scheint einiges auf mich zuzukommen bei 150 Fenstern ...

(a) Das mit der Fehlermeldung kommt mir spanisch vor - habe ich noch nicht gesehen. Ohne deinen Code gesehen zu haben, kann ich nicht sagen, wo hier der Fehler liegt - aber ich bin ziemlich sicher: nicht in Lazarus

Nix Code. Ich brauch bloß bei irgendeinem Control beim Namen was einzutippen und Enter oder Pfeil auf/ab zu drücken und es kommt die Meldung Access violation with value "cbTxMemo" (wenn ich gerade der Checkbox diesen Namen spendiert habe). Nehmen tut er es ja und kenntes auch im Code. Trotzdem komisch.

(b) Das ist auch unter Delphi so. Ist eine Folge davon, dass Windows heute mit Theme-Unterstützung arbeitet - d.h Windows (aber Linux/maxOS genauso) gibt vor wie bestimmte Controls auszusehen haben. Du kannst das für Windows zumindest in den Projekt-Optionen ausschalten - dann sieht dein Programm aber aus wie bei Win95, und deine User werden etwas zu meckern haben.

Von z.B. Buttons her kenne ich das schon, ist auch vom Manifest abhängig. Werde noch probieren, irgendwas ist aber seltsam.

Jedenfalls danke für die Infos!

Viele Grüße
Martin

[Jim Knopf]

Hallo Michl,

Ins Blaue geraten, als Hinweis, das Umbenennen von Bezeichnern von Komponenten muss im Objektinspektor erfolgen. Umbenennen mittels Taste <F2> im Sourcecode geht bei Komponenten auf einem Formular, welches im IDE-Formular-Designer bearbeitett wird, (z.Zt.) nicht.

Das Umbenenn erfolgt mitsamt Fehlermeldung ja im Objektinspektor

Viele Grüße
Martin

[Winni]

Hi!

Bzgl der Fonts:

Default ist das. was das Betriebssystem vorgibt. Würde ich nicht mit arbeiten,, da das bei jedem User etwas anderes sein kann. Und falls Du an den Fontgrößen rumrechnen musst, dividierst Du dann womöglich durch Null. Default für Fonts war ein ziemlich dummer Einfall.

Alle Komponenten, die mit Schrift arbeiten, besitzen die Property Font.In dem Komponenten-Reiter "Dialoge" gibt es den FontDialog, über den der Benutzer den Font auswählen kann und dann der jeweiligen Komponente zugewiesen werden kann.

Fall Du dir selbst etwas bauen möchtest: screen.fonts (unit Forms) enthält sämtliche auf dem System vorhandenen Fonts als StringList.

Winni

[Michl]

Default ist das. was das Betriebssystem vorgibt. Würde ich nicht mit arbeiten,, da das bei jedem User etwas anderes sein kann.

Sehe ich genau umgekehrt. Wenn man den default Font nimmt, hat man den Font genommen, den der User für seine Umgebung ausgewählt hat. Warum soll ich ihm den Font aufzwingen, der mir gerade am besten gefällt?

[Winni]

Hi!

Wenn man Bücher herstellt, wird man sich ganz bestimmt nicht auf den Default-Font verlassen.

Das ergibt sich schon aus der Typographie:
Am Bildschirm lassen sich serifenlose Typen (Helvetica, Arial..) am besten lesen, während bei Gedruckten für Fließtext eine Schrift mit Serifen (Times, ..) Standard ist. Guck mal in Deinen Bücherschrank.

Die ersten Lehrlingswochen dazu gibt's hier:
https://de.wikipedia.org/wiki/Leserlichkeit

Zweitens - wie oben schon gesagt - dividier ich nicht gerne durch Null. Nur weil die Default-Fontgröße Null ist. Was für ein Nonsens!

Winni

PS.: Für Fortgeschrittene:
http://www.alles-buch.uni-erlangen.de/bayer.pdf

[wp_xyz]

Ich gebe Michl absolut recht: Software, die mir den Lieblingsfont des Autors aufdrängen will, hat bei mir eine extrem kurze Lebensdauer. Und was hast du gegen die Null? jeder andere Ersatzwert für eine Font-Größe, die je nach Betriebssystem andere Werte annehmen kann, ist genauso Nonsens. Man hätte ein boolsches Property "DefaultFontSize" einführen können, aber dann hätte man immer noch nicht durch diese Fontgröße dividieren können. Dann lieber ein Crash bei der Division durch 0, der mir zeigt, hier stimmt etwas nicht, und ich muss herauskriegen, welche Pixel- oder Punkt-Größe der aktuelle Defaultfont wirklich hat.

Wenn die User von Jim Knopfs Software eigene Texte in einem Textausgabe-Control darstellen wollen, ist das natürlich etwas anderes. Aber ein Fontauswahl-Dialog ist schnell aufs Formular geklickt. Aber auch hier ist der "default"-Font mit Größe 0 immer noch besser als ein hart ins Programm kodierter Font, der auf dem Zielsystem nicht vorhanden ist so dass der Ersatzfont alles durcheinanderbringt.

[Michl]

Wenn man Bücher herstellt, wird man sich ganz bestimmt nicht auf den Default-Font verlassen.

Bei Layout vom Buchtext hast du natürlich recht. Ich war beim Programmlayout, falls das nicht Thema war, dann sorry.

Zweitens - wie oben schon gesagt - dividier ich nicht gerne durch Null. Nur weil die Default-Fontgröße Null ist. Was für ein Nonsens!

Wie hättest du es denn gelöst? Was wäre dein Default-Wert? P.S. eine LFM sollte unter Windows und Linux zu öffnen sein, ohne daß es diesen immer verändert.

[Winni]

Hi!

Wie die Menüs aussehen, ist mir völlig egal. Meinetwegen WingDings. Wer beim DTP mit den Menüs arbeitet, der hat sowieso den Beruf verfehlt. Das frisst Stunden im Arbeitsablauf. Dafür gibt es Hot-Keys.

Und mit den fehlenden Fonts gehe ich, seitdem es Linux gibt, folgendermaßen um:

Ich kopiere den Windows-Font-Folder nach Linux. Und umgekehrt. Außerdem hat Linux inzwischen ein intelligente Logik, die möglichst nahe Fonttypen ersetzt, falls irgendetwas nicht vorhanden ist.

Und wenn man etwas für die Allgemeinheit baut, muss man den entsprechende freien Font mitliefern und vom Installer installieren lassen. That's it.

Winni