iOS-Entwicklung mit Firemonkey (Delphi XE10)

[philver]

Hallo zusammen,

ich melde mich mit einem mehr oder weniger großem Anliegen bei euch. Es geht dabei nicht um eine spezielle Fragestellung als solches, sondern eher eine Art Informationsaustausch, vorzugsweise mit Personen die in diesem Bereich bereits Erfahrung haben.
Ich werde nachfolgend unser Unternehmen, unsere Zielgruppe und unsere Idee einer App und erste Gedanken zur Umsetzung beschreiben - ich hoffe, dass wir auf dieser Grundlage dann miteinander plaudern können 

Ich über uns: Wir sind ein Softwareunternehmen, das bisher nur native Windows-Anwendungen mit Delphi (VCL) entwickelt hat. Unsere Software wird hauptsächlich im industriellen Bereich zur Kalkulation und Optimierung von [alles was sich mischen lässt] (außer Karten) verwendet, aber auch wissenschaftliche Institute oder Universitäten finden sich im Anwenderkreis. Insofern war eine Ausrichtung zur mobilen Entwicklung nie ein großes Thema, da keine Nachfrage bestand.

Ich über mich: Ja, ich habe selbst mal das Programmieren mit Delphi gelernt, habe auch eine Ausbildung in diesem Bereich, programmiere aber selbst nicht mehr. Die gängigsten Fachwörter sollten mir also geläufig sein 

Problemstellung: Wie bereits erwähnt, nutzen unsere Kunden unsere Software um Berechnungen durchzuführen. Diese Berechnungen erfolgen ausschließlich für ihre eigenen Kunden. Am Ende jeder Berechnung steht dann folglich die Übergabe des Ergebnisses - kurz gesagt: Ergebnis wird auf Papier gedruckt oder als PDF gespeichert und per Mail versendet. Unser Meinung nach ein Zustand, der so nicht mehr sein muss.

Zielgruppe: Die Zielgruppe unserer App sollen also gar nicht unsere bereits bestehenden Kunden sein, sondern deren Kunden.
Die Idee: Wir erweitern unsere Windows-Anwendung um eine weitere Schnittstelle zum Export von „Ergebnissen“. Diese exportierten Dateien werden dann auf einen Server ins Internet geladen, die App lädt die Dateien herunter und zeigt diese an.

Klingt in der Theorie alles ganz einfach, praktisch ist es das aber nicht, wenn keine Erfahrung in diesem Bereich vorhanden ist. Und an dieser Stelle benötige ich ein paar Tipps von euch, wie ihr so etwas realisieren würdet. Natürlich habe ich mir schon Gedanken gemacht und würde wahrscheinlich auch zu einer Lösung kommen, aber ich hätte dann doch gerne das Gespräch mit Leuten, die sich auf diesem Gebiet auskennen oder diesen Weg bereits gegangen sind. Es wäre durchaus schon sinnvoll, wenn mir jemand nützliche Begrifflichkeiten, Empfehlungen oder Links nennen könnte.

Spezifische Fragen meinerseits könnten z.B. schon sein:
- Wir haben erst an die Übertragung von XML-Dateien gedacht. Ist das sinnvoll oder überhaupt ein guter Gedanke?
- Die Daten müssen verschlüsselt übertragen und gespeichert werden. Bietet iOS da intern eine Mechanik zur Verschlüsselung vor Übertragung an?
- Die Benutzer der App müssen sich irgendwie anmelden können. Gibt es da beispielsweise Serverlösungen, die diesen Part übernehmen können?
- Kann man überhaupt beliebig viele Dateien im Dateisystem mit seiner App speichern?

Jede Anmerkung und Frage ist sehr willkommen :)

[Mavarik]

Zitat:

Zitat von philver (Beitrag 1325501)

Spezifische Fragen meinerseits könnten z.B. schon sein:
- Wir haben erst an die Übertragung von XML-Dateien gedacht. Ist das sinnvoll oder überhaupt ein guter Gedanke?
- Die Daten müssen verschlüsselt übertragen und gespeichert werden. Bietet iOS da intern eine Mechanik zur Verschlüsselung vor Übertragung an?
- Die Benutzer der App müssen sich irgendwie anmelden können. Gibt es da beispielsweise Serverlösungen, die diesen Part übernehmen können?
- Kann man überhaupt beliebig viele Dateien im Dateisystem mit seiner App speichern?

