VCL vs. FMX - Die Frage ist (vorerst) offiziell beantwortet

[Codehunter]

Ich hoffe, der Glaubenskrieg hat mit diesem Post von Jim McKeeth ein Ende. Beide Frameworks sind da und bleiben da. Die VCL ist NICHT deprecated, wie oft gesagt wurde. VCL ist Windows only, FMX ist Cross-Platform. Somit entscheidet letztendlich der Markt, welche Plattform für welchen Anwendungsbereich am besten ist.

McKeeth scheint sich der Stärken und Schwächen beider Frameworks durchaus bewusst zu sein und spricht sie zwischen den Zeilen auch an. Man muss es nur aufmerksam lesen. Interessant fand ich den Hinweis auf TFiremonkeyContainer, kannte ich noch nicht und ermöglicht zumindest unter Windows ein Crossover beider Frameworks im selben Programm.

Im Moment sehe ich Delphi eigentlich wieder auf einem guten Weg. Zum ersten Mal seit langer Zeit gibt es wieder eine kostenlose Edition und ein Bekenntnis zu beiden Frameworks. Was nun noch fehlt ist der Beweis dass die Weiterentwicklung von Delphi ohne Emba-Spanien funktioniert. Denn 10.1 Berlin stammte ja noch überwiegend von dort.

[Sherlock]

Es gab echt einen Glaubenskrieg? Der muss aber sehr einseitig geführt worden sein. FMX ist noch Lichtjahre von VCL entfernt. Der einzige Vorteil ist die Verfügbarkeit für mehrere OSe, das wars dann aber auch.

Sherlock

[Codehunter]

Der Glaubenskrieg besteht ja hauptsächlich in der Annahme, Embadera würde langfristig eines der beiden Frameworks fallen lassen. Der Blogpost greift eine Frage auf, die sehr oft gestellt wurde: "Wenn ich ein neues Projekt starte, sollte ich dabei auf VCL oder auf FMX setzen?" Diese Frage war vor dem Hintergrund der Zukunftsfähigkeit der beiden Frameworks durchaus berechtigt.

[himitsu]

FMX hat paar nette "Layout"-Komponenten, welche man hätte gern auch in der VCL einbauen können, wenn man sie schon neu erfindet. :cry:

Vorallem die Komponentenentwickler wurden anfangs ganz schon er-/abgeschreckt, da man dort jedes Jahr intern massenhaft komplett umgebaut hatte und dann ständig nix mehr funktionierte, bei einigen Fremdkomponenten.

[Aviator]

Also ich bleibe nach wie vor bei der VCL. Wir hatten uns ja schonmal per PN darüber unterhalten @CodeHunter. :wink: Gerade erst ein neues Projekt damit angefangen. Eigentlich ein bestehendes, aber das wird komplett neu aufgebaut.

Hat zwar nicht direkt was mit dem Thema zu tun, aber wichtiger wäre mir eine Verbesserung der Sprache an manchen Stellen. In der Umfrage vom letzten Jahr gab es ja auch einen Punkt den man anwählen konnte wenn man Verbesserungen der Sprache für sinnvoll hält. Sowas wie der ?: Operator in C# oder Object?.Property in C# 6.0 ist sehr interessant. Dann würden die ganzen

Delphi-Quellcode:

if Assigned(Object)

Dinger wegfallen.

Aber genug OT jetzt. :)

[Codehunter]

Entscheidend ist, wo man mit seinem Projekt hin will. Wenn sich alles auf Windows abspielt gibt es keinen Grund, FMX zu verwenden. Umgekehrt wenn man auf Mobile will, kann man VCL nicht verwenden. Von einem Universalframework ist FMX weit entfernt. Darum die Wahl des Thread-Titels: Die Frage ist im Grunde beantwortet.

[himitsu]

Es kommt auch auf die Umgebung an.

Da FMX vieles selber zeichnet und keine/wenige nativen Windows-Controls verwendet werden, da gibt es dann ein paar Problemchen mit Fremdprogrammen, die auf die GUI zugreifen müssen,
also vorallem Screenreader für Blinde und Sehbehinderte oder sonstige Vorlese-/Auswertung-/Fernsteuerungsfunktionen.

