Plattformübergreifend - Augenauswischerei ...?

[jik]

Kurz zu meiner Vorgeschichte: Ich arbeite seit 1998 mit Delphi. Wir haben damals mit meiner IT-Firma mit Delphi3 begonnen und sind dann bei D5 stehen geblieben, da danach (nach unserer Ansicht damals) die Griffigkeit verlorenging. Bis heute arbeite ich mit D5 und habe nun in Eigenregie seit zehn Jahren ein großes Projekt am Laufen, Patchwork, ein Programm für Schriftsteller, seines Zeichens das umfangreichste Autorenprogramm (viel Eigeninteresse dabei, weil ich selbst schreibe). Immer wieder erhalte ich aber Anfragen, warum es das nicht für 'wenigstens' MacOS gäbe - verständlich, weil sich viele Autoren als Künstler sehen und Künstler gerne Mac nutzen.

Blauäugig (und vielleicht zu draufgängerisch) wie ich nun mal mit Neuem bin, habe ich zuerst mal Lazarus ausprobiert. War positiv überrascht, wie ähnlich es D5 ist, aber ... die wichtigsten Zusatzkomponenten für Patchwork sind die von Developer Express, brauche ich in fast jedem der über 70 Formulare, oft mehrere. Die sind leider nicht auf Lazarus portierbar wegen der zu großen/tiefen Windows-Affinität. Der Ersatz wäre die TVirtualStringTree-Komponente. Anscheinend sehr leistungsfähig, aber vergleichsweise extrem aufwendig/umständlich zu programmieren und vor allem so gut wie nicht dokumentiert - wie das leider oft bei kostenfreien Sachen der Fall ist.

Also hab ich mich doch für D12 entschieden und bin nun da. Denn Delphi 12 ist ja plattformübergreifend und IOS und Android auch noch. Und Embarcadero eine große Firma und es gibt Doku ...
Meine bisherigen Erfahrungen sind - bis auf die Hilfe hier im Forum - eher ernüchternd. Und nun fiel mir siedend heiß in der Nacht ein: Selbst wenn es von DevExpress Grids & Co in neu gibt - sind die überhaupt wenigstens MacOS-fähig??

Vor diesem Post habe ich Artikel hier zu plattformübergreifend gelesen und heftige Zweifel bekommen: 'Nur VCL', 'FMX nicht brauchbar' und weitere abtörnende Erfahrungen.

Nun meine Fragen an euch:
1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?
2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.
3. Wisst ihr, ob überhaupt DevExpress-Grids MacOS-fähig sind ...?
4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Danke für eure Lese- und Antwortszeit. Wäre euch für viele Antworten sehr dankbar, denn es geht um eine große Grundsatzentscheidung, die Mannjahre hinter sich herzieht.

[Uwe Raabe]

Kurz gesagt, wenn du auf DevExpress quasi festgelegt bist, dann musst du bei VCL bleiben. Plattformübergreifend geht bei Delphi mit bordeigenen Mitteln aber nur mit FMX. Selbst das als Zusatzprodukt verfügbare CrossVCL, mit dem VCL-Anwendungen mit Delphi auch für MacOS erstellt werden können, hat die Unterstützung von DevExpress mittlerweile eingestellt.

Natürlich kann man mit Delphi auch für MacOS entwickeln. In der Regel sind aber bestehende VCL-Programme bezüglich des User Interfaces komplett neu aufzubauen. Meistens kommt das einer kompletten Neuentwicklung schon sehr nahe.

[philipp.hofmann]

Wenn man von Anfang an mit FMX mit dem Ziel plattform übergreifend entwickelt, bietet Delphi da einem sehr viel, da bin ich eigentlich recht happy und nutze zusätzlich relativ viele TMS-Komponenten. Eine Portierung eines VCL-Projektes ist aber eine ganz andere Geschichte.

[Phoenix]

Wenn Du wirklich echte zukunftsfähige Cross-Plattform Anwendungen bauen willst, dann bist Du mit allem Nativen auf dem Holzweg. Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.
Wir machen das seit mehr als 10 Jahren extrem erfolgreich. Wir haben schon viele andere Ansätze gesehen und auch Kunden gehabt die das nicht glauben wollten und es anders versucht haben. Davon sind ausnahmslos alle gescheitert.

Oder andersum gesagt, wenn Du etwas für eine Plattform bauen willst, nimm am besten ausschließlich Tools dafür, die auch auf dieser Plattform laufen.
Willst Du für den Mac bauen, nehme Tools die auf dem Mac tun. Willst Du für Mac und Windows bauen, nehme Tools die auf Mac und Windows tun. Willst Du für Mac, Windows, Linux, Android und iOS bauen, nehme Tools die überall dort laufen. Wenn (komplexes) Entwicklungstooling dort läuft, kannst Du davon ausgehen dass auch Deine Anwendung die damit gebaut ist dort tut.

Unser Stack ist Angular fürs Frontend und .NET auf dem Backend, aber alles was JS/TS ist (React, Vue etc.) wird vorne tun und hinten kannst Du gerne auch JS/TS nehmen (Node) wenn Du nix besseres haben willst ;)

[jaenicke]

Zitat:

Zitat von jik (Beitrag 1531657)

1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?

Lazarus kann durchaus einiges, kommt an Delphi aber bei Weitem nicht heran. Wenn man nur kostenlos möchte und dafür deutlich mehr Aufwand in Kauf nimmt, ist es trotzdem keine schlechte Wahl.

Wenn man aber Kaufkomponenten einbezieht, kommt man mit Delphi meiner Meinung nach deutlich weiter.

Zitat:

Zitat von jik (Beitrag 1531657)

2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.

Das steht dann in der Regel schon deutlich dabei, wenn du im Internet angebotene Komponenten meinst. In Delphi selbst brauchst du nur schauen, was unter FMX zur Verfügung steht.

Zitat:

Zitat von jik (Beitrag 1531657)

3. Wisst ihr, ob überhaupt DevExpress-Grids MacOS-fähig sind ...?