- XML ist fein... Kleiner geht es mit JSON.
- SSH reicht Dir als Verschlüsselung?
- Serverlösungen gibt es sicherlich viele... Aber ich würde das immer selber machen.
- Beliebig viele Dateien ist ein sehr große Zahl... :stupid: Ich würde die Daten nach der Übertragung in eine SQLite Datenbank eintragen.

Mavarik

[Der schöne Günther]

Welche Seite soll diesen Server stellen? Ihr oder jeweils euer Kunde? Ich kann die Branche nicht einschätzen, aber in meinem Umfeld würde das nur schwer Akzeptanz finden. Wird denen nicht mulmig wenn diese "Berechnungen" quasi frei im Internet verfügbar sind?
Ich denke der Gedanke "Internet" war dass ihr diesen Service stellt und daran etwas verdient. Ich als euer Kunden würde das nicht mögen, sondern etwas erwarten dass ich in meinem internen Firmennetz aufsetzen kann. Dann könnt Ihr auch pleite gehen, und ich kann meinen Kunden trotzdem noch die Dinge hosten. Kann sein dass deine Branche anders tickt, aber bei mir würde beim Wort "Internet" schon die Ohren zugeklappt werden.

Grade da du nach Verschlüsselung "vor" der Übertragung, also auf dem Gerät, fragst ist das wohl nicht ganz so uninteressant. Von Embarcadero gibt es "IB (Interbase) Lite", das ist so eine Art SQLite für Windows, Mac OS X, Android und iOS und lässt sich, mittels Lizenz-Upgrade auf "Interbase To Go" upgraden das auch Verschlüsselung unterstützt. Damit kenne ich mich kein Stück aus und bin besser still.

Und das mit dem "Anmelden", sehe ich, spricht wohl auch für einen frei im Internet verfügbaren Server. Schau mal in die offizielle Embarcadero-Doku:
Übersicht über BaaS. Solche Anbieter sind eben diese Serverlösungen welche diesen Part (und mehr) übernehmen.

Ansonsten: Nicht vergessen die Limits von iOS-Geräten und was Apps dort dürfen im Auge zu behalten. Ich wüsste spontan nicht ob Delphi eine Airprint-Unterstützung hat oder ob man das wieder mit externen Komponenten zukaufen müsste.

[Pumuck18]

Hallo,

Eure Kunden haben als Ergebnis der Berechnung einige Daten vorliegen.
Diese kannst Du in ein XML oder JSON oder oder oder Datenpaket verpacken.(Schritt 1)
Aus diesem Datenpaket kannst Du wiederum mithilfe einer geeigneten Vorlage und eines Template Prozessors
ein Druckdokument, ein PDF oder ein HTML Dokument oder was auch immer erzeugen.(Schritt 2)
Dieses Dokument wird dann den Endkunden zur Verfügung gestellt, als Dokument per Mail, als Webseite o.ä.(Schritt 3)

Ich würde für Schritt 1 Delphi verwenden.
Für Schritt 2 und 3 würde Ich auf ein vorhandenes JAVA CMS zurückgreifen,
wie Liferay und Alfresco.
Dort bekommst Du Gruppen-, Rechte- und Benutzerverwaltung, Konverter und Scheduler "geschenkt", und mußt nur eine kleine
Portlet App schreiben, die den Endkunden die jeweiligen zur Verfügung stellt, und eine Administartionsoberfläche.

Der Aufwand, eine auf beliebigen Android- und IOS- Varianten gut aussehende und sauber funktionierende App zu schreiben,
ist nicht zu verachten, das mußten wir gerade am eigenen Leib erfahren.

Ich würde das als reine Weblösung bauen.
Bin mal gespannt welche Lösungsansätz die Anderen so haben :-)

Guten Rutsch

Tobias

[Der schöne Günther]

Zitat:

Zitat von Pumuck18 (Beitrag 1325521)

Ich würde das als reine Weblösung bauen.

Wäre auch meine Wahl, solange man die Möglichkeiten einer "richtigen" Anwendung garantiert nicht braucht. Beispielsweise Push-Benachrichtigungen bei neuen "Ergebnissen", mit einem Knopfdruck Bar/QR-Codes scannen und den passenden Datensatz laden, Offline-Verfügbarkeit (kein Empfang in Halle XY), ...

