Plattformübergreifend - Augenauswischerei ...?

[jaenicke]

Zitat von jik:

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 von jik:

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 von jik:

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 von jik:

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 von jik:

6. Ein leistungsfähiges Ribbon

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

[dummzeuch]

Zitat von bernhard_LA:

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 von dummzeuch:

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 von jik:

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 von 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.

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 von QuickAndDirty:

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 von jik:

@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 von Rollo62:

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 von Kas Ob.:

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 von jaenicke:

Zitat von TuPas:

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.