[mkinzler]

Zitat:

also vorallem Screenreader für Blinde und Sehbehinderte oder sonstige Vorlese-/Auswertung-/Fernsteuerungsfunktionen.

Hierfür gibt es aber eine Lösung: http://cc.embarcadero.com/item/30521
(Zumindest für Update 0; vielleicht auch für Update 1)

[Bambini]

Zitat:

Zitat von himitsu (Beitrag 1350601)

FMX hat paar nette "Layout"-Komponenten, welche man hätte gern auch in der VCL einbauen können, wenn man sie schon neu erfindet. :cry

Statt dessen gibt es bald so etwas: http://blog.marcocantu.com/blog/2016...r-control.html

Bin mir nicht im Klaren, was Emba mit solchen Controls will. Das gibt es bestimmt schon bei DevExpress, TMS oder anderen 3rd parties.
Nun ja, wenn man sich die Geschichte vom Emba-Ribbon-Control anschaut, sollte man doch gelernt haben.
Schon alleine für einen Frieden mit den 3rd Party Tool Herstellern.
Delphi hat genügend Baustellen die nur Emba bedienen kann, solche Controls gehören bestimmt nicht dazu.

[Bambini]

Zitat:

Zitat von Codehunter (Beitrag 1350609)

Von einem Universalframework ist FMX weit entfernt. Darum die Wahl des Thread-Titels: Die Frage ist im Grunde beantwortet.

Wenn die Frage schon entschieden ist, warum baut Emba die ganzen Jahre am falschen Framework?

[Lemmy]

Zitat:

Zitat von Bambini (Beitrag 1350639)

Nun ja, wenn man sich die Geschichte vom Emba-Ribbon-Control anschaut, sollte man doch gelernt haben.

Wie meinst Du das?

[Bambini]

Zitat:

Zitat von Lemmy (Beitrag 1350641)

Zitat:

Zitat von Bambini (Beitrag 1350639)

Nun ja, wenn man sich die Geschichte vom Emba-Ribbon-Control anschaut, sollte man doch gelernt haben.

Wie meinst Du das?

Das gibt es nicht mehr, es wurde einfach mal eingestellt :thumb:
Was man jetzt per GetIT Package bekommt ist ein ganz anderes Ribbon Control.

[mkinzler]

Dort findet man beide Ribbon Frameworks

[Bambini]

Zitat:

Zitat von mkinzler (Beitrag 1350646)

Dort findet man beide Ribbon Frameworks

Ok, sorry. Hätte jetzt schwören können, dass es die Emba Version, bei meiner letzten Suche noch nicht gab.

[himitsu]

Dass die Ribbons einzeln sind, ist schon OK.
Immerhin hätte man sich eigentlich erst von Windows 'ne Lizenz besorgen müssen, bevor man sie im Programm verwenden darf, aber man konnte es ja einfach so draufklicken.

Zitat:

Zitat von Bambini (Beitrag 1350639)

Zitat:

Zitat von himitsu (Beitrag 1350601)

FMX hat paar nette "Layout"-Komponenten, welche man hätte gern auch in der VCL einbauen können, wenn man sie schon neu erfindet. :cry

Statt dessen gibt es bald so etwas: http://blog.marcocantu.com/blog/2016...r-control.html

Ich meinte mehr sowas wie TLayout, also zum "anordnen" von Komponenten, in einem bestimmten Layout. (nicht das Design der Komponenten)
Und wenn man schon sowas neu erfindet, dann doch bitte in beiden Frameworks gleich benamen und vom Verhalten/Bedienung ähnlich gestalten.

[Lemmy]

Zitat:

Zitat von Bambini (Beitrag 1350644)

Das gibt es nicht mehr, es wurde einfach mal eingestellt :thumb:
Was man jetzt per GetIT Package bekommt ist ein ganz anderes Ribbon Control.

und was genau hat Embarcadero damit zu tun, dass Microsoft die Lizenzierung der Controls durch Entwickler zurück zieht? Embarcadero scheint daraus gelernt zu haben: Die neuen Komponenten basieren nicht mehr auf den Microsoft Komponenten sondern sind eigene Nachbauten.