[Pumuck18]

Hallo Günther,
Die Offline Verfügbarkeit wäre natürlich ein KO-Kriterium,
das Einbinden von Barcode Scanns und Push Nachrichten
bekommt man inzwischen in Webseiten ja hin

[Sir Rufo]

Die Übertragung sollte man eh mit SSL (=> HTTPS) vornehmen.

Die Daten selber kann man auch auf dem Server (komprimiert und) verschlüsselt ablegen. In der Datenbank hat man dann eine Tabelle mit einem BLOB-Feld.

Bei der Auslieferung wird dieser Inhalt einfach als BASE64-kodierter Block ausgeliefert.

Code:

{
  "id": 1,
  "data": "<BASE64-DATEN>"
}

Der Client muss sich jetzt um die Entschlüsselung (und das Entpacken) kümmern. Auf dem Client selber kann man diese Daten so ablegen, wie man die erhalten hat (sind ja schon verschlüsselt).

[philver]

Hallo zusammen und vielen Dank für eure Beiträge :) Ich denke hier sind schon nun einige Begrifflichkeiten gefallen, mit denen ich etwas anfangen oder anhand dessen ich weiter recherchieren kann. Dankeschön dafür!

Zitat:

Zitat von Der schöne Günther (Beitrag 1325513)

Welche Seite soll diesen Server stellen? Ihr oder jeweils euer Kunde? Ich kann die Branche nicht einschätzen, aber in meinem Umfeld würde das nur schwer Akzeptanz finden. Wird denen nicht mulmig wenn diese "Berechnungen" quasi frei im Internet verfügbar sind?
Ich denke der Gedanke "Internet" war dass ihr diesen Service stellt und daran etwas verdient.

- Ich verstehe deinen Einwand und würde das in den meisten Fällen auch genau so sehen. Bei der geplanten App geht es allerdings nicht darum, Geld mit der App als solches zu verdienen. Die Ziele sind viel mehr: (1) Erfahrungen in der mobilen Entwicklung sammeln, (2) den bestehenden Kunden und der Konkurrenz zeigen, dass wir eben nicht nur Windows können und die mobile Entwicklung nicht fremd für uns ist und (3) unseren Kunden eine Verkaufshilfe für ihre Produkte zur Verfügung zu stellen - denn das ist der Grund, warum sie unser Produkt nutzen: Ihre eigenen Produkte verkaufen. - Nehmen wir beispielsweise an, dass ich ein Hersteller von Zusatzstoffen bin und unsere Software einsetze. Ich spreche mit meinem Kunden XY (Hersteller für Hundefutter oder ähnliches) über seine bisherige Zusammensetzung des Futters, tippe die genannte Zusammensetzung in unser Programm ein und schaue mir die Inhaltsstoffwerte an (in dem Beispiel die verwertbare Energie) und sage ihm "Mensch, würdest du unseren Zusatzstoff ABC mit in deine Zusammensetzung aufnehmen, würdest du viel bessere Werte erhalten und kannst dazu noch ein bisschen Geld sparen!".
- Die App soll also wirklich nur Zeitersparnis bei der Überlieferung von Ergebnissen von Kunden an Kundeskunden bieten und uns unsere Kunden damit noch weiter an unser Hauptprodukt binden.
- Es wäre folglich nicht mal ein Verlust, wenn eine solche Berechnung an Dritte gerät. Natürlich ist das aber von unserer Seite aus nicht gewollt - es muss schon differenziert werden, wer was mit der App sehen kann. Die Daten werden also exklusiv für einzelne Benutzer der App verteilt.
- Der Server soll auf unserer Seite stehen.

Zitat:

Zitat von Pumuck18 (Beitrag 1325521)

Ich würde das als reine Weblösung bauen.

- Vielen Dank für deine ausführliche Antwort! :) Ich hätte vorher erwähnen sollen, dass eine Webanwendung keinesfalls eine Lösung ist oder? :D Gründe dafür sind, dass die Zielgruppe unter Umständen nicht immer über eine bestehende Internetanbindung verfügt (deshalb meine Idee, die Dateien auf dem Gerät zu speichern) und unsere Konkurrenten Webanwendungen einsetzen - "keine Webanwendung, wie alle anderen" ist in unserem Falle Alleinstellungsmerkmal und Vorteil, aus Sicht der Kundschaft (die haben in der Vergangenheit glücklicherweise nicht so gute Erfahrungen damit gemacht). :)

