Delphi XE3?

[Darlo]

Wenn es mit dem Mobile Studio klappt und man auch unkompliziert Datenbanken benutzen kann, dann hat EMBA echt was geleistet. Dafür bin ich auch gerne bereit zu bezahlen. Bin allerdings nach wie vor der Meinung, dass es verschiedene Updatepreise geben sollte. XE2 User sollten hier ein bisschen bevorzugt werden bzw. das Mobile Studio dazu bekommen.

[Mavarik]

Hallo Zusammen!

Macht programmieren eigentlich noch Spass?
Eigentlich wird alle nur jedenmal komplizierter, oder?

Hab ich das richtig verstanden?

XE3 kann immer noch kein (natives/FireMonkey) Android?
Ich brauche dafür Mobil Studio?

Kann ich Mobil Studio auch einzeln verwenden, ohne XE3?

Der Marktanzeil von Android liegt schon seit 2010 vor iOS... Selbst Symbian liegt vor iOS... Also warum wurde iOS vor Android implementiert?

Vielleicht liegt es daran, dass ich Apple und das iTunes nicht leidern kann, oder wollt Ihr iOS lieber als Android?

Wer bringt mal Licht ins dunkle?

Grüsse Mavarik

[Darlo]

Mir persönlich ist iOS wichtiger als Android. Der Vorteil ist eben die geringe Hardware-Vielfalt. Ferner vermute ich,
dass iOS-User eher bereit sind für eine App zu bezahlen. Vor Android habe ich ein bisschen Angst was den Supportaufwand betrifft.
Allein schon die diversen Bildschirmgrößen und extrem schwankende Leistung der Geräte.

So wie ich das verstanden habe ist das Mobile Studio ein Add-On für XE3 und setzt somit XE3 voraus. Außerdem wurde wohl einiges an Firemonkey geändert. Somit dürfte nur FM² mit dem Mobile Studio kompatible sein.

Gruß

[Robotiker]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1179379)

Zitat:

Zitat von Robotiker (Beitrag 1179305)

Naja, ob es problemlos geht, wage ich zu bezweifeln:

• ARM Compiler fehlt noch
• Windows 8 SDK Umsetzung für Delphi ?
• Gegenstück zur WRL (C++ Wrapper für WinRT COM)
• Alternativ Pascal Gegenstück zu C++/CX (Syntactic Sugar für WinRT COM)

Wenn ich diesen Beitrag richtig interpretiere ist es doch ein richtiger Metro-Support bei FMX

Hierzu gibt es neue Erkenntnisse aus einem Posting von Allen Bauer:

Zitat:

Yes. We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless
you're the VC++ RTL DLL.

...

We're currently rattling some cages at MS to find out how or if they're going to allow third-party tools to target WinRT.

...

We are able to build WinRT applications with Delphi that work with a developer certificate, however they all fail the application qualification checks because of the aforementioned (an other) APIs.

...

Like the APIs I mentioned above, there are lots of changes with WinRT that make targeting it a little more tricky. For instance, you cannot merely open any file, access the registry, and even use the loopback (127.0.0.1) adaptor. LoadLibrary cannot be used to load any arbitrary DLL; you must call LoadPackageLibrary and only on a DLL that is present
in the digitally signed appx package. WinRT is a seriously locked down sandbox or "walled-garden" with some extremely high walls.

Also, wer kurzfristig native Apps für den Windows Store programmieren will, .net Apps sind ja so toll zu dekompilieren, nimmt dafür VC++ ...

[Uwe Raabe]

Zitat:

Zitat von Darlo (Beitrag 1179488)

Mir persönlich ist iOS wichtiger als Android. Der Vorteil ist eben die geringe Hardware-Vielfalt. Ferner vermute ich,
dass iOS-User eher bereit sind für eine App zu bezahlen. Vor Android habe ich ein bisschen Angst was den Supportaufwand betrifft.
Allein schon die diversen Bildschirmgrößen und extrem schwankende Leistung der Geräte.

