Windows Messages in FMX ?!

[arnold mueller]

Zitat von Union:

Tut mir leid, mir erschließt sich der Sinn des Einsatzes nicht wenn man kein X plant. Liegt vielleicht auch daran dass ich damit Geld verdienen muss. Und meine Kunden müssen das auch.

Das trifft den Kern der Sache. Ich finde den Gedanken meine Anwendung tatsächlich für Windows und OSX verfügbar zu machen durchaus interessant und es würde wenn Linux noch hinzu kommt auch einen Wettbewerbsvorteil darstellen. Insofern wäre ich bereit Zeit und Geld in die Protierung zu Firemonkey zu investieren. Mit dem Austausch der Oberfläche könnte ich leben, da sich die Geschäftslogik nicht in den Formularen befindet. Wenn die Geschäftslogik aber ebenfalls neu geschrieben werden müsste, wird das Vorhaben zunehmend uninteressant.

Die Frage kam ziemlich zu Anfang auch im Workshop auf, wurde nach hinten gestellt und dann im Eifer des Gefechts vergessen

[Robotiker]

Zitat von arnold mueller:

Mit dem Austausch der Oberfläche könnte ich leben, da sich die Geschäftslogik nicht in den Formularen befindet. Wenn die Geschäftslogik aber ebenfalls neu geschrieben werden müsste, wird das Vorhaben zunehmend uninteressant.

In diesem Punkt hat sich bei dem neuen Crossplatform-Ansatz nichts zu den Vorläufern Kylix und C++ Builder X geändert. Eigentlich ist es ein Problem aller Crossplatform-Ansätze.

VCL-Programme sind nun mal eng mit der Win32-Welt verknüfpt: Assembler Code, Windows Messages, Dateisystem, Druckeransteuerung, WinApi, man sieht ja was da jetzt alles gefunden wird.

Eine existierende VCL-Anwendung quasi Top-Down in eine Crossplattform-Anwendung umzubauen hat damals schon nicht gut funktioniert. Der Bottom-Up Ansatz erstmal eine portable Geschäftslogik, z.B. in Standard C++, aufzubauen und dann eine portable Oberfläche drüber zu legen, war definitiv der schmerzfreiere.

Das ist aber nicht der übliche Weg, wie Delphi Programmierer bisher ihre Programme aufgebaut haben. Ich denke mal der produktive Einsatz von FireMonkey wird einige Änderungen im Entwicklungsprozess erforden. Vom Gefühl her, sehe ich da den C++ Builder gegenüber Delphi im Vorteil, da C++ auf den anderen Plattformen wesentlich präsenter ist, als das bischen Free Pascal.

Grüße

Robotiker

[mkinzler]

Aber für Delphi gibt es dann ja Compiler für die Plattform bzw. wird es geben

[Robotiker]

Zitat von mkinzler:

Aber für Delphi gibt es dann ja Compiler für die Plattform bzw. wird es geben

Ich meine eigentlich eher, dass es mehr vorhandenen Code gibt, um die genannten Probleme zu lösen.
z.B. sowas
http://pocoproject.org/features.html

Delphi hat erstmal auf jeder neuen Plattform nur die RTL und Firemonkey, der Rest muss erstmal wachsen. Und dieses Wachsen braucht ein gewisses "Moment", das jetzt hoffentlich wieder vorhanden ist. Bei Kylix war es eine Weile da, dann ist es verebbt ...

[Medium]

Wie funktioniert denn so generell Multithreading auf OSX? Mit der "Normalwerdung" von Multicores ist das imho um so mehr ein wichtiges Thema. Ich schreibe derzeit fas kein Programm, dass nicht an etlichen Stellen mit mehreren Threads Dinge tut, und wo die Sync extensiv via Messages läuft. Ich wüsste derzeit auch spontan keine echte Alternative, ohne ein vom Compiler bereit gestelltes Threading-Framework, dass solche Mechaniken "magisch" bereit stellt, und je nach Plattform implementiert. Das ginge aber wohl auch nur, wenn Multithreading sich auf allen Zielplattformen in irgendeiner Weise systematisch vereinheitlichen ließen, d.h. nicht jeweils komplett etwas anderes ist. (Wie war das? Unter Linux musste man forken, den Threadcode laden und manuell den Fork PC auf die Adresse schubsen? Das wäre ja schon recht weit weg von dem, wie Windows Threads behandelt...)

[Luckie]

Bleibt bitte beim Thema. Es geht darum was man als Ersatz für Nachrichten unter Windows bei OSX nimmt. Und es geht nicht um Multithreading oder welche Vor- und Nachteile das FireMonkey Framework hat und warum man es nutzt.

[Robotiker]

Zitat von Medium:

Wie funktioniert denn so generell Multithreading auf OSX?

In der XE2 Hilfe gibt es schon beim Beispiel zur C++ Konsolenanwendung einen Thread. Offensichtlich Posix-Threads, ganz ähnlich wie in Linux.

Zitat von Medium:

Ich wüsste derzeit auch spontan keine echte Alternative, ohne ein vom Compiler bereit gestelltes Threading-Framework, dass solche Mechaniken "magisch" bereit stellt, und je nach Plattform implementiert.

Da triffst du den Nagel auf den Kopf. Im C++ Builder sind Sachen wie boost::threading, boost::filesystem usw. vorhanden. Alternativen gibt es z.B. mit dem oben verlinkten Poco.

Bei Delphi stellt sich mir die Frage, will Emba das alles selber schreiben (in der RTL ?), soll man sich bei Free Pascal bedienen (wie machen die das), oder entwickelt die Community das ?

Tut mir leid, wenn ich euch etwas mit meinen Ausführungen zum C++ Builder nerve, aber die gleiche Thematik hat sich dort ja vor sieben Jahren auch gestellt ...

Zitat von Luckie:

Bleibt bitte beim Thema. Es geht darum was man als Ersatz für Nachrichten unter Windows bei OSX nimmt. Und es geht nicht um Multithreading

Der Threadersteller nutzt doch bisher Windows-Messages zur Threadkommunikation. Und wenn man dafür einen portablen Ersatz sucht, kann man bei den Threads gleich weiter machen.

[arnold mueller]

Zitat von Robotiker:

Der Threadersteller nutzt doch bisher Windows-Messages zur Threadkommunikation. Und wenn man dafür einen portablen Ersatz sucht, kann man bei den Threads gleich weiter machen.

Nein es geht nicht primär um Threads hier, ich habe sie lediglich als Beispiel gebracht. Es ist mir klar das man die Synchronisation von Threads auch anders implementieren kann. TThread existiert auch unter Firemonkey (denke ich, ich habe bisher nur mit der Demo gespielt).

Wenn man auf das Hinzufügen von USB-Sticks reagieren will, wüsste ich gar nicht wie man das plattformübergreifend gestalten kann. Klar in der Windows-Welt mit WM_DEVICE_CHANGE. Aber unter OSX?