Es gibt auch das FMX Data Grid von DevExpress. Das ist plattformunabhängig (Windows, Android, and macOS).

Von TMS gibt es auch größere Sammlungen an plattformunabhängigen Komponenten (TMS FNC UI Pack, ...).

Zitat:

Zitat von jik (Beitrag 1531657)

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Definitiv nicht. Da hat sich so viel getan, unabhängig von Plattformunabhängigkeit, dass das keinen Sinn macht (Unicode, Generics, ...). (Außer, weil der Umstieg zu viel Aufwand wäre natürlich, dann geht es ggf. nicht sofort, aber man sollte dran arbeiten, wenn das Produkt weiterentwickelt wird.)

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1531669)

Es gibt auch das FMX Data Grid von DevExpress. Das ist plattformunabhängig (Windows, Android, and macOS).

Ich bin vielleicht nicht ganz auf dem Laufenden, aber hat sich an dem Status wie hier beschrieben mittlerweile was geändert?

[jaenicke]

Da davon nichts bei der Komponente dabei steht, wusste ich davon nichts. Ich habe mich einfach auf diese Webseite verlassen. Ich kenne die DevExpress Komponenten kaum, da ich immer bei denen von TMS war.

[Uwe Raabe]

Okay, dann ist der Blog-Post offenbar immer noch aktuell.

[QuickAndDirty]

Ich weiß nicht wer davon überzeugt ist das FMX nicht brauchbar wäre... Ich finde es besser als die VCL Und habe Apps und Programme für Windows, Android und IOS mit FMX geschrieben. Das geht alles an sich richtig gut.

Lazarus ist auch sehr schön fürs Hobby.

Du wirst kein VCL Projekt mit 70 Formularen auf Android und IOS portieren , es sei denn du hast dich an eine strikte Trennung von Oberfläche und Geschäftlogik gehalten. Dann sollte es kein problem sein die Oberfläche auszutauschen und eine FMX Oberfläche gegen die Geschäftslogik zu binden.
Es steht auch noch zu bedenken, dass du evtl. sowieso neue Formulare designen willst, denn große Auflösungen machen das evtl . notwendig...dann kannst du bei der Gelegenheit gleich zu FMX wechseln.

[himitsu]

Es gibt halt auch ein paar Fallstickte.

Normal hat FMX alle viele System-Komponenten so in etwa nachgebaut.
* nicht nachgebaute Funktionen fehlen dann natürlich
* nativ haben z.B. ScreenReader ein Problem damit, weil für sie diese "Delphi"-Komponenten nicht existieren (gibt es aber teilweise auch eine API zum Nachrüsten, damit "viele" / nicht alle Reader die Infos hintenrum bekommen)
* gibt es ein altes/neues Windows, mit einem anderen Style, dann sieht dein Programm "alt" aus, weil es ja seinen "eigenen" FMX/VCL-Style mitbringt
* ebenso, wenn Windows oder Zusatzprogramme neue Funktionen für eine Komponente nachrüsten, welche die Delphi-Komponente noch nicht kennt
* * z.B. Shortcuts für Smilies/Sonderzeichen, gewisse Eingabeeditoren, Live-Übersetzungen, Sprachsteuerung usw.
* ...

Drum gibt es für einige Komponenten auch die Möglichkeit die native Komponente zu nutzen, welche dann von Delphi über die Form (3D-Zeichenfläche) gelegt wird.

[jik]

Zwischenantwort(-status) neben großem Danke, weil mich eure Posts wirklich weiterbringen:

1. Habe ich so von den TMS-Komponenten erfahren, die denen von Developer Express recht ähnlich zu sein scheinen, und die gibt es für FMX - klingt gut
2. Ich möchte die Anwendung ohnehin großteils neu erstellen und mit einer Mini-Version für den kleinen Einstieg beginnen. Also ist direktes Portieren kein Thema außer vielen Funktionen
3. @QuickAndDirty: Wenn, dann wird es auf Android ohnehin nur eine Light-Version geben, schon allein des begrenzten Platzes wegen
4. Auf D5 würde ich schon von wegen 32bit und kein Unicode ohnehin nur als letzte Notlösung bleiben

Und dann doch noch schnell eine Frage: Warum wird mein zwar vorhandenes Profilbild nicht angezeigt und ich kann es auch nicht ändern und auch keine Signatur eingeben. Muss ich mich noch eigens wo anmelden?

[TuPas]

Hallo jik,

ich hatte mir auch mehr Cross-Komponenten beim Kauf der D12 erhofft.

Wenn man im Designermodus mit der Maus auf die Komponenten zeigt wird eine Sprechblase mit den Unterstützen Plattformen angezeigt.

Mir fehlen für eine komfortable Cross-Entwicklung die Datenbankunterstützungen bei Eingabe-Elemente und Grids.
Nicht umständlich über irgendwelche TStringGrid oder so, das langweilt mich, wenn man die VCL-Schiene kennt.

Jetzt habe ich die Enterprise-Version gekauft und muss entweder viel selbst Hand anlegen um Elemente zu programmieren oder ich kaufe wieder kräftig irgendwelche Drittanbieter-Elemente.

Meine persönliche Erfahrung ist aber, eher die Module kapseln, so dass man das UI stark von dem Rest trennt und dann so nativ wie möglich das UI programmiert um auch wirklich das jeweilige UI und die Konnektivität des jeweiligen Betriebssystems voll auszunutzen (MVC Model).

Ein paar Tests habe ich mit FMX schon gemacht mit einer Anwendung, die auf Win, iOS, Android und macOS läuft. Aber so richtig haut es mich vom Handling her noch nicht vom Hocker.
Aber ich bin noch in der Antastphase - das kann sich also durchaus noch geben.

BTW ... ich muss über GetIt jetzt mal den FastReport VCL und FastReport FMX installieren und sehen, wie brauchbar der ist.

Viel Erfolg jedenfalls bei Deiner Portierung - und berichte bitte.


Gruß

TuPas

[himitsu]