Das sind durchaus nachvollziehbare Überlegungen. Es wäre interessant zu erfahren, was man unterm Strich mit iOS bzw. Android Apps erzielen kann. Laut diesem Bericht bei Heise zahlen iOS-Nutzer im Schnitt viermal soviel für Apps als Android-Nutzer. Ob man das allerdings einfach mit dem Verhältnis der Verkaufszahlen gegenrechnen kann, ist eher fraglich. Auf jeden Fall muss man dann auch den erhöhten Aufwand und das Risiko gemäß der oben aufgeführten Punkte berücksichtigen.

Zitat:

Zitat von Darlo (Beitrag 1179488)

So wie ich das verstanden habe ist das Mobile Studio ein Add-On für XE3 und setzt somit XE3 voraus.

Da habe ich eine andere Information! In diesem Post auf G+ schreibt Malcolm Groves (Embarcadero):

Zitat:

if Delphi and MobileStudio are installed ont eh ame machine, the mobile stuff will show up as an additional personality int he IDE (like Delphi, C++Builder currently do)

Das deutet auf eine Standalone-Version von MobileStudio hin.

[greenmile]

Benötigt MobileStudio nicht FM2, damit XE3?

[Darlo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1179501)

Da habe ich eine andere Information! In diesem Post auf G+ schreibt Malcolm Groves (Embarcadero):

Zitat:

if Delphi and MobileStudio are installed ont eh ame machine, the mobile stuff will show up as an additional personality int he IDE (like Delphi, C++Builder currently do)

Das deutet auf eine Standalone-Version von MobileStudio hin.

Das wäre ja interessant, dann würde XE2 mit FM(1) und Mobile Studio mit FM² arbeiten. Dürfte dann doch nicht so schwer sein FM² in XE2 zu integrieren :gruebel:

Gruß

[mjustin]

Zitat:

Zitat von Robotiker (Beitrag 1179497)

Also, wer kurzfristig native Apps für den Windows Store programmieren will, .net Apps sind ja so toll zu dekompilieren, nimmt dafür VC++ ...

Die Dekompilierbarkeit kann man durch Auslagerung der Geschäftslogik auf einen (nativ in Delphi betriebenen) Web Service / Anwendungsserver ausgleichen. (kbmMW, Data Abstract & Co.)

Anwendungen, bei denen die gesamte "Essenz" im User Interface steckt, haben da zugegebenermaßen Nachteile :twisted:

[Uwe Raabe]

Zitat:

Zitat von greenmile (Beitrag 1179507)

Benötigt MobileStudio nicht FM2, damit XE3?

Der erste Teil der Frage ist wohl korrekt, aber wie kommst du auf den darauf folgenden Schluss? Nirgendwo steht (bislang) geschrieben, daß es FM2 nur als Teil von XE3 geben wird. Ich bedaure aber auch, daß die verlässlichen Informationen in diesem Bereich eher gegen Null gehen.

[mkinzler]

Die Desktop Version von FM² ist Teil von XE3. Die mobile ( iOS, Android) vom Mobile Studio.

[Darlo]

Zitat:

Zitat von mkinzler (Beitrag 1179513)

Die Desktop Version von FM² ist Teil von XE3. Die mobile ( Ios, Android) vom Mobile Studio.

Dann vermute ich Lizenzkosten die mich nicht erfreuen werden...

Zusatz: Gibt es schon Erkenntnisse ob das Mobile Studio FastReport enthält?

[Mavarik]

Für alle die es noch nicht gelesen haben:

xe3-and-beyond

Mavarik

[BUG]

Das könnte vielleicht auch ganz interessant sein: Why no native WinRT support in Delphi XE3?

[Robotiker]

Zitat:

Zitat von BUG (Beitrag 1179547)

Das könnte vielleicht auch ganz interessant sein: Why no native WinRT support in Delphi XE3?