[Bambini]

Zitat:

Zitat von Lemmy (Beitrag 1350662)

und was genau hat Embarcadero damit zu tun, dass Microsoft die Lizenzierung der Controls durch Entwickler zurück zieht? Embarcadero scheint daraus gelernt zu haben: Die neuen Komponenten basieren nicht mehr auf den Microsoft Komponenten sondern sind eigene Nachbauten.

Soweit ich das gesehen habe, waren die Emba Ribbon auch selbst gezeichnete Controls, sowie die DevExpress und TMS auch.
Nur die andere - via GetIt - verfügbare Komponente nutze die MS eigenen. Gefüttert mit den XML Daten.

[uligerhardt]

Zitat:

Zitat von Bambini (Beitrag 1350639)

Statt dessen gibt es bald so etwas: http://blog.marcocantu.com/blog/2016...r-control.html

Bin mir nicht im Klaren, was Emba mit solchen Controls will. Das gibt es bestimmt schon bei DevExpress, TMS oder anderen 3rd parties.
Nun ja, wenn man sich die Geschichte vom Emba-Ribbon-Control anschaut, sollte man doch gelernt haben.
Schon alleine für einen Frieden mit den 3rd Party Tool Herstellern.
Delphi hat genügend Baustellen die nur Emba bedienen kann, solche Controls gehören bestimmt nicht dazu.

+1. War auch mein erster Gedanke, als ich es gelesen habe.

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1350658)

Und wenn man schon sowas neu erfindet, dann doch bitte in beiden Frameworks gleich benamen und vom Verhalten/Bedienung ähnlich gestalten.

Was der Hauptgrund sein dürfte, weshalb kaum Projekte von VCL nach FMX portiert werden. Allein die Einarbeitungs-/Umlernphase für jahrelange Delphi-Entwickler ist schon ungünstig. Vielleicht war das Ganze auch anders rum gedacht, dass man Eclipse- oder AS-Entwickler zu Delphi locken wollte. Hat aber IMHO nicht wirklich geklappt.

Es macht einen ziemlichen Aufriss, die Zuweisungen umzubiegen. Am Ende dann hat man etwas, das in Usability dem VCL-Vorgänger nicht das Wasser reichen kann. Das hat für mich noch nie Sinn ergeben. Aber zumindest das WARUM dieser abweichenden Benennung kann ich nachvollziehen. Firemonkey ist halt ursprünglich von Leuten entwickelt worden, die aus der Dalvik-Szene kamen und sich mit Delphi nicht wirklich auskannten. Emba hätte aber gut daran getan, in der Anfangszeit nach der Übernahme eine Angleichung durchzuführen. Stattdessen hat man versucht, irgendeinen Mittelweg zu finden um die wenigen damals vorhandenen FMX-Projekte kompilierbar zu halten.

Zitat:

Zitat von Bambini (Beitrag 1350640)

Zitat:

Zitat von Codehunter (Beitrag 1350609)

Von einem Universalframework ist FMX weit entfernt. Darum die Wahl des Thread-Titels: Die Frage ist im Grunde beantwortet.

Wenn die Frage schon entschieden ist, warum baut Emba die ganzen Jahre am falschen Framework?

Ich habe nirgends gesagt, es wäre das falsche Framework. Ich habe nur gesagt, es wäre spezialisiert für mobile Anwendungen und die VCL auf anderen Gebieten überlegen.

Zitat:

Zitat von Lemmy (Beitrag 1350662)

Zitat:

Zitat von Bambini (Beitrag 1350644)

Das gibt es nicht mehr, es wurde einfach mal eingestellt :thumb:
Was man jetzt per GetIT Package bekommt ist ein ganz anderes Ribbon Control.

und was genau hat Embarcadero damit zu tun, dass Microsoft die Lizenzierung der Controls durch Entwickler zurück zieht? Embarcadero scheint daraus gelernt zu haben: Die neuen Komponenten basieren nicht mehr auf den Microsoft Komponenten sondern sind eigene Nachbauten.