Im FMX geht es mit den hauseigenen Komponenten eh nur über die LiveBindings.
DB-aware Komponenten, wie man sie von der VCL kennt, sind dort out.




Weil du kein Bild dafür hochgeladen hast :zwinker:

Mein Profil > Profilbild
Einstellungen&Optionen > Benutzerbild

[jaenicke]

Zitat:

Zitat von TuPas (Beitrag 1531687)

Mir fehlen für eine komfortable Cross-Entwicklung die Datenbankunterstützungen bei Eingabe-Elemente und Grids.

Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt. Insofern vermisse ich diese auch nicht bei FMX. Dort gibt es dafür aber auch Databinding, wenn man es denn unbedingt nutzen möchte.

Eine wirklich gute Gridkomponente vermisse ich aber bei FMX wirklich sehr. Da kommt man um einen Kauf einer guten Komponente nicht herum, wenn man diese benötigt. Mir gefällt die von TMS schon gut:
https://www.tmssoftware.com/site/tmsfncuipack-grid.asp
Aber für eine plattformübergreifende TVirtualStringTree mit auch nur annähernd der Funktionalität der VCL Version wäre ich bereit einiges zu zahlen (und ich denke einige andere auch).

[Mavarik]

Zitat:

Zitat von jik (Beitrag 1531657)

Nun meine Fragen an euch:
1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?

Delphi und FMX bietet aus meiner Sicht alles was man braucht.
Ich programmiere seit XE8 nur noch FMX und überhaupt kein VCL mehr.

Zitat:

Zitat von jik (Beitrag 1531657)

2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.

Eigentlich reichen die FMX Komponten - Wenn Du etwas anders brauchst, kannst Du (wie bei VCL) eine FMX Komponente als Basis nehmen und damit neue Komponenten erstellen.

Zitat:

Zitat von jik (Beitrag 1531657)

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Nein - D5 ist gruselig wenn wenigstens D2007 - aber was willst Du mit den alten Zeug?

TMS hat Komponenten die Sowohl für VCL und FMX geeignet sind.

Beispiele für FMX findest Du auf meinen YouTube Kanal. (Und auf vielen anderen)

[Rollo62]

Zitat:

Zitat von Phoenix (Beitrag 1531666)

Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.

...

aber alles was JS/TS ist (React, Vue etc.)

Damit bin ich im Prinzip völlig mit einverstanden, nur JS ist wirklich völlig plattformübergreifend.

Nur leider komme ich jedes Mal, wenn ich wieder etwas Neues/Hybrides austeste, ganz schnell an irgendwelche Grenzen.
Solange man Web-Zentrierte Apps baut, die nicht viel von der Hardware oder von den Mobil-Spezialitäten nutzen, dann mag das OK sein.
Sobald man Location, Background-Modi, Bluetooth, Sensoren, Audio, Mail, SMS, PhoneCall, Mikrofon, SpeechRecognition, usw. usw. usw. braucht,
dann gibt es mit Web-Technologie oft noch mehr Beschränkungen als rein nativ.

Egal ob Flutter, React oder Xamarin, ich finde oft sehr viel ähnliche Beiträge in den Foren dort, wo es genauso wenig Lösungen gibt wie bei Delphi.
Zuletzt hatte ich bei Flutter gesucht, wo geschrieben stand: Ja, geht im Prinzip, da gab es diese OpenSource Library ( allerdings nur ein proof-of-concept, ungepflegt), aber offiziellen Support gab es nicht.
Ok, die Entwicklung geht da natürlich rasant immer weiter, aber ein kompletter No-Brainer ist IMHO keine dieser Technologien.

Das Problem ist ja mehr politischer Natur, wenn der Zugriff durch Google/Apple unnötig verkompliziert und restriktiver gemacht wird, ohne Rücksicht auf Verluste.

Deshalb ist Delphi gar nicht so verkehrt, für solche Anwendungen.
Und bei den ganzen obskuren Problemen, die mir untergekommen sind, wenn ich dann mal über den Tellerrand schaue:
Auch Xamarin, Unity, React, Flutter, NetMAUI, ja sogar XCode und Android-Studio selbst, haben oft die gleichen Probleme an die Hardware zu kommen.

Ich würde mir wünschen, einfach nur eine App mit einem DB-View machen zu müssen, eventuell noch mit REST-API,
aber meistens kommt dann doch noch sehr viel obendrauf.

[jik]

Zitat:

himitsu schrieb: Weil du kein Bild dafür hochgeladen hast
Mein Profil > Profilbild
Einstellungen&Optionen > Benutzerbild

Genau dorthin würde ich gern, aber ich finde es beim Profil nicht (siehe hier) und außer neben Willkommen, xyz finde ich nichts. Seltsamerweise konnte ich früher mal das Bild einfügen, kann es jetzt aber nicht mehr ändern. Und Signatur finde ich auch nicht.

Zitat:

jaenicke schrieb: Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt.

Bei plattformübergreifend vermutlich schon. Wir hatten uns selbst seinerzeit eine Schnittstelle zu Pervasive (live und SQL) geschaffen mit abgeleiteten Komponenten. Das war auf jeden Fall angenehmer, als Daten und GUI komplett zu trennen. So hatten wir eine Applikation, aber die wurde dadurch etwas krakelig.

Zitat:

Aber für eine plattformübergreifende TVirtualStringTree mit auch nur annähernd der Funktionalität der VCL Version wäre ich bereit einiges zu zahlen (und ich denke einige andere auch).

Meines Wissens ist TVirtualStringTree plattformübergreifend. Aber zum Programmieren ein Horror mit den ganzen Records und Zeigern. Diesbezüglich war die Treelist von Developer Express optimal. Für eine gescheite TreeView würde ich auch gern was zahlen. Ist die von TMS nicht so etwas?

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

[jaenicke]

Zitat:

Zitat von jik (Beitrag 1531697)

Meines Wissens ist TVirtualStringTree plattformübergreifend.

Die von Lazarus wohl ja, inwieweit weiß ich nicht. Und die FMX Version wohl auch, aber die ist noch nicht so weit. Das Hauptprojekt ist rein für Windows.