Der zitiert da das selbe, was ich gerade sechs Beiträge weiter oben zitiert habe. 8-)

Bemerkenswert ist die Quelle, das Originalpost tauchte in Delphi Non-Tech, irgendwo an hundertster Stelle in einem Thread über den Html5-Builder (!) auf, kein Blog-Eintrag oder sowas. :?

Das ganze betrifft übrigens nicht Metro Apps auf normalem Windows 8, sondern nur für WinRT, das ist die Version für ARM-Tabletts, damit möglicherweise aber auch Windows Phone 8.

Jedenfalls hat MS dort einige APIs so abgesichert, dass das BS nur Aufrufe direkt aus der VC Runtime (aber nicht aus mit VC geschriebenen Programmen heraus) zulässt. Da steht die Delphi Runtime dann vor verschlossenen Türen, es sei denn, man leitet sie über die VC Runtime um.


Die anderen Sachen, über die Allen Bauer sich da beschwert, wie fehlender Datei- und Registry Zugriff, die betreffen allle Apps. Da haben sie wahrscheinlich ein Problem mit der Portierung von FireMonkey, das müssen sie aber selber ausbaden.

[mkinzler]

WinRT ist aber auch die API für Metro/Win8 UI. Und diese ist imho gemeint.

Zitat:

Der zitiert da das selbe, was ich gerade sechs Beiträge weiter oben zitiert habe.

Der davor war auch schon genannt. Du kannst aber von keinem verlangen, den Thread ganz zu Lesen. :mrgreen:

[Robotiker]

Zitat:

Zitat von mkinzler (Beitrag 1179551)

WinRT ist aber auch die API für Metro/Win8 UI. Und diese ist imho gemeint.

Das ist nicht ganz klar. Insbesondere weil es bei MS auf Channel 9 ein Video gibt, wo die WinRT (die API) Leute andere Entwickler einladen, andere Programmiersprachen (auch native ?) für WinRT zu portieren. Dies ist ein Punkt, der diese ganze Geschichte etwas merkwürdig macht.

Hier der Link
http://channel9.msdn.com/Events/Lang...indows-Runtime
wo weiter unten in den Kommentaren ergänzt wird

Zitat:

Martyn made it clear that we not only want language designers and implementers to add WinRT to their list of target platforms for their language and toolchains, but we will help and advise.

Scheint als gibt es da noch ein paar unerzählte Teile der Geschichte.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1179308)

Zitat:

Zitat von Robotiker (Beitrag 1179305)

Naja, ob es problemlos geht, wage ich zu bezweifeln:

problemlos meine ich das keine NoGo-Argumente wie es die VCL bringt. Das es Arbeit bedeutet ist klar.

Diese Arbeit hat Allen Bauer im Embarcadero Forum so beschrieben:

Zitat:

To be a "consumer" of WinRT, you can code directly to those interfaces,
which is about as painful as slamming your hand in a car door, or the
language provides a "projection" which maps this meta-data interfaces
onto actual language classes/objects/types.

Being a "producer" takes far more work since you have to ensure your
compiler supported "projection" is able to generate this Windows
meta-data.

[Darlo]

Gelöscht.

[stahli]

Zitat:

Zitat von Peter666 (Beitrag 1179288)

Ehrlich gesagt ist so etwas ein klares Nogo und wenn nichtmal eine einfache Listbox performant läuft, dann braucht man Treeviews und Grids ehrlich gesagt gar nicht erst probieren. ... Überspitzt formuliert heisst das, dass wohl keiner wirklich ne Tabelle auf ne Kugel rendern lässt und diese da mit dem Gyroskop auf seinem Tablet drehen will.

:thumb:

Ich schaue nach längerer Zeit mal wieder vorbei...