Soweit ich das verstehe ist es ohnehin völlig egal, ob man Microsofts Controls einbindet oder auf eigenen Wegen ähnlich/gleich aussehende Controls baut. Microsoft sieht in Ribbons eine Art geschütztes Geschmacksmuster. Daher würde sich die MS-Lizenz auf jegliche Art von Ribbon-artigem Control erstrecken. So richtig durchsetzen konnte sich dieses Bedienkonzept außerhalb der MS-Office-Welt auch noch nicht, trotz mittlerweile fast 10 Jahren seit es Office 2007 gibt. Bezeichnenderweise läuft VisualStudio bis heute im klassischen Menü-Toolbar-Design.

Mich stört daran weniger das neuartige Layout als mehr die Tatsache, dass einige Softwareanbieter ihren Produkten auf Gedeih und Verderb dieses neue Look&Feel überstülpen mussten ohne dabei auch das Bedienkonzept anzupassen. Während bei Office das halbe Frontend umgekrempelt wurde um häufig benutzte Funktionen aus den Tiefen diverser Menüs und Dialoge zu holen, hat man sich bei anderen Programmen darauf beschränkt, die vorhandenen Toolbars irgendwie in Ribbon-Tabs zu quetschen. Herausgekommen sind dabei unnütz verlängerte Klickpfade ohne Mehrwert für den Nutzer.

[Bambini]

Zitat:

Zitat von Codehunter (Beitrag 1350703)

Soweit ich das verstehe ist es ohnehin völlig egal, ob man Microsofts Controls einbindet oder auf eigenen Wegen ähnlich/gleich aussehende Controls baut. Microsoft sieht in Ribbons eine Art geschütztes Geschmacksmuster. Daher würde sich die MS-Lizenz auf jegliche Art von Ribbon-artigem Control erstrecken. So richtig durchsetzen konnte sich dieses Bedienkonzept außerhalb der MS-Office-Welt auch noch nicht, trotz mittlerweile fast 10 Jahren seit es Office 2007 gibt. Bezeichnenderweise läuft VisualStudio bis heute im klassischen Menü-Toolbar-Design.

Aber warum nimmt Emba das Ribbon aus der Standardinstallation? Die rechtlichen Fragen dazu sind für den Delphi Entwickler relevant, nicht für Emba.
Ich habe z.B. den Vertrag zu Nutzung der Ribbons mit MS damals (als es ihn noch gab) abgeschlossen. Also darf ich die auch nutzen.

Zitat:

Zitat von Codehunter (Beitrag 1350703)

Mich stört daran weniger das neuartige Layout als mehr die Tatsache, dass einige Softwareanbieter ihren Produkten auf Gedeih und Verderb dieses neue Look&Feel überstülpen mussten ohne dabei auch das Bedienkonzept anzupassen. Während bei Office das halbe Frontend umgekrempelt wurde um häufig benutzte Funktionen aus den Tiefen diverser Menüs und Dialoge zu holen, hat man sich bei anderen Programmen darauf beschränkt, die vorhandenen Toolbars irgendwie in Ribbon-Tabs zu quetschen. Herausgekommen sind dabei unnütz verlängerte Klickpfade ohne Mehrwert für den Nutzer.

Ob man will oder nicht, die Ribbons sind nun mal da, auch im Windows Dateiexplorer u.v.m.. Man gewöhnt sich an alles 8-)

[MEissing]

Zitat:

Zitat von Bambini (Beitrag 1350707)

Aber warum nimmt Emba das Ribbon aus der Standardinstallation? Die rechtlichen Fragen dazu sind für den Delphi Entwickler relevant, nicht für Emba.

Weil die ursprünglichen Ribbons nicht optimal waren/sind....

Da viele/einige/ausreichend_viele Kunden nachgefragt haben, sind diese im GetIt Package Manager wieder mit drin (Classic Ribbons)
Anhang 46023

[Sherlock]

Ganz kurzes OT, vorab schon ein mea culpa dafür:

Zitat:

Zitat von Bambini (Beitrag 1350707)