Zitat:

Zitat von jik (Beitrag 1531697)

Aber zum Programmieren ein Horror mit den ganzen Records und Zeigern.

Seit Generics unterstützt werden braucht man direkt keine Pointer mehr (fand ich allerdings auch nicht schlimm). Und Records muss man auch nicht nutzen. Ich habe die Komponente meistens generisch mit Klassen verwendet. (Vor der offiziellen Unterstützung hatte ich die Generics selbst drüber gebaut.)

Zitat:

Zitat von jik (Beitrag 1531697)

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

Weil du unter den mobilen Plattformen keinen länger laufenden Code in einem Buttonklick drin haben darfst. Unter Windows ist das nur unangenehm für den Benutzer, unter Android oder iOS kommst du mit solch einem Code nicht in den AppStore.

[bernhard_LA]

ich hatte die (Sisyphos-)Aufgabe vor einigen Jahren unsere Anwendung auch unter LINUX bereitzustellen. Ca. 1 Mio Zeilen Quellcode alles mit VCL programmiert und keine TestCases.
Die Strategie für Cross-Plattform bei uns:

• GUI Code von BL-Logik Trennen ....
• Code Refaktoring nch MVVM (https://de.wikipedia.org/wiki/Model_View_ViewModel) oder vergleichbaren Ansatz
• beide Plattformen unterstützen über compiler switches ( dann kann man immer auf die lauffähige VCL Version zugreifen)
• testcase einführen wann immer es geht :-)
• zu allen Überfluss haben wir auch 2 DB Interface in der Compiler Switch Option
  Delphi-Quellcode:

  {$IFDEF Framework_ADO }

  und
  Delphi-Quellcode:

  {$IFDEF Framework_Firedax }

Delphi-Quellcode:

uses
  types,
  classes,
  SysUtils,
{$IFDEF FrameWork_VCL}
  vcl.Graphics,
  .....
{$ENDIF}
{$IFDEF FrameWork_FMX}
  FMX.Graphics,
  .....
{$ENDIF}



....

[jik]

Noch einmal ganz herzlichen Dank für die Mühe, die ihr euch für die Erklärungen gemacht habt - das finde ich supernett!

Nun muss ich mich mal in das Ganze einarbeiten, was sehr aufwendig ist (was denn sonst :) ). Noch bin ich mir immer noch nicht ganz sicher, ob es Lazarus oder Delphi 12 wird - auch wenn von vielen Lazarus als Hobbytool gesehen wird. Die Tendenz, mal abzustürzen kommt mir bei Lazarus tatsächlich etwas größer vor. Die jetzt leider nicht zu klärende Frage: Was ist, wenn es wirklich viel Code und Units werden ...?

Bisher habe ich halt alle Energie in die Weiterentwicklung des Paketes investiert und mir wenig Zeit genommen, rundherum zu schauen. Denn alle hie und da unternommenen Versuche haben mich relativ bald verstört. Und auch ich glaube, dass mein geschätztes 5er-Delphi mit seinen 32bit-Programmen irgendwann mal outdated sein wird (so nett ich denke, das Programm trotzdem hingebracht zu haben - nicht supermodern, aber es geht, zumal man selbst die 24 Skins sogar anpassen kann). Beim Mac ist das ja schon vor einiger Zeit passiert: Nix 32bit - basta. Allerdings läuft bei Windows intern so viel auf 32bit, dass ich mich noch einigermaßen sicher fühle. Aber Unicode ist ein großes Thema, denn Autoren, die slawische, griechische oder russische Namen verwenden, sind verärgert, wenn das nicht geht.
Das Dumme ist einfach, dass mehrere Dinge unter einen Hut gebracht werden müssen:

1. Plattformunabhängig wäre schön
2. Unicode sollte sein - ist ja ein Programm für Schriftsteller
3. Eine leistungsfähige TreeView - Developer Express war da super, wird aber selbst bei Delphi nicht für Multiplattform mehr unterstützt. Also TFM? Kann das alles? Sieht mir nicht so aus und ich muss sehen, ob man die Optik schöner bekommen kann (als die Demos). Und TVirtualStringTree kann zwar sehr viel, aber die ganzen Records und Zeiger sind für so viele Grids wie ich habe ein Horror.
4. Zum Glück gibt es den Super-Editor TRichViewEdit und TSRichViewEdit von Serge Tkachenko, der auf D12 und Lazarus läuft - eine Wohltat.
5. Ausgabe des Endprodukts (Buch) des Anwenders als PDF-Datei.
6. Ein leistungsfähiges Ribbon, sonst müsste ich das eigene portieren, was vermutlich das kleinste Übel ist. Denn obwohl TSpkToolbar nett aussieht, scheint es beim Schmalermachen des Monitors die Tabs nicht zu schrumpfen können. TFM kann das zwar, aber laut Demo unkontrolliert (kommt mir vor) und vor allem ist das Fenster beim Ziehen ruckelig. Dafür sind die Styles recht gut durch Einbeziehung der Titelleiste, aber der Rand wird durch ein Pixel schlecht fassbar ...

So fühle ich mich derzeit abends total geplättet vor lauter Lesen und Ausprobieren und bin sehr dankbar für eure fachlichen Erfahrungen und Unterstützungen!

Hier noch ein Screenshot, damit ihr seht, worum es überhaupt geht: 164 Fenster bei rund 240.000 Zeilen Code (ohne jegliche Komponenten)

https://autorenprogramm.com/down/tmp/pw.png

[jaenicke]

Zitat:

Zitat von jik (Beitrag 1531729)

Die jetzt leider nicht zu klärende Frage: Was ist, wenn es wirklich viel Code und Units werden ...?

Bei viel Code sprechen wir von Millionen Zeilen. Bei Delphi gibt es seit der Umstellung auf den LSP zur Codevervollständigung Probleme, wenn man Kreuzbeziehungen zwischen Units drin hat. Das ist zwar sehr unsauberer Code, aber leider weit verbreitet. Wenn du das nicht hast, solltest du in aller Regel mit Delphi in deiner Größenordnung des Codes keine Probleme haben.

