Firemonkey mit XE2

[Mavarik]

Hallo Zusammen!

Einfache Frage...: Arbeitet einer von Euch ernsthaft mit XE2 & Firemonkey?

Ich frage, weil ich habe schon mehr Fehler als Features gefunden.

- Die IDE spackt rum
- Die Zwischenablage um Controls zu kopieren funktioniert nicht richtig
- Die Positionsmarken fehlen
- Die Tabreihenfolge funktioniert nicht.
- Es ist alles unscharf
- usw.

Grüsse Mavarik

[milo]

Nein. :roll: :-D

Gruß Milo

[stahli]

Mit der XE3 Trial ging es mir ähnlich.

Bei einer Master/Detail-DataSource und LiveBinding an ein Grid wurde beim Master-Datensatzwechsel im Detail-Grid nur die aktuelle Zeile neu gezeichnet. Der Rest dann erst durch MouseOver oder Fokussieren (weiß nicht mehr genau) des Grids.

Ich will es aber dennoch mit FM (und dem TMSFMGrid) versuchen, sobald ich mein XE3 Ultimate habe.

Vom Ansatz her finde ich das (selbst für reine Windowsanwendungen) inzwischen ganz interessant, wobei ein paar Dinge sicher noch ausbaufähig sind.


PS: Die gleiche Frage wollte ich demnächst auch mal stellen. :)

[himitsu]

Für das Unschaf in XE2 gibt es aber irgendwo einen Bugfix (danach isses dann nicht mehr ganz so unscharf :angle:)

Tipp: Wenn ihr lachen+weinen wollt, dan schaut euch die VCL-Metro-App an (Datei > Neu > ...)

[fred.ahrens]

Wir haben ein Miniprojekt mit FireMonkey gemacht, um die Möglichkeiten zu testen.
Im Ergebnis ist uns FireMonkey noch zu "experimentell" - um es mal diplomatisch auszudrücken.

Neue Projekte mit FM sind nicht geplant und es juckt uns auch nicht wirklich in den Fingern, noch mehr mit FireMonkey zu machen, was bei neuen Features eigentlich immer der Fall ist.

Das dann bei XE3 auch noch Features entfernt werden, die es bei XE2 noch gab, lassen doch wirklich daran zweifeln, dass FireMonkey durch eine durchdachte Roadmap begleitet wird.

Fred

[mkinzler]

Zitat:

Das dann bei XE3 auch noch Features entfernt werden, die es bei XE2 noch gab, lassen doch wirklich daran zweifeln, dass FireMonkey durch eine durchdachte Roadmap begleitet wird.

Was wurde den entfernt?
Oder meinst du die Plattform iOS, welche in das MobileStudio ausgelagert wurde?

[Union]

Ja, wahrscheinlich meint er das.

Mir ging es ja ähnlich: Gelockt durch iOS XE2 + SA gekauft. Dann zwei Anwendungen für iOS erstellt, die dann mangels FM-Funktionalität hauptsächlich in FP erstellt werden mussten und mehr {IFDEF} enthielten als LOC. Delphi eigentlich degradiert zu einem ziemlich fehlerbehafteten Resourcen-Editor.

Jetzt ist XE3 da OHNE JEDE Mobile Unterstützung und laut aktueller Product Adress darf man sich das dann 2013 modulweise dazu kaufen. Selbstverständlichkeiten wie Anchors und Actionlists werden als tolle Neuerungen verkauft.

Den alten Source kann man nun auch in die Tonne treten.

[himitsu]

Zitat:

Zitat von Union (Beitrag 1190098)

Den alten Source kann man nun auch in die Tonne treten.

Es kommt drauf an, sooo viel haben die letztendlich garnicht verändert.
Der Umbau meines FMX-Hints ging einfacher, als erwartet.
- praktisch nur paar Property verschoben/umbenannt
- und ein/zwei verwendete Funktionen ausgebaut (da gab es z.B. mal eine globale Bitmapinstanz, welche für Größenberechungen verwendet wurde, wenn die Komponente selbst grade keinen Canvas besaß, weil sie z.B. nirgendwo einer Form zugewiesen war)



OK, jetzt soll man ja das MobileStudio (irgendwann mal?) mit dazubekommen (abgesehn von "Neukunden"), aber wird das dann auch bei XE4,5,6,... wieder der Fall sein? Ist ja nicht so, daß Delphi jetzt wieder günstiger wird, wo nun wieder weniger drin ist.

[Darlo]

Zitat:

Zitat von himitsu (Beitrag 1190101)

Zitat:

Zitat von Union (Beitrag 1190098)

Den alten Source kann man nun auch in die Tonne treten.

Es kommt drauf an, sooo viel haben die letztendlich garnicht verändert.

Wenn man sich das FireFlow Sample unter XE3 anschaut, sieht man leider dass da einiges nicht mehr richtig klappt (selbst die mit XE3 mitgelieferte Demo funktioniert
nicht richtig)

Auf die Frage ob jemand mit FM richtig arbeitet: Ja ich ;-)

Das beschriebene Problem mit den Grid hatte ich auch. Man muss hier mit BeginUpdate und EndUpdate sowie im Notfall einem refresh arbeiten, dann funktioniert das auch richtig.
Selbes bei Memos.

[Union]

