Windows Messages in FMX ?!

[Robotiker]

Zitat:

Zitat von arnold mueller (Beitrag 1123453)

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:

Zitat von mkinzler (Beitrag 1123503)

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:

Zitat von Medium (Beitrag 1123540)

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:

Zitat von Medium (Beitrag 1123540)

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:

Zitat von Luckie (Beitrag 1123547)

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:

Zitat von Robotiker (Beitrag 1123549)

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?

[Robotiker]

Zitat:

Zitat von arnold mueller (Beitrag 1123669)

TThread existiert auch unter Firemonkey (denke ich, ich habe bisher nur mit der Demo gespielt).

TThread ist ja Teil der RTL und dafür heißt es in der Doku:

Zitat:

The RAD Studio run-time library (RTL) has been modified so that in most cases you can use the same RTL calls in all of your cross-platform applications (native Win32, Win64, and OS X applications).

Allerdings findet man wenig dazu, wo da die "most cases" aufhören.

[Elvis]

nn

Zitat:

Zitat von arnold mueller (Beitrag 1123669)

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?

Das musst du dann abstrahieren.
Du hättest dann etwas, in das du Handler für diesen Event registrieren kannst. Wie der Event gefeuert wird, ist dir dann egal.
Ist sicher nicht was du hören willst, aber Embarcadero wird sicher keine RTL vom Umfang des .Net/Mono Frameworks bauen, um alle möglichen Eventualitäten zu kapseln.
solche Stellen im Code zu suchen und mit Abstraktionen zu verpacken ist generell eine gute Idee. Denn dann kannst du noch anderen Dinge tun, bevor der Event ausgelöst wird, oder danach. Was ansonsten irgendwo untergemoddert werden müsste.

Um beim Beispiel des Threadings zu bleiben: In OSX gibt es dafür Grand Central Dispatch. Und dafür gibt es anscheinend auch einen Windows-Port.
Das ist nicht direkt vergleichbar mit dem alten Threadpool, den schon unsere Großväter im Krieg benutzt haben.
GCD ist mehr eine Version der .Net Task parallel Library für native Code. D.h. du sagst was alles getan werden muss, und was vor wem getan werden muss. Und GCD kümmert sich darum, dass es möglichst zackig auf so vielen Kernen wie möglich passiert.

[Robotiker]

Ok, ich habe mich gerade mal etwas mit den Sourcen beschäftigt.

TThread z.B. ist offenbar bereits für Windows, MacOS und Linux implementiert. Dabei unterscheiden sich die Member, die die Klasse unter den einzelnen Plattformen hat, teilweise in Typ oder Name.

Die Hilfe beschränkt sich bei den Stichproben, die ich gemacht habe, leider immer meist auf Aussagen wie

Zitat:

Unter Win32 ist Priority ein TThread Priority-Wert. Die möglichen Werte sind in der Tabelle im Thema “Thread initialisieren” aufgeführt

das es unter MacOS und Linux ein Integer ist, muss man in den Quellen nachlesen:

Code:

{$IFDEF MSWINDOWS}
    function GetPriority: TThreadPriority; platform;
    procedure SetPriority(Value: TThreadPriority); platform;
{$ENDIF}
{$IFDEF POSIX}
    // ** Priority is an Integer value in Linux
    function GetPriority: Integer; platform;
    procedure SetPriority(Value: Integer); platform;
    function GetPolicy: Integer; platform;
    procedure SetPolicy(Value: Integer); platform;
{$ENDIF}

Offensichtlich hinkt die Hilfe der Implementierung noch hinterher, da ist noch etwas Forschung angesagt, was überall geht, was teilweise anders geht und was man selber machen muss.