Zitat:

Zitat von jik (Beitrag 1531729)

3. Eine leistungsfähige TreeView - Developer Express war da super, wird aber selbst bei Delphi nicht für Multiplattform mehr unterstützt. Also TFM? Kann das alles? Sieht mir nicht so aus und ich muss sehen, ob man die Optik schöner bekommen kann (als die Demos).

Die TMS FNC Treeview kann auf den ersten Blick das, was bei dir auf dem Screenshot zu sehen ist. Diese ist plattformunabhängig bis hin zum Web:
https://www.tmssoftware.com/site/tms...k-treeview.asp

Zitat:

Zitat von jik (Beitrag 1531729)

4. Zum Glück gibt es den Super-Editor TRichViewEdit und TSRichViewEdit von Serge Tkachenko, der auf D12 und Lazarus läuft - eine Wohltat.

Bei den TMS FNC Komponenten ist auch ein Rich Editor dabei, auch für alle Plattformen. Was der kann, weiß ich nicht.

Zitat:

Zitat von jik (Beitrag 1531729)

5. Ausgabe des Endprodukts (Buch) des Anwenders als PDF-Datei.

Auch dafür hat TMS eine plattformunabhängige Bibliothek:
https://www.tmssoftware.com/site/blog.asp?post=377
https://download.tmssoftware.com/dow...ryDevGuide.pdf
Wenn du den TTMSFNCRichEditor verwendest, kannst du den Inhalt auch in die PDF Bibliothek gießen.

Zitat:

Zitat von jik (Beitrag 1531729)

6. Ein leistungsfähiges Ribbon

Die TMS FNC Ribbon kann schon viel:
https://www.tmssoftware.com/site/tms...ack-ribbon.asp

[dummzeuch]

Zitat:

Zitat von bernhard_LA (Beitrag 1531703)

Delphi-Quellcode:

uses
  types,
  classes,
  SysUtils,
{$IFDEF FrameWork_VCL}
  vcl.Graphics,
  .....
{$ENDIF}
{$IFDEF FrameWork_FMX}
  FMX.Graphics,
  .....
{$ENDIF}



....

Diese ifdefs kann man im Prinzip auch durch unit aliases oder unit scope names ersetzen. Dann bleibt der Code lesbarer. Allerdings ist dann evtl. nicht mehr ganz so gut sichtbar, welche Unit jeweils vewendet wird.

[himitsu]

Zitat:

Zitat von dummzeuch (Beitrag 1531736)

Diese ifdefs kann man im Prinzip auch durch unit aliases oder unit scope names ersetzen.

In diesem Fall also.

Delphi-Quellcode:

uses
  Types,
  Classes,
  SysUtils,
  Graphics,

VCL-Projekte haben als Namespace standardmäßig "VCL"
und FMX-Projekte ein "FMX" in den Projektoptionen.
Projektoptionen > Erzeugen > Delphi-Compiler > Unit-Gültigkeitsnamen.

Wird eine Unit unter dem angegebenen Namen nicht gefunden, dann werden diese Namespaces durchprobiert.
z.B. bei den ersten Units wurde das bereits angewendet, denn diese Units heißen seit einer Weile ja schließlich so:

Delphi-Quellcode:

uses
  System.Types,
  System.Classes,
  System.SysUtils,
  ...

[Rollo62]

Zitat:

Zitat von jik (Beitrag 1531729)

1. Plattformunabhängig wäre schön
...
4. Zum Glück gibt es den Super-Editor TRichViewEdit und TSRichViewEdit von Serge Tkachenko, der auf D12 und Lazarus läuft - eine Wohltat.

Wenn Du was plattformunabhängiges suchst, kann ich nur die HtmlEditorLibrary empfehlen,
Das kann fast alles, was HTML+CSS auch kann, und Du bist dann gleich auf modernem HTML, wenn es mal für was anderes gebraucht ist.
TRichViewEdit is auch super, aber nur VCL.

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1531688)

Im FMX geht es mit den hauseigenen Komponenten eh nur über die LiveBindings.
DB-aware Komponenten, wie man sie von der VCL kennt, sind dort out.

Oh Ja!
Man kann FMX sehr gut ohne Livebindings benutzen und das habe ich auch so gemacht.
Aber die DB Anzeige, Manipulation und Navigation muss man dann selber programmieren,
was aber kein Beinbruch ist, denn Firemonkey ist ein wirklich Komfortables werkzeug.

Allerdings bin ich auch irgendwie ein Fanboy was viele Dinge in bezug auf FMX angeht!
Außerdem bedeutet das Nutzen von FMX und das Verzichten auf VCL und native Windows32 Komponenten,
dass wir Microsofts Philosophie was native Oberflächen betrifft folgen.
Quote von Bard

Zitat:

Ab der Version Office 2013 verwendet Microsoft Office keine nativen Windows-Komponenten mehr. Die vorherige Version, Office 2010, verwendete noch einige native Windows-Komponenten, wie z. B. das Dialogfeld "Drucken" und die Symbolleiste "Standard". In Office 2013 wurden diese Komponenten durch eigene, von Microsoft entwickelte Komponenten ersetzt.

Der Grund für diese Umstellung war, dass Microsoft Office eine einheitliche Benutzeroberfläche für alle Plattformen bieten wollte. Dazu musste Microsoft die Abhängigkeit von nativen Windows-Komponenten aufgeben, die sich von Plattform zu Plattform unterscheiden.

[Phoenix]

Zitat:

Zitat von QuickAndDirty (Beitrag 1531757)

Außerdem bedeutet das Nutzen von FMX und das Verzichten auf VCL und native Windows32 Komponenten,
dass wir Microsofts Philosophie was native Oberflächen betrifft folgen.
Quote von Bard

Zitat:

Ab der Version Office 2013 verwendet Microsoft Office keine nativen Windows-Komponenten mehr. Die vorherige Version, Office 2010, verwendete noch einige native Windows-Komponenten, wie z. B. das Dialogfeld "Drucken" und die Symbolleiste "Standard". In Office 2013 wurden diese Komponenten durch eigene, von Microsoft entwickelte Komponenten ersetzt.

Der Grund für diese Umstellung war, dass Microsoft Office eine einheitliche Benutzeroberfläche für alle Plattformen bieten wollte. Dazu musste Microsoft die Abhängigkeit von nativen Windows-Komponenten aufgeben, die sich von Plattform zu Plattform unterscheiden.

Puh, diese Aussage so zu interpretieren ist... zumindest gewagt.

Die einheitliche Benutzeroberfläche für alle Plattformen ist "Web". Das ist alles HTML+CSS + JavaScript bzw. in großen Teilen TypeScript.
Kurzum, wenn Du Microsofts Philosophie folgen willst, baust Du Web-basierte Applikationen. Und ganz sicher nicht FMX oder ähnlichen Quatsch (Xamarin Forms, React Native, Avalon etc. pp.).

[Mavarik]

Zitat:

Zitat von jik (Beitrag 1531697)

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

Ganz einfach...

Die Style-Animationen in FMX werden über "Timer" gelöst. Diese laufen nur, wenn die Ausführung in der Application-Loop läuft.

Wenn Du also - damit der User nicht 2x auf einen Button klickt - den Button disablen willst, wird es erst dargestellt, wenn die Ausführung wieder in Application-Loop läuft.

Im OnClick

• Button disablen
• Thread starten
• Am Ende von Thread eine Queue-Proc und darin den Button wieder enablen.

Oder einfach den Idleworker aus meinem FDK verwenden.

Wenn der Application.OnIdle event feuert, ist alles auf dem Bildschirm gemalt und Du kannst andere Sachen machen.

Mavarik

PS.: Nicht so "tragisch" auf FMX_Windows.

[Kas Ob.]

Zitat:

Zitat von Rollo62 (Beitrag 1531749)

TRichViewEdit is auch super, aber nur VCL.

Just updating your information, TRichView does support them all with Delphi ! (for over a year now)
https://www.trichview.com/features/trichview.html

Code:

Supported FireMonkey platforms: Windows (Delphi XE6 and newer), 64-bit macOS (Delphi 10.3 and newer), Android (Delphi 10.4 and newer), 64-bit Linux (Delphi 10.3 and newer + FMXLinux v1.76 and newer), 64-bit iOS devices (Delphi 10.4 and newer), 64-bit ARM iOS simulator (Delphi 11 and newer)

[Rollo62]

Zitat:

Zitat von Kas Ob. (Beitrag 1531770)

Just updating your information, TRichView does support them all with Delphi ! (for over a year now)

Well, that's great news.
I wasn't aware of this, used TRichView many years ago, in an BCB5 C++ project.
Good to know that FMX is on the roadmap of many important components.

[TurboMagic]

Zitat:

Zitat von jaenicke (Beitrag 1531691)

Zitat:

Zitat von TuPas (Beitrag 1531687)

Mir fehlen für eine komfortable Cross-Entwicklung die Datenbankunterstützungen bei Eingabe-Elemente und Grids.

Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt. Insofern vermisse ich diese auch nicht bei FMX. Dort gibt es dafür aber auch Databinding, wenn man es denn unbedingt nutzen möchte.

Eine wirklich gute Gridkomponente vermisse ich aber bei FMX wirklich sehr. Da kommt man um einen Kauf einer guten Komponente nicht herum, wenn man diese benötigt. Mir gefällt die von TMS schon gut:
https://www.tmssoftware.com/site/tmsfncuipack-grid.asp
Aber für eine plattformübergreifende TVirtualStringTree mit auch nur annähernd der Funktionalität der VCL Version wäre ich bereit einiges zu zahlen (und ich denke einige andere auch).

Für das VST gibt's dort im Bugtracker eine Diskussion. Da wollte mal jemand was machen.
Details siehe dort.

[DieDolly]

// OT //

Ich habe leider nichts zum Thema beinzutragen, aber zu deinem Programm und der Webseite. Ist auch hilfreich.
Zumindest im neuen Mozilla-Browser gibt es sehr viele Fehler wie "Content-Security-Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf https://autorenprogramm.com/wp-conte...n.js?ver=3.5.4 blockiert ("script-src").".
Das hat u.a. zur Folge, dass in der Mobile-Ansicht das Hamburger-Menu nicht aufklappt.

[jik]

Hallo DieDolly,
bin eben die Seite durchgegangen mit dem aktuellsten Firefox, kann aber keinen Fehler finden. Kann es sein, dass das an deinem Gerät liegt ...?
Viele Grüße
Martin

[jaenicke]

Bei mir gibt es weder diese Fehler in der Konsole noch ein Problem mit dem Hamburgermenü unter Android mit Firefox oder Chrome.

[Rollo62]

Zitat:

Zitat von jaenicke (Beitrag 1531691)

Eine wirklich gute Gridkomponente vermisse ich aber bei FMX wirklich sehr.

Ich habe mir vor kurzem die Steema TeeGrid Komponente angeschafft.
Die scheint alles das zu haben, was ich brauche und ist nicht gleich so ein DevExpress oder TMS Monster.
Ich teste noch, bin aber bis jetzt schon überaus zufrieden damit, denn das füllt genau die Lücke zwischen TStringGrid und TMS/DevExpress.

Die würde ich auf jeden Fall empfehlen, auch weil die Anschaffung preislich keine große Hürde darstellt.

[jik]

Zitat:

Zitat von Rollo62 (Beitrag 1531811)

Ich habe mir vor kurzem die Steema TeeGrid Komponente angeschafft.
Die scheint alles das zu haben, was ich brauche und ist nicht gleich so ein DevExpress oder TMS Monster.