An XE3 finde ich eigentlich nur das Visual LiveBinding reizvoll. Zumindest scheint es in die richtige Richtung zu gehen. Mal schauen, ob es Videos geben wird, die auch auf die (möglicherweise existenten) kleinen Haken und Details eingehen.
Für XE4 würde ich mir ein Rundum-Sorglos-ORM wünschen, das mir meine Datenobjekte persitiert und zwischen Server und Clients verteilt, die ich dann über das Visual LiveBinding an die Formular-Controls binden kann. Das wäre für mich DAS Kaufargument.

FM(2) fände ich nur interessant, wenn es sauberer aufgebaut wäre und sich leichter an eigene Bedürfnisse anpassen ließe als die VCL. Bei der VCL gibt es m.E. einfach zu viele Überraschungen, wenn man einige Details anpassen will (Drag&Drop, Fokusbehandlungen o.ä.). Vorteile vermute ich bei FM aber da nicht.

Unter "Layoutmanager" kann ich mir derzeit nichts vorstellen.

Ich werde mal ein halbes Auge offen halten...

[mkinzler]

[QUOTE=stahli;1179733]

Zitat:

Zitat von Peter666 (Beitrag 1179288)

An XE3 finde ich eigentlich nur das Visual LiveBinding reizvoll. Zumindest scheint es in die richtige Richtung zu gehen. Mal schauen, ob es Videos geben wird, die auch auf die (möglicherweise existenten) kleinen Haken und Details eingehen.

http://www.mitov.com/products/openwirelivebindings

Zitat:

FM(2) fände ich nur interessant, wenn es sauberer aufgebaut wäre und sich leichter an eigene Bedürfnisse anpassen ließe als die VCL. Bei der VCL gibt es m.E. einfach zu viele Überraschungen, wenn man einige Details anpassen will (Drag&Drop, Fokusbehandlungen o.ä.). Vorteile vermute ich bei FM aber da nicht.

Was meinst du damit?

Zitat:

Unter "Layoutmanager" kann ich mir derzeit nichts vorstellen.

http://de.wikipedia.org/wiki/Layoutmanager

[MEissing]

Zitat:

Zitat von Darlo (Beitrag 1179327)

Im diesem Zusammenhang erstmal vielen Dank @meissing für die Informationen!

Danke. Das hört man selten^Hgerne

Zitat:

Zitat von Darlo (Beitrag 1179327)

Offene Fragen von mir:
1. Wann ist der Release geplant und ab wann gibt es Infos zu den Preisen (inkl. Mobile Studio)?
2. Bekommt man mit Aktivierung sofort Zugang zur Beta und ist in der Beta das Mobile Studio integriert?

Gruß

Das werden wir mit der offiziellen Ankündigung (innerhalb der nächsten Wochen / bis zum Ende des Quartals) bekanntgeben.... sorry.

[MEissing]

Zitat:

Zitat von mkinzler (Beitrag 1179355)

@meissing: Wird für das Mobil Studio XE3 benötigt?

Nein.

Man wird auch "nur" das Mobile Studio erwerben können.... Die grundlegende IDE wird dann installiert...ohne Delphi Personality.

Das Mobile Studio ist letztendlich eine weitere Personality innerhalb des RAD Studios.

[Lemmy]

@Matthias: Danke für die Info!

[stahli]

Zitat:

Zitat von mkinzler (Beitrag 1179735)

http://www.mitov.com/products/openwirelivebindings

Das gefällt mir sehr gut! Mal sehen, welche Variante sich eher durchsetzt.

Zitat:

Zitat von mkinzler (Beitrag 1179735)

Was meinst du damit?

Ich habe eigene Komponenten abgeleitet, die an Objektpropertys gebunden wurden und in spezieller Weise auf Mausereignisse reagierten sollten. Die VCL-Controls sind gegenüber solchen spezifischen Anpassungen leider etwas widerspenstig und oft unlogisch aufgebaut (z.B. wird OnClick nicht nur aufgerufen, wenn die Kompo angeklickt wird oder eine RadioGroup "klickt", wenn das Formular aktiviert wird).