Ob man will oder nicht, die Ribbons sind nun mal da, auch im Windows Dateiexplorer u.v.m.. Man gewöhnt sich an alles 8-)

Es muss immer noch ein Entwickler die Ribbons ins Programm einbauen. Oder hast Du wirklich jede im Lieferumfang vorhandene Komponente in Deine Applikation verbaut, einfach weil sie da ist? :shock:

Ich habe mich erfolgreich den Ribbons verweigert. Und siehe da, Ribbons sind schon wieder passé.

Sherlock

[Codehunter]

Zitat:

Zitat von Bambini (Beitrag 1350707)

Ob man will oder nicht, die Ribbons sind nun mal da, auch im Windows Dateiexplorer u.v.m.. Man gewöhnt sich an alles 8-)

Wie gesagt, es geht nicht um das Vorhandensein von Ribbons sondern um eine zweckmäßige Umsetzung.

Ich habe inzwischen eine ganz andere UI-Philosophie für meine Datenbankprojekte entwickelt, die weder auf klassische Menü-Toolbar-Anordnung noch auf Ribbons setzt. Vielmehr sind die Oberflächen sehr minimalistisch, vergleichbar mit einigen Webbrowsern. Themengebiete werden in Tabs zusammengefasst, jeder Tab ist ein MDI-Fenster, es kann von jeder Aufgabe mehrere gleichberechtigte Instanzen geben. Funktionen sind immer nur dort verfügbar wo sie gebraucht werden, z.B. direkt am jeweiligen Datensatz. Assistenten-Fenster gibt es gar keine mehr, weil sich gezeigt hat dass die Leute mehr genervt davon sind als dass es sie unterstützt wenn sie sich durch einen mehrseitigen "Assi" klicken müssen.

Als ich die neue Version zum ersten Mal gezeigt habe waren die Nutzer regelrecht schockiert weil sämtliche Toolbars verschwunden waren. Es gab viel Geschrei und böse Worte. Nachdem sie eine Weile damit spielen konnten waren sie aber in mehreren Stufen zunächst skeptisch, dann nachdenklich, zurückhaltend, lobend, begeistert. Das hat sich über einige Monate hingezogen.

Entscheidend ist bei einem UI-Design, dass man sich als Entwickler hinsetzt und schaut wie die Leute in der Praxis damit arbeiten und wie man Abläufe effizienter gestalten kann. Das geht nur wenn man nah dran ist an der Praxis. Wenn man aber nur ein paar Controls umgestaltet damit die Oberfläche "anders" aussieht und den Upgrade-Preis allein dadurch rechtfertigen soll, das funktioniert nicht. Und genau das kritisiere ich an Microsoft seit längerem, sie basteln ständig am UI herum und gaukeln damit Innovation vor die tatsächlich gar nicht vorhanden ist weil die Leute hinterher eigentlich nur damit beschäftigt sind durch Nachkonfigurieren alles wieder zurück zu drehen.

[Bambini]

Zitat:

Zitat von MEissing (Beitrag 1350710)

Zitat:

Zitat von Bambini (Beitrag 1350707)

Aber warum nimmt Emba das Ribbon aus der Standardinstallation? Die rechtlichen Fragen dazu sind für den Delphi Entwickler relevant, nicht für Emba.

Weil die ursprünglichen Ribbons nicht optimal waren/sind....

Das hinterlässt immer einen sehr fahlen Nachgeschmack und dient nicht zur Vertrauensbildung von neuen Delphi Komponenten.

[Aviator]

Zitat:

Zitat von Sherlock (Beitrag 1350711)

Ich habe mich erfolgreich den Ribbons verweigert. Und siehe da, Ribbons sind schon wieder passé.

Muss mal kurz an das OT anknüpfen. Womit kannst du belegen, dass die Ribbons schon wieder passé sind? Es gab zwar nicht so viele Anwendungen mit Ribbons, aber ausgestorben sind die noch nicht so viel wie ich weiß.

[Bambini]

Zitat:

Zitat von Aviator (Beitrag 1350715)

Zitat:

Zitat von Sherlock (Beitrag 1350711)

