Business-Anwendung mit FireMonkey erstellen

[CHackbart]

Ich kann arnof nur zustimmen. Der Mangel an Barrierefreiheit ist ein NoGo auf Desktopsystemen. Ich muss gestehen das ich das gerne mal verdränge, aber zumindest außerhalb von Tablet und Telefon sollte man das schon berücksichtigen. Nichtsdestotrotz bin ich gespannt wie deine Macversion aussehen wird. Vom Grundgedanke unterscheidet sich Mac und Windows ja in der Nutzerführung.

Hast du eigentlich das Problem mit der Menüleiste in den Griff bekommen? In XE5 musste ich ganz schön tricksen, damit das halbwegs nativ funktioniert.

[Harry Stahl]

Zitat von Stevie:

Auch in den einzelnen Eingabefenstern kann ich nicht mit nem Shortcut eine Seite weiter oder sowas (fehlende Accelerators auf den Buttons bzw fehlende Shortcuts auf den Actions dahinter).

Es ist doch ein fruchtbarer Dialog, den wir hier führen. Habe also einen weiteren "Workaround" erstellt, der jetzt die Unterstriche in den Buttons bzw. TTabItems im OnPaint-Event des jeweiligen Controls malt (siehe anliegenden Screenshot).

Im OnkeyDown-Event der Form prüfe ich dann, ob eine Alt+Buchstaben bzw. Alt+Ziffern Kombination gedrückt wurde und rufe dazu das passende Event dafür auf (also entweder ButtonClick oder Wechsel der Seite des TTabControls).

Ich muss da allerdings zu einem wirklich abenteuerlichen Trick greifen, dass bei der Alt+Tastenkombination nicht eine Tonausgabe in Form eines "beep" kommt. Den Wert von Key auf Null oder KeyChar auf #0 zu setzen bringt leider nichts. Das einzige was das "beep" vermeidet, ist kurzfristig den Focus an ein anderes modales Fenster abzugeben. Also erzeuge ich ein kleines Fenster, das ich außerhalb des sichtbaren Anzeigebereichs anzeigen lasse. Sofort schließt es sich wieder und der eigene Dialog hat wieder den Focus (das macht der Aufruf von "Killfocus").

Es sollte noch erwähnt werden, dass das "Beep" seltsamerweise nicht kommt, wenn man eine Alt-Key+Accelerator-Taste Abfrage in der Hauptform macht. In einem modalen Dialog kommt der Ton aber.

So sieht das im OnKeyDown-Event dann aus:

Code:

procedure Tf_Bill.FormKeyDown(Sender: TObject; var Key: Word; var KeyChar: Char;
  Shift: TShiftState);
begin
  if HandleTabEvent (self.GetFocused, Key, Shift) then exit;

  if key = vkEscape then close;

  if (Shift = [ssAlt]) then begin
    case Key of
      49..52: begin
        pc1.TabIndex := key-49;
        KillFocus (self);
      end;

      87: begin if bnWeiter.Enabled then begin bnWeiterClick(NIL); KillFocus (self); end; end;
      90: begin if bnBack.Enabled then begin bnBackClick(NIL); KillFocus (self); end; end;
      70: begin if bnReady.Enabled then begin bnReadyClick(NIL); KillFocus (self); end; end;
      72: begin bnHelpClick(NIL); KillFocus (self); end;
    end;
  end;

end;

Was übrigens seltsam ist, das Abfragen der Alt-Key-Taste funktioniert nur, wenn die Optimierung in Delphi ausgeschaltet ist. Schräg, oder?

Hat jemand vielleicht noch eine andere Idee, wie man das "beep" vermeiden kann? Die Lösung funktioniert zwar, aber ein leichtes Flackern ergibt sich und ehrlich gesagt, ist mir es ja ziemlich peinlich, so was machen zu müssen.

Das mit dem Malen des Accelerator-Zeichen erreicht man dann, indem man in dem jeweiligen Paintereignis folgende Prozedur aufruft:

procedure Tf_Bill.bnWeiterPaint(Sender: TObject; Canvas: TCanvas; const ARect: TRectF);
begin
DrawAccelerator (Sender, canvas, ARect);
end;

Das "&" Zeichen könnt Ihr in den Buttons wie gewohnt setzen (im TTabItem geht das leider nicht, da wird dann immer das erste Zeichen mit einem Unterstrich versehen).

Die DrawAccelerator procedure sieht aus wie folgt, derzeit werden TButton, TSpeedButton und TTabItem unterstützt. Könnt Ihr natürlich frei verwenden.

Code:

procedure DrawAccelerator (Sender: TObject; canvas: TCanvas; ARect: TRectF);
var
  tf: tfilltextflags;
  a: TTextalign;
  r: TRectF;
  T:  string;
  p: Integer;
  aw: extended;
  start, w: extended;
  col: TAlphaColor;