Zitat:

Zitat von mkinzler (Beitrag 1179735)

http://de.wikipedia.org/wiki/Layoutmanager

Danke. Das kann eine nützliche Sache sein.

[mkinzler]

Zitat:

Das gefällt mir sehr gut! Mal sehen, welche Variante sich eher durchsetzt.

Ich vermute mal, das ist die selbe Lösung.

[himitsu]

Nur mal so eine rein hypothetische Frage:

Im Prinzip ist es doch erstrebenswert die Logic von der GUI zu trennen, also da stimmt ihr mir doch zu?

Aber irgendwie ist das LiveBinding IMHO doch Logic (Verknüpfungen von Komponenten), welche direkt in der GUI rumgammeln. :gruebel:



Wenn man will, dann kann man ja schon einen ganzen Taschenrechner zusammenbauen, wobei die gesamte Logic nur noch im LiveBindung liegt ... also die Logic komplett in der GUI :angle2:
Ich finde zwar das Beispiel nicht mehr, aber ich sah letztes Jahr mal eine Demo, wo man im LiveBinding beim Ziel sowas wie "Edit1 + Edit2" oder war's "Edit1.Text + Edit2.text" eintrug und dann wurde im Edit3 die Summe der beiden Werte angezeigt.

[MEissing]

Zitat:

Zitat von himitsu (Beitrag 1179752)

Nur mal so eine rein hypothetische Frage:

Im Prinzip ist es doch erstrebenswert die Logic von der GUI zu trennen, also da stimmt ihr mir doch zu?

Aber irgendwie ist das LiveBinding IMHO doch Logic (Verknüpfungen von Komponenten), welche direkt in der GUI rumgammeln. :gruebel:

Visual LiveBinding ist mehr als das Verknüpfen von Komponenten.

Man kann auch x-beliebige Objekte (natürlich auch eigene) verbinden. TFoo mit seinen Membern an datensensitive Objekte. TFoo (in einer anderen Klasse/Unit) bildet dann die Persistenz ab....

Aber: A fool with a tool is still a fool!

[Wosi]

Zitat:

Zitat von himitsu (Beitrag 1179752)

Nur mal so eine rein hypothetische Frage:

Im Prinzip ist es doch erstrebenswert die Logic von der GUI zu trennen, also da stimmt ihr mir doch zu?

Aber irgendwie ist das LiveBinding IMHO doch Logic (Verknüpfungen von Komponenten), welche direkt in der GUI rumgammeln. :gruebel:



Wenn man will, dann kann man ja schon einen ganzen Taschenrechner zusammenbauen, wobei die gesamte Logic nur noch im LiveBindung liegt ... also die Logic komplett in der GUI :angle2:
Ich finde zwar das Beispiel nicht mehr, aber ich sah letztes Jahr mal eine Demo, wo man im LiveBinding beim Ziel sowas wie "Edit1 + Edit2" oder war's "Edit1.Text + Edit2.text" eintrug und dann wurde im Edit3 die Summe der beiden Werte angezeigt.

Ich denke bei LiveBindings geht es darum triviale Zusammenhänge zwischen einzelnen Controls darzustellen und nicht um tatsächlich Anwendungen zu programmieren. Dem Entwickler wird so einiges an lästigem Code erspart, der andernfalls in der Formular-Klasse untergebracht werden muss. Dadurch wäre die Logik auch wieder in der GUI verankert.
In Qt gibt es ein ähnliches Konzept schon länger: Signals and slots

[greenmile]

[QUOTE=MEissing;1179737]

Zitat:

Zitat von mkinzler (Beitrag 1179355)

Man wird auch "nur" das Mobile Studio erwerben können.... Die grundlegende IDE wird dann installiert...ohne Delphi Personality. Das Mobile Studio ist letztendlich eine weitere Personality innerhalb des RAD Studios.