Ich habe mich erfolgreich den Ribbons verweigert. Und siehe da, Ribbons sind schon wieder passé.

Muss mal kurz an das OT anknüpfen. Womit kannst du belegen, dass die Ribbons schon wieder passé sind? Es gab zwar nicht so viele Anwendungen mit Ribbons, aber ausgestorben sind die noch nicht so viel wie ich weiß.

... auch das Office für Mac hat das Ribbon nun.

[MEissing]

Zitat:

Zitat von Bambini (Beitrag 1350714)

Das hinterlässt immer einen sehr fahlen Nachgeschmack und dient nicht zur Vertrauensbildung von neuen Delphi Komponenten.

Jeder Entwickler kann prüfen, ob die ihm zur Verfügung gestellten Komponenten für ihn geeignet sind.
Dazu sollte jeder Entwickler aufgerufen sein. Dazu gibt es Testversionen.

[Sherlock]

Stimmt, Ms-Office lebt noch. Aber abgesehen von MS Produkten ist mir nichts bekannt. Zugegeben: Ich arbeite zu 75% auf MacOS und Raspbian. Sobald ich aber mal im Windows unterwegs bin, sehe ich auch keine Ribbons. Toolbars sind deutlich sinnvoller und flexibler. Und für Touch werden ListViews verwendet.

Sherlock

[bra]

Dann bist du nicht mehr viel mit Windows unterwegs. Gefühlt hat jedes zweite Programm, welches eine neue Oberfläche bekommt, inzwischen Ribbons.

[Bambini]

Zitat:

Zitat von MEissing (Beitrag 1350717)

Zitat:

Zitat von Bambini (Beitrag 1350714)

Das hinterlässt immer einen sehr fahlen Nachgeschmack und dient nicht zur Vertrauensbildung von neuen Delphi Komponenten.

Jeder Entwickler kann prüfen, ob die ihm zur Verfügung gestellten Komponenten für ihn geeignet sind.
Dazu sollte jeder Entwickler aufgerufen sein. Dazu gibt es Testversionen.

Klar, aber es scheint ja eine größere Fan-Gemeinde der Ribbons gegeben zu haben.
Keine Ahnung, was es da für Probleme gab, aber statt sie Probleme zu beheben, nimmt man die jetzt einfach raus?
Ähnlichen Schicksal wie: ReportSmith und RaveReport?
Warum hält sich Emba aus dem Controls-Bereich nicht ganz raus? Der Markt ist doch kompetent besetzt und kann sich wunderbar ergänzen.

[bra]

Zitat:

Zitat von Bambini (Beitrag 1350721)

Warum hält sich Emba aus dem Controls-Bereich nicht ganz raus? Der Markt ist doch kompetent besetzt und kann sich wunderbar ergänzen.

Weil die Controls von DevExpress, TMS und wie sie alle heißen alle extra kosten vielleicht?

[uligerhardt]

Zitat:

Zitat von Sherlock (Beitrag 1350718)

Sobald ich aber mal im Windows unterwegs bin, sehe ich auch keine Ribbons.

Also, ich seh z.B. welche im Explorer, Paint, WordPad. :shock:

[Bambini]

Zitat:

Zitat von bra (Beitrag 1350722)

Zitat:

Zitat von Bambini (Beitrag 1350721)

Warum hält sich Emba aus dem Controls-Bereich nicht ganz raus? Der Markt ist doch kompetent besetzt und kann sich wunderbar ergänzen.

Weil die Controls von DevExpress, TMS und wie sie alle heißen alle extra kosten vielleicht?

... das hat sich vielleicht auch bald erledigt, wenn Emba mit Raize & Co weiter in diesem Bereich aufrüsten und alles "kostenlos" in den Sack werfen.
Dann wird vielleicht der allerletzte Menu-Eintrag "VCL", auf der DevExpress Seite ganz verschwunden sein :?
Ich kann mir nur wünschen, das Emba sich auf seine Aufgaben konzentriert, die kein anderer machen kann: IDE, RTL, VCL, FMX und Compiler.
Den Rest machen die anderen, meist viel besser.

[Codehunter]

Zitat:

Zitat von uligerhardt (Beitrag 1350723)