begin
  canvas.BeginScene;

  r := ARect;
  col := TAlphaColorRec.black;

  if sender is TButton then begin
    T := TButton(sender).Text;
    w := TButton(sender).canvas.TextWidth(T);
    if TButton(sender).Enabled = false then col := TAlphaColorRec.gray;
    
    case TButton(sender).TextAlign of
      TTextAlign.taCenter: start := (TSpeedButton(sender).Width -w) / 2;
      TTextAlign.taLeading: start := 1;
      TTextAlign.taTrailing: start := TSpeedButton(sender).Width -w;
    end;
  end;

  if sender is TSpeedButton then begin
    T := TSpeedButton(sender).Text;
    w := canvas.TextWidth(T);

    case TSpeedButton(sender).TextAlign of
      TTextAlign.taCenter: start := (TSpeedButton(sender).Width -w) / 2;
      TTextAlign.taLeading: start := 1;
      TTextAlign.taTrailing: start := TSpeedButton(sender).Width -w;
    end;

    if TSpeedButton(sender).Enabled = false then col := TAlphaColorRec.gray;
  end;

  if sender is TTabItem then begin
    T := TTabitem(sender).Text;
    w := canvas.TextWidth(T);

    case TTabItem(sender).TextAlign of
      TTextAlign.taCenter: start := (TSpeedButton(sender).Width -w) / 2;
      TTextAlign.taLeading: start := 8;
      TTextAlign.taTrailing: start := TSpeedButton(sender).Width -w;
    end;

    start := start + 10;
  end;

  if T = '' then begin
    canvas.EndScene; 
    exit;
  end; 

  P := pos ('&', T);

  aw := canvas.TextWidth(copy (T, 1, p));
  tf := [];

  a := TTextAlign.taLeading;
  r.Top := r.Top + 6;
  r.left := start + aw-7;

  canvas.Fill.Color := col;
  Canvas.FillText(r,'_',false,1,tf,a,a);
  canvas.EndScene;
end;

[Harry Stahl]

Zitat von CHackbart:

Hast du eigentlich das Problem mit der Menüleiste in den Griff bekommen? In XE5 musste ich ganz schön tricksen, damit das halbwegs nativ funktioniert.

Hast Du das schon berücksichtigt: http://www.devpage.de/blog/firemonkey-Teil5.htm ?

[arnof]

Mit negativ musste aber aufpassen. Ich habe z.B. 3 Monitore dran der Haupt ist die Mitte linke Monitor ist bei DElphi der negative in X Richtung, d.h. Ich würde hier dein Dummyfenster sehen


P.s. Trotzdem irgendwie V0.85 in vielem fühlt man sich echt in die 90'er zurückversetzt, prof. Entwickeln ist irgend wie anders...

Der Destop ist seit XE3 irgendwie stehen geblieben und es wird nicht besser werden, zumindestens nicht vor Oktober!

[Harry Stahl]

Zitat von arnof:

Mit negativ musste aber aufpassen. Ich habe z.B. 3 Monitore dran der Haupt ist die Mitte linke Monitor ist bei DElphi der negative in X Richtung, d.h. Ich würde hier dein Dummyfenster sehen

Ich habe auch 3 Monitore hier an meiner Hauptentwicklungsmaschine.

Bei dem von mir benutzen ".Left" Wert des Fensters von -8000 wird das wohl auf keinem derzeitigem Monitor angezeigt.

[Harry Stahl]

Zitat von arnof:

P.s. Trotzdem irgendwie V0.85 in vielem fühlt man sich echt in die 90'er zurückversetzt, prof. Entwickeln ist irgend wie anders...

Da stimme ich Dir zu.

Zitat von arnof:

Der Destop ist seit XE3 irgendwie stehen geblieben und es wird nicht besser werden, zumindestens nicht vor Oktober!

Das hört sich ja irgendwie nach Insiderwissen an. Das wäre ja wirklich schade.

[arnof]

Zitat von Harry Stahl:

Zitat von arnof:

Der Destop ist seit XE3 irgendwie stehen geblieben und es wird nicht besser werden, zumindestens nicht vor Oktober!

Das hört sich ja irgendwie nach Insiderwissen an. Das wäre ja wirklich schade.

Dazu musste nur in die öffentliche Roadmap schauen, da kann ich nichts Destopmäßiges entdecken.

Ich würde gerne was WINDOWS 8 mäßiges Erzeugen können, ist aber nicht ....

[greenmile]

Harry, wie immer Hut ab! Ich ziehe meinen Hut vor der Arbeit und auch vor Deinem Kampfgeist. Ich habe 2 größere Projekte mit Firemonkey realisiert, die ich hier nicht nennen möchte. Ich war am Ende froh wie nach nem Hausbau: Geschafft, aber niemals wieder. Die Probleme und der Aufwand waren mir einfach zu hoch und die ganze Sache war mir einfach zu unberechenbar (wenn es bei mir "knallt", was passiert dann erst beim Kunden?). Ich habe aufgegeben, was aber letztendlich daran lag, dass selbst Kinderkrankheiten nicht behoben werden. Die Einnahmen auf z.B. Mac Seite stehen kaum in einem Verhältnis zum Aufwand, den ich dafür betreiben muss.
Dabei kränkelt FMX nicht an unlösbaren Problemen, sondern hauptsächlich an Bugs, bei denen man sich einfach nur mit der Hand vor die Stirn schlagen muss weil man nicht versteht, wie so etwas passieren kann und wieso es keiner korrigiert.