Ohoh das wird teuer. An sich finde ich die Trennung ja nicht übel, aber wenn es ein eigenes Produkt wird, dann bekommt es auch den Preis eines eigenen Produktes. Mich würde wirklich stark interessieren, wieso es in XE2 drin war und nun getrennt wird. Sieht mir sehr nach "heißmachen" aus.

Am wichtigsten ist jedoch für mich: Läuft FM2 schneller und stabil? FM selbst war ja sehr langsam und hatte einige Bugs bzw einiges funktionierte schlichtweg nicht. VIelleicht kann mir das jemand in zwei Wörtern (Ja oder Nein) an einem Beispiel beantworten: Funktioniert das füllen einer Listbox mit 1000 Einträgen nun schneller als 30 Sekunden? Und funktioniert Drag&Drop unter Mac nun sauber? Und zu guter Letzt: Gibt es unter Mac nun native Hints?

Das sind momentan 3 wichtige Fragen, wenn es um einen Wechsel zu XE3 geht. Anchors/Actions hin oder her, da habe ich zur Not einen Workaround. Aber die Basics müssen stimmen und endlich funktionieren.

LiveBindings interessieren mich, sorry, nicht. Die machen die Welt ein wenig leichter, aber ich traue den Designern nicht, bislang lief kaum einer stabil (wie der FM Style Designer, Form Designer usw.), außer vielleicht der Dialog für die Bilderauswahl. Ich bin seit D2 dabei und in der Regel braucht der "Schnick-Schnack" erstmal 1-2 Versionen, bis er stabil und produktiv läuft. Wenn es ihn dann überhaupt noch gibt, siehe "Datei / Neu / Firemonkey-HD-iOS-Anwendung".

[Daniel]

Zitat:

Zitat von greenmile (Beitrag 1179768)

Am wichtigsten ist jedoch für mich: Läuft FM2 schneller und stabil? [...] Funktioniert das füllen einer Listbox mit 1000 Einträgen nun schneller als 30 Sekunden?

Nun, ich bin natürlich nicht von Embarcadero ... aber ... wenn ich mal *hust* ... mutmaßen dürfte, dann würde folgender Code in einer Test-VM mit Windows 8 (VMWare Fusion 5) mit FireMonkey2 und VCL ähnlich schnell (beide Varianten reproduzierbar unter 50ms) laufen. Wichtig wäre möglicherweise (was weiß ich schon) die Verwendung von

Delphi-Quellcode:

.BeginUpdate

und

Delphi-Quellcode:

.EndUpdate

.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var i : integer;
 s, e : cardinal;
begin
  ListBox1.Clear;

  s:= GetTickCount;

  ListBox1.BeginUpdate;
  for i:= 0 to 999 do
  begin
    ListBox1.Items.Add( 'Eintrag #' + IntToStr(i) );
  end;
  ListBox1.EndUpdate;

  e:= GetTickCount;
  ShowMessage( IntToStr(e-s) + 'ms' );
end;

Würde das Deine Frage beantworten?

[greenmile]

Natürlich kenne ich .BeginUpdate / .EndUpdate. Aber unter Mac (und ich meine ein physikalisches MacBook der aktuellen Generation) ist es saulangsam. Unter Windows geht es, unter Mac ist es eher peinlich; so peinlich, dass ich derzeit maximal 300 Einträge anzeige.

[mjustin]

Zitat:

Zitat von Robotiker (Beitrag 1179554)

Scheint als gibt es da noch ein paar unerzählte Teile der Geschichte.

Allen Bauer gab im zitierten Thread auch dieses Fazit:

Zitat:

Until we can get past that, targeting WinRT isn't actually possible from a deliverable product sense.
We are able to build WinRT applications with Delphi that work with a developer certificate, however they all fail the application qualification checks because of the aforementioned (an other) APIs.

