Windows Messages in FMX ?!

[bernau]

Zitat von Union:

Und warum sollte man sich das dann antun? Um im Startbildschirm ein rotierendes Firmenlogo anzuzeigen?

Um die grafischen Fähigkeiten von Firemonkey zu nutzen. Man sollte es nicht auf das rotierende Firmenlogo beschränken.

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

[bernau]

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.

Habe ich doch geschrieben. Um die grafischen Fähigkeiten von Firemonkey zu nutzen. Z.B. die Zoom-Funktion, die auch die Controls stufenlos ohne grafische Einbußen vergrößert und ohne daß mir die Eingabemaske zersemmelt wird. Was musste ich mir schon beschwerden anhören, weil der eine Kunde die Eingabemaske auf einer 1680*1050-Auflösung nicht mehr sehen konnte, weil ich Eingabemasken manchmal auf 800*600 runterschrauben muss, da diese Bildschirmauflösung immer noch verwendet wird. Und ja, ich verdiene damit auch mein Geld.

[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...)