Zitat:

Zitat von Sherlock (Beitrag 1350718)

Sobald ich aber mal im Windows unterwegs bin, sehe ich auch keine Ribbons.

Also, ich seh z.B. welche im Explorer, Paint, WordPad. :shock:

Ganz wichtig: Paint! Ohne das geht ja gar nix ;-)

Man sollte dazu sagen: Nicht-Microsoft-Programme. Gerüchten zufolge soll sich z.B. SmartFTP seinerzeit bei der Einführung eines Ribbon-UI den Kundenstamm glatt halbiert haben. Vorallem aber wegen des patzigen Supports zu dem Thema "Ist da und bleibt da. Basta." Genau dieses Programm sehe ich als Paradebeispiel dafür, dass das eigentliche Bedienkonzept das hinter Ribbons steht, nicht verstanden wurde. Dieses UI wirkt nicht rund, nicht stimmig sondern irgendwie planlos und drangeflanscht. Und genau so sollte m.E. ein UI niemals sein.

[MEissing]

Zitat:

Zitat von Bambini (Beitrag 1350721)

Klar, aber es scheint ja eine größere Fan-Gemeinde der Ribbons gegeben zu haben.

Echt? Von den Ribbons (aus Delphi 2009) habe ich nie was Gutes gehört.... die generelle Empfehlung hiess und heißt: Vermeiden.
Ich kenne kein Softwareprojekt, was diese (länger) eingesetzt hat.

Zitat:

Zitat von Bambini (Beitrag 1350721)

Keine Ahnung, was es da für Probleme gab, aber statt sie Probleme zu beheben, nimmt man die jetzt einfach raus?
Ähnlichen Schicksal wie: ReportSmith und RaveReport?
Warum hält sich Emba aus dem Controls-Bereich nicht ganz raus? Der Markt ist doch kompetent besetzt und kann sich wunderbar ergänzen.

Es gibt ja die Ribbons aus dem Turbopack. Gut. Brauchbar. Standardkonform. (zu finden über den GetIt Package Manager)

Oh ja... da war noch die Report-Geschichte.....
Wir haben in 21 Jahren den Reportgenerator 3 mal ausgetauscht.

• ReportSmith
• QuickReport
• RaveReports
• FastReport

Macht alle paar Jahre einen Austausch..... es gibt schlimmeres.... und deutliche größere, sich bewegende Ziele.

[Codehunter]

Zitat:

Zitat von MEissing (Beitrag 1350728)

Wir haben in 21 Jahren den Reportgenerator 3 mal ausgetauscht.

• ReportSmith
• QuickReport
• RaveReports
• FastReport

Ich wüsste ohnehin gern mal wonach da eigentlich entschieden wurde. Haben die jeweiligen Hersteller nicht mehr genug für den Platz an der Sonne bezahlt? Gab es technische Gründe?

[Bambini]

Zitat:

Zitat von MEissing (Beitrag 1350728)

Zitat:

Zitat von Bambini (Beitrag 1350721)

Klar, aber es scheint ja eine größere Fan-Gemeinde der Ribbons gegeben zu haben.

Echt? Von den Ribbons (aus Delphi 2009) habe ich nie was Gutes gehört.... die generelle Empfehlung hiess und heißt: Vermeiden.

Gibt es da auch noch weitere "Empfehlungen" für andere Delphi Komponenten?

[rokli]

Zitat:

Zitat von MEissing (Beitrag 1350728)

Wir haben in 21 Jahren den Reportgenerator 3 mal ausgetauscht.

• ReportSmith
• QuickReport
• RaveReports
• FastReport

Macht alle paar Jahre einen Austausch..... es gibt schlimmeres.... und deutliche größere, sich bewegende Ziele.

Da war QuickReport ganz ok und der 3. Austausch absolut der beste!

Gruß

[rokli]

@CodeHunter: Ich weiß ja, dass Du keine Screenshots machst, aber kannst Du mal so eine "aufgeräumte" UI zeigen?

[stahli]

... oder ein Video, da man das Handling besser nachvollziehen könnte (ich wollte auch schon fragen)