Danke für den Hinweis. Darf ich dich gleich was fragen?
1. Zwar scheint das Grid auch Unterknoten haben zu können, aber nur eine oder mehrere Ebenen? EDIT: scheints sie auch zu können
2. Grafiken im Header möglich?
3. Spalten mit Checkboxen und/oder Grafiken möglich?
4. Weil VCL dabeisteht: Plattformübergreifend ...? EDIT: Habs schon gesehen: ja

[Rollo62]

Zitat:

Zitat von jik (Beitrag 1531813)

Danke für den Hinweis. Darf ich dich gleich was fragen?
1. Zwar scheint das Grid auch Unterknoten haben zu können, aber nur eine oder mehrere Ebenen? EDIT: scheints sie auch zu können
2. Grafiken im Header möglich?
3. Spalten mit Checkboxen und/oder Grafiken möglich?
4. Weil VCL dabeisteht: Plattformübergreifend ...? EDIT: Habs schon gesehen: ja

Ich hab extra nochmal reingeschaut.
1. Es gibt anscheinend nur bis zu 1 Level SubColumns zu haben. Es gibt verschiedene Master-Detail und SubBands Beisiele, die aber noch nicht alle aktuell hier funktionieren.
Ich weiß auch nicht, warum die nicht einfach alles mit Sqlite oder anderen Daten machen, warum ODBC?
Sowas nervt, wenn die Demos nicht out-of-the-box laufen.
2. Grafiken im Header sehe ich keine Möglichkeit, es gibt viele Farb- Font usw, aber Bitmaps oder dergleichen im Header scheinen zu fehlen.
3. Ja, es gibt Checkbox und auch auch eins mit TeeCharts in den Spalten. Das habe ich mal auf bis 10000 Zeilen hochgezogen und viel mehr Stützpunkte, das war noch recht flott.
Also werden Grafiken auch ohne Probleme laufen, wenn es nicht gerade 15MB Images sind.
Prinzipiell ist es so umgesetzt:

Delphi-Quellcode:

procedure TFormCellEditors.SetupCustomEditors;
begin
  // Custom cell editor controls (default is TEdit):

  TeeGrid1.Columns['Height'].EditorClass:=TTrackBar;

  TeeGrid1.Columns['BirthDate'].EditorClass:=TDateEdit;

  TeeGrid1.Columns['Vehicle'].EditorClass:=TComboBox;

  TeeGrid1.Columns['EyeColor'].EditorClass:=TComboColorBox;

  TeeGrid1.Columns['Holidays'].EditorClass:=TCheckBox;

  TeeGrid1.Columns['Happiness'].EditorClass:=TNumberBox;
end;

Man kann anscheinend ziemlich beliebige Komponenten da reinwerfen, habe ich aber noch nicht weiter getestet.

Ich brauche das für kleine, Spreadsheet-ähnliche Ausgaben, wo ein StringGrid zu simpel ist.
Genau da passt es gut rein.
Es ist auch ein Spreadsheet-Sample dabei, allerdings nutzt das TeeBI Expressions dafür, welche wohl nicht im Paket dabei sind.
Hab ich noch nicht gecheckt wofür das gut ist, kaufen kann man das anscheinend nicht direkt.
Muss ich mich mal näher mit beschäftigen, es scheint aber nur ein paar Formel-Expression Klassen zu sein, so wird es zumindest im Example benutzt.

[Redeemer]

Zitat:

Zitat von Mavarik (Beitrag 1531692)

Zitat:

Zitat von jik (Beitrag 1531657)

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Nein - D5 ist gruselig wenn wenigstens D2007 - aber was willst Du mit den alten Zeug?

Was ist denn bei D2007 so toll? D2009 ist mit Unicode und Generics meiner Meinung nach die bedeutendste Version von VCL-Delphi.

[himitsu]

Genau das ist es ja.

2006/2007 als die letzten Versionen ohne Unicode, für den (ersten) Upgrade von noch viel älteren Versionen.

[IBExpert]

Zitat:

Zitat von jik (Beitrag 1531729)

Noch bin ich mir immer noch nicht ganz sicher, ob es Lazarus oder Delphi 12 wird - auch wenn von vielen Lazarus als Hobbytool gesehen wird. Die Tendenz, mal abzustürzen kommt mir bei Lazarus tatsächlich etwas größer vor.

Aus meiner Sicht: Ich arbeite in einem Kundenprojekt seit ca 11 Jahren mit Lazarus, der Lazarus Code hat zwar relativ wenig statische Formulare, weil ich mir schon sehr lange auch in alle Delphi Projekten angewöhnt hatte, alles was geht per code zur Laufzeit zu erzeugen und würde das auch nie wieder anders machen wollen. Das Hauptprojekt hat ca 30000 Zeilen quellcode, den ich selber geschrieben hab.

dbcontrols gibt es bei mir nicht sondern eine über lange jahre selber gebaute Klassenarchitektur, die alles relevante von der db in den Speicher holt, wenn es nicht eh gleich in der db weiterverarbeitet werden soll und wenn was angezeigt werden soll, dann eben ohne den datasource kram damit controls auf dem Bildschirm füllt, damit der anwender das sieht und je nach control auch bearbeiten kann.

Speichern geht dann umgekehrt genau so. Ich hab einige Ideeen in der GUI, die ich früher immer zwangsweise mit Fremdkomponenten gemacht hätte, mittlerweile komplett selber in vorhandene Komponenten integriert oder teilweise auch ganz simple code routine erstellt, die das da auf den screen in scrollboxen komponentenweise erzeugt, was sich aus den daten der datenbank ergibt.

Da eh alles zur laufzeit erzeugt wird, braucht mein code den ganzen overhead nicht, das ich irgendwo in der GUI mir dann zur Entwicklungszeit hinklicken kann und mit pseudodaten wie in treeviews oder sogar mit echtdaten in grids anschauen kann, das interessiert mich nicht. Beim debuggen hoppelt der nicht ständig durch irgendwelche mir unbekannten und unwichtigen Komponentenevents, sondern geht zeile für zeile durch meinen eigenen code.