Naja, unter anderem funktionierte ja das Virtuelle Keyboard nicht so wirklich. Das musste man sich im iOs zusammenhacken. Oder an den ViewController zu kommen:

Delphi-Quellcode:

type
  TUIWindowHack = objcclass(UIWindow)
  protected
  public
    Text: UITextField;
    mainView: UIView;
    mainController: UIViewController;
  end;
{$ENDIF}


function SelectImage(ABitmap : TBitmap) : boolean;
{$ifdef FPC}
  var
    ImagePicker : UIImagePickerController;
    Window : TUIWindowHack;
{$endif}
begin
{$ifdef FPC}
  Bitmap := ABitmap;
  Window := UIApplication.sharedApplication.Windows.objectAtIndex(0);
  ViewController := Window.mainController;

[Darlo]

Zitat:

Zitat von Union (Beitrag 1190110)

Naja, unter anderem funktionierte ja das Virtuelle Keyboard nicht so wirklich.

Da hast Du recht. Dass man auf dem iPad nicht auf das verschwinden den Keyboards (dieser Knopf ganz unten rechts) mit den Standardfunktionen von FM reagieren kann hat mich schwer gewundert.

Habe jedoch hier eine bequeme Lösung gefunden:
http://syncro-concept.aisware.de/sit...atur_erkennen/

[Mavarik]

Zitat:

Zitat von Union (Beitrag 1190110)

Naja, unter anderem funktionierte ja das Virtuelle Keyboard nicht so wirklich. Das musste man sich im iOs zusammenhacken. Oder an den ViewController zu kommen:

Delphi-Quellcode:

type
  TUIWindowHack = objcclass(UIWindow)
  protected
  public
    Text: UITextField;
    mainView: UIView;
    mainController: UIViewController;
  end;
{$ENDIF}


function SelectImage(ABitmap : TBitmap) : boolean;
{$ifdef FPC}
  var
    ImagePicker : UIImagePickerController;
    Window : TUIWindowHack;
{$endif}
begin
{$ifdef FPC}
  Bitmap := ABitmap;
  Window := UIApplication.sharedApplication.Windows.objectAtIndex(0);
  ViewController := Window.mainController;

Also mal ehrlich... Glückwunsch zu Deinem Wissen aber...

- TUIWindowHack = objcclass(UIWindow)
- Window := UIApplication.sharedApplication.Windows.objectAtIn dex(0);

Wie kommt Ihr an diese Infos...? Mein größtest Problem ist.. NULL Ahnung von Apple
Und eigentlich bin ich davon ausgegangen, das Delphi und die Runtime mir alles bietet, was ich auf der (dunklen) anderen Seite benötige.

Gibt es da ein geheimes Buch oder Tutorial, dass ich nicht kenne?

Grüsse Mavarik

[daywalker9]

http://developer.apple.com

[Union]

Ich hab mir die FP header angeschaut und viel mit Phil Hess geschrieben. Ausserdem natürlich ein iOS Buch durchgearbeitet und mir ein bischen XCode reingezogen. Aus meiner Sicht war FM (1) wohl eher ein Proof of concept. Leider war die Herangehensweise falsch. Das beste war, wenn ich in QC Fehler beanstandet habe dann kam als Antwort teilweise: "Das ist ein Problem von FP. Nicht unseres". Naja, wenn ich keinen eigenen Compiler fertigkriege und auf FP aufsetze und das dann gebundelt als mein Produkt verkaufe bin cih sehr wohl dafür verarntwortlich. Hoffentlich wird es mit FM2 und den neuen Interfaces sowie Mobile Studio besser.

@maverik: Du baust Deine Masken und einige Login in Delphi, schickst das in XCode und debuggst dort. Das meiste weitere muss Cocoa- bzw. FP-spezifisch mit ifdefs in Delphi gemacht werden. Bzw. in XCode bearbeitet werden und eine Finale Version für den Shop darf auch keinesfalls mehr mit Delphi angefasst werden. Z.b. waren in XE2 die Embarcadero-Icons im Konvertierungstool hardcodiert bzw. als res enthalten. Sowas kannst Du natürlcih nicht als eigene App in den Shop stellen.

[stahli]

Ich habe mal das Projekt FireMonkeyControls ein wenig angeschaut. Leider gibt es allein dort diverse Probleme.

Laden des Jet-Styles funktioniert, ein nachträgliches Wechseln zu einem normalen Style führt zu einer Schutzverletzung. (Habe ich in der QC eingetragen.)

Auf einem XP-Rechner wird beim drehen des ClientBereiches der Bereich nicht mehr geskinnt. Bei einer größeren Formulargröße gibt es einen "Div by 0" Fehler und das Programm hängt.

Auf meinem Win7-Rechner funktioniert das Drehen, gelegentlich hängt das Programm aber dann. Eine Auflösung von 2500*1600 bremst den Formularaufbau natürlich gewaltig aus. Aber das kann man FM sicher nicht vorwerfen. Immerhin ist ja einiges zu zeichnen.

Ich sehe es leider (noch) kritisch, ernsthaft mit FM zu arbeiten, obwohl ich den Ansatz eigentlich lohnenswert finde.
Je größer und komplexer der Projektumfang und die Formulargrößen sind, um so ungünstiger ist wohl FM zu verwenden.