• Für (natives) WinRT kann man, solange diese technischen Hürden bestehen, kein Produkt liefern
• Mit einem Entwicklerzertifikat kann man zwar eine WinRT Anwendung erstellen, die lokal mit einem Entwicklerzertifikat arbeitet, aber die WinRT App besteht nicht den Aufnahmetest für den Windows Store

Der zweite Punkt bedeutet auch: im Intranet (ohne Windows Store) ist die Verteilung einer mit Delphi erstellten WinRT Anwendung nur möglich, wenn auf jedem Computer ein Entwicklerzertifikat installiert ist.

Diese Möglichkeit wurde im September 2011 auf Stackoverflow bereits beschrieben:

How to Distribute Compiled Windows 8 Metro Applications without Windows Store?

Zitat:

Each machine that wants to install the application will need a developer license.

Also:
Jeder Computer, auf dem die App installiert werden soll, benötigt eine Entwicklerlizenz.

[MEissing]

Zitat:

Zitat von greenmile (Beitrag 1179768)

Ohoh das wird teuer.

Selbst ich kenne die Preise noch nicht....

....aber schön, dass man schon FUD lesen kann. :-) Besonders einfallsreich ist der aber nicht

[Darlo]

Zitat:

Zitat von MEissing (Beitrag 1179780)

Zitat:

Zitat von greenmile (Beitrag 1179768)

Ohoh das wird teuer.

Selbst ich kenne die Preise noch nicht....

....aber schön, dass man schon FUD lesen kann. :-) Besonders einfallsreich ist der aber nicht

Ich gehe ebenfalls davon aus dass es teurer wird (ist ja einfach ein Produkt mehr dass man lizenzieren muss). Wenn die angedeuteten Funktion kommen bin ich jedoch echt " :firejump: " auf das Mobile Studio

[himitsu]

Es ist ja nicht so, daß ich die LiveBindings schlecht finde ... die sind bestimmt ganz praktisch und die graphischen sind mit Sicherheit auch noch übersichtlicher (falls man nicht zuviel auf einer Form drauf hat).

Aber in so alteingesessenen und über jahrzehnte gewachsenen Projekten ist ein bissl Logic jetzt schon in der GUI (also in den EventHandlern), dann gammelt welche in ein paar Klassen rum (hoffentlich auch logisch zusammenhängend), Einiges befindet sich in irgendwelchen Datenbankfunktionen, Unzähliges verteilt sich wirre in unüberschaubaren Triggern (auch schonmal mehrere Trigger, welche auf das Selbe reagieren) und das was mehrfach an sowas wie AfterScoll, AfterInsert, AfterPost, BeforPost und seinen Freunden hängt, will ich lieber nicht denken.
Da sieht man doch jetzt schon kaum noch wer durch.

Und nun gibt es eine neue Stelle, wo man nach weiteren Funktionen und Abhängigkeiten suchen muß. :?

[Robotiker]

Zitat:

Zitat von mjustin (Beitrag 1179775)

Allen Bauer gab im zitierten Thread auch dieses Fazit:

In einem anderen Thread hat er übrigens noch gesagt

Zitat:

I never said they are actively blocking access to third-parties. I don't think they are maliciously excluding third-parties. "Do not attribute malice to that which can be described by mere ignorance or incompetence."

Es scheint technisch auch mehr ein Problem der Zertifizierung von Apps für den Shop zu sein, keine Sonderbehandlung der VC++ RTL durch das Betriebssystem.


Bei den andere technischen Schwierigkeiten mit der API, die Allen Bauer da beschreibt, frage ich mich allerdings, warum man das erst jetzt offen diskutiert. Ich kann mich noch erinnern, dass ich letztes Jahr mit FireMonkey im C++ Builder gespielt habe und wenig später die Videos von der Build-Konferenz über WinRT gesehen habe. Mein erster Eindruck war "Das passt von der Architektur nicht wirklich gut zusammen", kann sein, dass ich das damals hier sogar schon mal geschrieben habe, als über FireMonkey diskutiert wurde.