Umso mehr ziehe ich meinen Hut vor Usern, die durchhalten.

[Union]

Um eines mal klarzu stellen: Wirklich eine tolle Leitung von Harry!

Ich versuche das seit es FMX gibt. Ich habe auch ständig den Bedarf nach Workarounds gehabt. Bin aber irgendwann an eine Stelle gekommen, wo ich im Grunde große Teile des FMX Sources hätte kopieren und überarbeiten müssen da eine halbwegs saubere Objektorientierte Beeinflussung von Fehlverhalten nicht mehr möglich war.

Mal ein Beispiel um einen von EMB hardcodierten Text zu übersetzen:

Delphi-Quellcode:

procedure TfrmTarget.TransLateListViewButton(const AItem: TListViewItem);
var
  LComponent : integer;
  AComponent : TComponent;
  ALayout    : TLayout;
  LButton    : integer;
  AButton    : TComponent;
begin
  // Suche des echten Buttons
  // ListItem->ListView->TLayout->TSpeedButton->StyleLookup = 'listitemdeletebutton'

  for LComponent := 0 to AItem.Parent.ComponentCount-1 do
  begin
    AComponent := AItem.Parent.Components[LComponent];
    if AComponent is TLayout then
    begin
      ALayout := TLayout(AComponent);
      for LButton := 0 to ALayout.ComponentCount-1 do
      begin
        AButton := ALayout.Components[LButton];
        if AButton is TSpeedButton then
        begin
          // Eigene Übersetzungsfunktion, da TLang nicht den richtigen Sprachcode holt
          TSpeedButton(AButton).Text := _T('Löschen');
        end;
      end;
    end;
  end;
end;

Das Verhältnis zwischen Nutzlast und solchem Korrekturcode bzw. auch Platform-Spezifischem Code beträgt nach meinen Erfahrungen ca. 3:1.


Ich benutze für Win32 Desktop weiterhin VCL. Umstellung auf FMX bringt mir nur Einschränkungen. Der Vorteil ist natürlich die gleiche Codebase (haha) für eine Mac-Anwendung nutzen zu können.

FMX wird hier nur für iOS und Android apps verwendet. Und das auch nur für relativ unwichtige und kleine Teilgebiete, die man zur Not in ein paar Tagen nach ObjC oder Java umgestrickt bekommt. Denn ich weiß ja nie, ob nicht plötzlich wieder etwas aus FMX herausfällt oder grundlegend geändert wird weil auc EMB erkennt dass man mit der Lösung in einer Sackgasse steckt (so geschehen bei der Umstellung von FPC auf LMAA).

Ich lasse mich aber gerne eines Besseren belehren. Deshalb bin ich gespannt auf die fertige Mac-App von Harrys Rechnungsprogramm - und vor allem den Erfahrungsbericht dazu.

[v2afrank]

Hallo Harry,
jetzt habe ich mir das Programm auch mal runtergeladen und etwas damit rumgespielt. Wenn ich eine Rechnung ausdrucken möchte bekomme ich folgende Fehlermeldung
---------------------------

---------------------------
Zugriffsverletzung bei Adresse 0095CAE8 in Modul 'PCRechnung.EXE'. Lesen von Adresse 00000058.
---------------------------
OK
---------------------------

Noch ein Nachtrag. Das war der Druckknopf der auf dem vierten Tabsheet angezeigt wird wenn ich eine Rechnung bearbeite

Eins ist mir auch noch aufgefallen. Hints. Da war ja was mit Firemonkey. Hast Du die absichtlich nicht reingenommen oder wegen Firemonkey. Ich habe mir natürlich nicht die Hilfe durchgelesen sondern einfach rumgespielt. Da waren mir die Bedeutung von einigen Hints nicht klar


Noch ein Fehler.
Ich habe kein Angebot angelegt. Wenn ich da auf Faxen gehe kommt ---------------------------
Pcrechnung
---------------------------
'' ist kein gültiger Gleitkommawert.
---------------------------
OK
---------------------------


Zur tastatursteuerung ist mir auch noch was aufgefallen. Keine Ahnung ob es an Firemonkey (habe ich nach einigen wenigen Tagen an die Seite gelegt)oder an Dir liegt, aber ich finde es nicht schön und trage das hier ein.
Dialog Artikel bearbeiten. Tabulatorreihenfolge falsch (Feld mehrwertsteuer wird beim Durchtippern mit Tab übersprungen)
Kein Navigieren mit Pfeiltaste Links Rechts.
Kein Abbruch des Dialoges mit Escape
Kein F1