Zitat:

Zitat von Sir Rufo (Beitrag 1325536)

Die Übertragung sollte man eh mit SSL (=> HTTPS) vornehmen.

Die Daten selber kann man auch auf dem Server (komprimiert und) verschlüsselt ablegen. In der Datenbank hat man dann eine Tabelle mit einem BLOB-Feld.

Der Client muss sich jetzt um die Entschlüsselung (und das Entpacken) kümmern. Auf dem Client selber kann man diese Daten so ablegen, wie man die erhalten hat (sind ja schon verschlüsselt).

- Hi Sir Rufo. Genau so habe ich mir das im Grunde vorgestellt. Die Dateien werden exportiert, komprimiert und verschlüsselt an den Server übertragen. Dort werden sie dann von "einem Dienst" in einer Datenbank verwaltet. Kunde XY kann dann mithilfe der App die ihm zugeordneten Dateien herunterladen, entschlüsseln und anschauen.

Ich hoffe ich konnte jetzt doch noch einen besseren Einblick verschaffen :) Bei Fragen stehe ich natürlich gern Rede und Antwort.

Guten Rutsch!

[Mavarik]

Zitat:

Zitat von Der schöne Günther (Beitrag 1325513)

Grade da du nach Verschlüsselung "vor" der Übertragung, also auf dem Gerät, fragst ist das wohl nicht ganz so uninteressant. Von Embarcadero gibt es "IB (Interbase) Lite", das ist so eine Art SQLite für Windows, Mac OS X, Android und iOS und lässt sich, mittels Lizenz-Upgrade auf "Interbase To Go" upgraden das auch Verschlüsselung unterstützt. Damit kenne ich mich kein Stück aus und bin besser still.

Wieso IB? SQLite kann auch verschlüsseln.

Zitat:

Zitat von Pumuck18 (Beitrag 1325521)

Ich würde das als reine Weblösung bauen.

Weblösungen werden doch mittlerweile als App-Ersatz nur noch belächelt. Nach dem Motto: Ach konnten die nicht Programmieren.

Zitat:

Zitat von philver (Beitrag 1325595)

- Vielen Dank für deine ausführliche Antwort! :) Ich hätte vorher erwähnen sollen, dass eine Webanwendung keinesfalls eine Lösung ist oder? :D Gründe dafür sind, dass die Zielgruppe unter Umständen nicht immer über eine bestehende Internetanbindung verfügt (deshalb meine Idee, die Dateien auf dem Gerät zu speichern) und unsere Konkurrenten Webanwendungen einsetzen - "keine Webanwendung, wie alle anderen" ist in unserem Falle Alleinstellungsmerkmal und Vorteil, aus Sicht der Kundschaft (die haben in der Vergangenheit glücklicherweise nicht so gute Erfahrungen damit gemacht). :)

So sehe ich das auch... Einer meiner Mitbewerber hatte auch so eine Serverlösung... Und alle haben Ihn ausgelacht...
Schnell mal ne Webseite zusammenklöppel ist eben keine App.

Mavarik

[Der schöne Günther]

Zitat:

Zitat von Mavarik (Beitrag 1325601)

Wieso IB? SQLite kann auch verschlüsseln.

Deshalb sagte ich "Damit kenne ich mich kein Stück aus und bin besser still.". Dass SQLite das auch hat wusste ich nicht.

Zitat:

Zitat von Mavarik (Beitrag 1325601)

Weblösungen werden doch mittlerweile als App-Ersatz nur noch belächelt. Nach dem Motto: Ach konnten die nicht Programmieren.

Das finde ich überhaupt nicht, ich bin jedes mal wieder richtig beindruckt wie gut richtige "Anwendungen" im Browser laufen. Egal ob Microsoft Office, Google Earth, Zeichensoftware draw.io oder was auch immer. Ich arbeite damit täglich. Nicht übersehen was in den letzten Jahren möglich geworden ist :warn:

[Mavarik]

Zitat:

Zitat von Der schöne Günther (Beitrag 1325611)

Das finde ich überhaupt nicht, ich bin jedes mal wieder richtig beindruckt wie gut richtige "Anwendungen" im Browser laufen. Egal ob Microsoft Office, Zeichensoftware draw.io oder was auch immer. Ich arbeite damit täglich. Nicht übersehen was in den letzten Jahren möglich geworden ist :warn:

Ok vielleicht war das von mir zu allgemein... Natürlich geht da viel... Aber 1-2 Forms die ein Ergebniss liefern ist noch keine WebApp. (Wir aber oft als solches "verkauft")

[Pumuck18]

Hallo Mavarik,

die Frage ist doch was Du willst.
Wenn Du eine Applikation mit jeder Menge Interaktivität,
Zugriff auf Gerätefunktionen wie Bluetooth, Sensoren, Kamera,
schnellem Feedback und lokalem Speicher bauen willst, baust Du eine App.
Da würde Ich dann aber drüber nachdenken, die jeweils für IOS und Android
seperat nativ zu programmieren.
Wir haben jetzt 2 Applikationen für Mobiltelefone und Tablets unter Delphi entwickelt,
und es war jeweils ein ziemliches Gekrebse, sobald man an die Systemdienste rangehen mußte.
Zum Teil sind die von Emba einfach ziemlich schlampig angekoppelt.
Und das WYSIWYG Versprechen hält auch nur bis zum ersten Deployment.

Wenn man in erster Linie nur Daten präsentieren will,
reicht meines Erachtens ein HTML5 Formular mit Javascript für die
meisten Anwendungsfälle aus.

Ich habe mich evtl mißverständlich ausgedrückt :
Ich hätte zwar eine Web-Applikation erstellt, die aber im Intranet laufen lassen.

Viele Grüße und Allen einen guten Rutsch

Tobias

[Peter666]

Kann ich nur allzu gut bestätigen. Eine Webanwendung, wobei das auch eine Delphi Anwendung sein kann, die auf einem Server läuft und Webseiten generiert, sollte man langfristig vorziehen. Das hat mehrere Gründe. Der wohl Schwerwiegendste ist, dass schnell mal Anpassungen bei einem OS Update notwendig werden. Hatten wir die Jahre ja andauernd. Mal gingen bestehende Apps unter Lollipop nicht mehr und letztens bei IOS. Solange man selber SaaS betreibt mag das egal sein, aber abgeschlossene Projekte warten zu müssen - wegen so etwas - ist gelinde gesagt für den Poppes.
Auch sind bei iOS die Wartezeiten bis zum Review unerträglich und unter Umständen muss man dann mehrfach Updates hochladen, weil bestimmte Design und/oder sonstige Entscheidungen gegen ein Veröffentlichen sprechen. So eine Webseite kann man schnell mal reparieren.

[philver]

Hallo zusammen und frohes neues Jahr!

Ich persönlich sehe meine ursprünglich genannte Idee nur als "Version 1" der App an - was damit passiert, nachdem sie Daten empfangen und anzeigen kann, ist noch komplett offen. Das ist auch der Grund, warum wir die Daten nicht als fertig-formatierte PDF-Datei übertragen wollen. Vielleicht soll der Benutzer dann auch die erhaltenen Daten bearbeiten und anschließend zurückschicken oder weiterleiten können; wer weiß. Und wie bereits erwähnt ist eine Webanwendung keine praktikable Lösung in unserem Fall :)

Zitat:

Zitat von Pumuck18 (Beitrag 1325659)

Da würde Ich dann aber drüber nachdenken, die jeweils für IOS und Android
seperat nativ zu programmieren.

- Genau das wäre auch unsere Idee. Ich bin wirklich kein Freund von Allumfassenden-Ultimativlösungen für jedes OS und erdenkliche Gerät - geht eh schief :P Android steht aber momentan nicht im Fokus. Die Nachfrage dafür ist auch gleich Null bei uns.

@Peter666
- Das mag sich jetzt vielleicht komisch anhören, aber darüber mache ich mir erstmal keine Gedanken. Auch mit einer Windows-Anwendung kannst du bei jedem Windows Update oder neuem Release schwerwiegende Probleme haben; das habe ich schon oft genug erlebt und das gehört dann einfach dazu. Und das mit dem "Ablehnen einer Veröffentlichung" im App Store sehe ich gar nicht mal als negativ an, denn ich finde es schon interessant vor dem Release zu wissen, was unter Umständen nicht korrekt ist. Zudem habe ich den Lerneffekt auch etwas im Fokus - unsere Leute sollen Erfahrungen sammeln und diese dann, vielleicht in späteren Projekten, umsetzen können.