Mir reicht zu wissen, an der position x ist eine scrollbox, wo der ganze kram dann hinkommt, den ich brauche. Das sind dadurch bei mir zum beispiel panels, labels, edits, checkboxen oder sonstwas für ein kram ich da haben will und die zusammenstellung übernimmmt dann eine sehr einfache beschreibungssprache, die meine stored procedures dann in der datenbank dafür zusammenbaut.
ab 10000 Komponenten musst du ein wenig vorsichtiger werden, aber das lernt man dann schnell, zu optimieren.

Das wird zum Beispiel auch für industrielle Kapazitätsplanung benutzt, bei der horizontal die werktage spalten abbilden, vertikal gruppiert maschine/arbeitsgang usw in teilweise extra spalten kommen, je nach sicht (bzw je nach implementation der sp) und je nach daten kommen dann noch zeilweise extra spalten mit details, die man nur bei bestimmten abrufaufträgen sehen muss, aber nicht immer.

Ich hatte mir aus tradition den wolf gesucht nach brauchbaren Grids oder treeview ähnlichen Komponenten und alleine um zu bewerten, ob die meinen Vorstellungen entsprechen können, diverse stunden oder gar Tage meines Lebens damit verplempert. Am Ende ist es sogar so, das teilweise mein Kunde sich die mühe macht, eine Sicht was er gerne sehen möchte, in excel manuell zusammenklöppelt und ich mir das anschau, um das direkt umzusetzen.

war nie ein Problem, hier und da mal extra neuer code weil auf bestimmten komponenten extra hints anzeigen zeigen, klicks darauf bestimmte aktionen oder redirects machen sollte, farben zellenweise passend sein müssen, auslastungen mit mini extra linie dargestellt werden usw. Manchmal zeigte er mir Funktionen, die er aus anderer Software kannte und gut fand und wenn ich die dann auch gut fand, oft schneller als ich selber dachte in meinen code integrierte, ohne irgendjemand fragen zu müssen, ob der das irgendwie in seine eh schon zu komplizierten Komponenten einzubauen.

Das Projekt lief ca 3-4 Jahre als reine win32 Anwendung und anfänglich war lazarus schon wirklich einigermaßen instabil, hat aber bis heute den vorteil, das es im vergleich zu Delphi sauschnell startet. Seit mindestens 5 Jahren ist die lazarus IDE aber sehr stabil und lass dich nicht abschrecken von irgendwelchen "Oppa erzählt vom Krieg ...." Berichten von Leuten, die vor x Jahren das mal 10 minuten probiert hatten und scheisse finden, weil instabil. stimmt nicht!

Ich hatte dann mal aus neugier den Crosscompile auf win64 gemacht und das ganz in der win64 IDE geladen (die es bis heute von delphi ja nicht gibt) und das lief ohne jede sourcecode Änderung. Ein Mac hatte ich eh noch rumliegen, lazarus installiert und auch da dann den Quellcode ausprobiert, dabei ergaben sich ein paar visuelle dinge, die aber schnell beidseitig für win und mac in den code gingen und schon lief das auch da ohne Einschränkung. Nun stand noch Linux auf dem Plan und siehe da, lazarus IDE auf Ubuntu lief der Quellcode dann auch sofort. Es gab damals auch crosscompile varianten für mobiles, das halte ich aber bis heute für begrenzt relevant, weil auf mobile devices mach ich immer alles als Webapplikation (und zwar mit pas2js oder komplexeren kram mit tms webcore, was beides mit lazarus funktioniert) und hab keine Lust warum man binaries an die appstores verteilen sollte um die dann irgendwann aufgrund von deren Restriktionen nicht mehr einsetzbar zu haben oder von vornherein abgelehnt werden, was man aber erst einige tage nach upload erfährt.

Und ganz nebenbei: versuch mal mit jemand der Ahnung von der Materie Delphi IDE Sourcecode hat, im Delphi Umfeld in Kontakt zu kommen, der 1. deinen reproduzierbaren Fehler versteht und 2. diesen dann auch noch selber vor deinen Augen im Debug Modus mit der IDE nachzuvollziehen kann , um dann relativ schnell einen möglichen Bugfix zu diskutieren, der dann oft schon am selben abend im trunc umgesetzt ist. Passierte mir mit Michael von Canneyt und Mathias Gärtner schon auf diversen Lazarus Konferenzen.

Früher gab es solche Namen auch im Delphi Umfeld, die man in USA auf Konferenzen treffen konnte, das war aber im letzten Jahretausend. Mir ist da kein einziger mehr bekannt, der da nicht nur als Tempeltänzer wie Jim McKeeth auf seinen sessions irgendwie scheinbar selber keinen Zugriff auf die IDE Sourcen hat. Nun denn, er ist ja auch schon geschichte bei emba, wie so viele ...

Ich für mein Teil betrachte Lazarus definitiv nicht als "Hobbytool", weil ich damit sicherlich schon einige tausend stunden selber gearbeitet habe und da zu sehr guten Stundenlöhnen. Und wenn du in anderen Foren fragst ist ja auch Delphi nur Hobbykram ... Ist beides de fakto mumpitz aus meiner sicht ...

[dummzeuch]

Zitat:

Zitat von Redeemer (Beitrag 1531823)

Zitat:

Zitat von Mavarik (Beitrag 1531692)

Zitat:

Zitat von jik (Beitrag 1531657)

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Nein - D5 ist gruselig wenn wenigstens D2007 - aber was willst Du mit den alten Zeug?

Was ist denn bei D2007 so toll? D2009 ist mit Unicode und Generics meiner Meinung nach die bedeutendste Version von VCL-Delphi.

D2007 ist sehr stabil, was man von Delphi 2009 und diversen späteren Versionen meiner Erfahrung nach nicht behaupten kann. Und "kein Unicode" heißt für viele schlichtweg "Strings sind einfacher". Ich habe noch diverse Projekte in Delphi 2007 und viele davon werde ich vermutlich auch nie updaten.
Aber da mögen Erfahrungen abweichen, je nachdem welche Art von Programmen man schreibt, und es ist auch nicht wirklich das Thema hier.