Für Interessierte hier mal eine aktuelle Beschreibung, wie native WinRT Apps gebaut werden. In der Xaml-Variante, nicht in der DirectX-Variante, die FireMonkey wohl benutzen würde:
http://blogs.msdn.com/b/vcblog/archi.../10343401.aspx

[greenmile]

Zitat:

Zitat von MEissing (Beitrag 1179780)

Zitat:

Zitat von greenmile (Beitrag 1179768)

Ohoh das wird teuer.

Selbst ich kenne die Preise noch nicht....

....aber schön, dass man schon FUD lesen kann. :-) Besonders einfallsreich ist der aber nicht

Was ist FUD?

[MEissing]

Zitat:

Zitat von greenmile (Beitrag 1179827)

Was ist FUD?

Das, was du geschrieben hast....

[mjustin]

Zitat:

Zitat von Robotiker (Beitrag 1179821)

Es scheint technisch auch mehr ein Problem der Zertifizierung von Apps für den Shop zu sein, keine Sonderbehandlung der VC++ RTL durch das Betriebssystem.

Ja, das ist aktuell ein etwas sumpfiges Gebiet.

Es gibt eine (technische) Sonderstellung für Internet Explorer, Microsoft Office, das .NET Framework und für die VisualC++ Runtime (native Anwendungen).

Zum Beispiel kann ausser Internet Explorer keine WinRT / ARM Anwendung JIT (Just In Time) Kompilierung implementieren (da dazu vom Store Validator nicht akzeptierte API Funktionen benötigt werden), was schon zu Protesten von Browserherstellern geführt hat:

http://www.freelists.org/post/luajit...dows-8-for-ARM

http://www.extremetech.com/computing...windows-on-arm

http://news.cnet.com/8301-1001_3-574...wser-concerns/

Im Detail wird in diesem Stack Overflow Artikel gezeigt, dass die Sandbox der Windows 8 UI Anwendungen nicht alle Anwendungen gleich behandelt:

http://stackoverflow.com/questions/1...winrt-possible

Hier kann man nachlesen, dass die VC++ Runtime besondere Rechte hat:

Zitat:

Zitat von Allen Bauer

Right now the VC++ RTL DLL is given special dispensation since that is
the library that makes the calls to those forbidden APIs and not directly from the user’s app.

Für Delphi Entwickler bleibt natürlich immer noch die Möglichkeit, eine WinRT Oberfläche mit einer webbasierten Serveranwendung zu verbinden, die man nativ programmiert.

[Robotiker]

Danke für die Links.

Mal sehen, inwieweit sich das noch bessert, wenn Win8 (und seine Nachfolger) richtig in die Gänge kommt.

Was die Programmierung von XAML-Apps angeht, stellt es sich für mich allerdings so dar, dass der Unterschied zwischen der Programmierung von managed Apps in Prism oder C# und der von nativen Apps in C++, kaum größer ist, als der zwischen Desktop Anwendungen in Delphi und dem C++ Builder. Jeweils gleiche IDE, Tools und Anwendungsstruktur, nur eine andere Sprache und teilweise andere Bibliotheksfunktionen (C++ Standardlib und z.B. Boost, statt .net BCL bzw. VCL/Delphi RTL).

Delphi macht da wohl nur Sinn, wenn man möglichst viele Plattformen mit FireMonkey abdecken will. Man entfernt sich mit der IDE und der Anwendungsstruktur recht weit von den anderen Sprachen.

[Insider2004]

WinRT, MobileStudio, etc. sind mal wieder richtig schöne restriktive Technologien, die total verrammelt sind. Jeder will Geld und Lizenzgebühren kassieren. Ich wette, fast alle Entwickler werden diese Techniken meiden. Das wird sicher ein toller Durchbruch werden. Vor allem, wenn man bedenkt, dass WinRT nur ein zusätzlicher Layer auf der Win32 API ist. Im Prinzip ist .Net=WinRT.