Ganz davon ab: Der App Store ist einfach eine tolle Sache für uns, da wir unsere Produkte weltweit vermarkten. Wer sich nie damit beschäftigt hat, weiß vielleicht gar nicht was für ein riesiger Aufwand die Distribution von Software sein kann. Von Zahlungsabwicklung bis zur initialen Lieferung, Update-Auslieferungen und Installation.

[bra]

Zitat:

Zitat von philver (Beitrag 1326034)

@Peter666
- Das mag sich jetzt vielleicht komisch anhören, aber darüber mache ich mir erstmal keine Gedanken. Auch mit einer Windows-Anwendung kannst du bei jedem Windows Update oder neuem Release schwerwiegende Probleme haben; das habe ich schon oft genug erlebt und das gehört dann einfach dazu. Und das mit dem "Ablehnen einer Veröffentlichung" im App Store sehe ich gar nicht mal als negativ an, denn ich finde es schon interessant vor dem Release zu wissen, was unter Umständen nicht korrekt ist. Zudem habe ich den Lerneffekt auch etwas im Fokus - unsere Leute sollen Erfahrungen sammeln und diese dann, vielleicht in späteren Projekten, umsetzen können.

Das Problem hat man aber, wenn nach einem OS-Update die bereits im Appstore vorhandene App auf einmal nicht mehr funktioniert und man erst Tage/Wochenlang nach einer Lösung suchen muss und die Kunden die App solange nicht nutzen können. Das kann mit nativen Entwicklungstools zwar auch passieren, dann hat man aber i.d.R. schneller eine Lösung als bei Delphi, wo man ggf. erst mit dem nächsten Delphi-Update das Problem behoben bekommt.

Wir hatten dieses Problem jetzt schon zweimal, einmal bei Android 6 und einmal bei iOS 9. Bei Android ist das nicht ganz so brisant, weil es dort bisher ewig dauert, bis die neue Version für die verschiedenen Geräte überhaupt verfügbar ist. Bei Apple updaten die Kunden dagegen gleich innerhalb weniger Tage in Massen auf das neue OS.

[mkinzler]

Diesem Problem will man sich annehmen. Da darf man mal gespannt sein.

http://community.embarcadero.com/art...r-a-great-2016

Man wird in der Zukunft nicht um frühe Tests mit Vorabversionen der OS-Versionen herumkommen. Ich hoffe mal, dass Herr Atanas es genauso sieht.

[philver]

Hallo zusammen,

um noch mal auf meine eigentliche "Fragestellung" zurückzukommen: Ihr seht grundsätzlich erstmal kein schwerwiegendes Problem darin, iOS-Apps mit den von Embarcadero zur Verfügung gestellten Tools zu entwickeln, richtig? Oder würde jemand sagen, dass zwar mitgelieferte Komponente XY ganz nett ist, aber Dritthersteller ABC eine durchaus praktikablere Variante anbietet?

Würde mich wirklich mal interessieren, ob es sich lohnt, Geld in Komponenten von Drittherstellern zu investieren oder ob man erstmal die mitgelieferten Komponenten nutzen und sein Glück versuchen sollte. Vielen Dank!

[CHackbart]

Also im Prinzip ist die Entwicklung von Mobilanwendungen ziemlich gut in Delphi gelöst. Theoretisch kann man eine Desktopanwendung (sofern bestimmte Voraussetzungen erfüllt sind) mit nur 2 Klicks für IOS oder Android kompilieren. Über den Sinn lässt sich dahingehend streiten, aber es geht. Das funktioniert aber nur bedingt :) Anbei mal ein Screenshot einer Desktopanwendung auf einem Tablet. Auf dem iPad sieht das gleich aus, auf einem Telefon ist das ganze aber fast unbedienbar.

Übrigens nutze ich bei den meisten Projekten keine Thirdparty Komponenten.
Bis auf https://github.com/gmurt/KernowSoftwareFMX, denn diese Treeview/Slidemenu Lösung ist super performant und der von Embarcadero mitgelieferten vorzuziehen.
Der Verzicht auf extra Komponenten liegt schlicht daran, dass bei der Updatefrequenz von Delphi gefühlt ne Woche vergeht bis man alle nötigen Komponenten installiert hat.

Christian