FireMonkey Sammelthread

[stahli]

Das Leben Programmieren kann so einfach sein: AutoCapture :-)

Zitat:

Beschreibung: Gibt an, ob das Steuerelement Mausereignisse abfängt.

Wenn ein Steuerelement die Mausbotschft erhält, werden alle nachfolgenden Mausereignisse an dieses Steuerelement übergeben, bis der Benutzer die Maustaste loslässt.

Siehe auchFMX.Types.TControl.MouseDown

[stahli]

Ich setze eine TEdit-Ableitung in ein eigenes "Gitter" und reagiere auf bestimmte Tasteneingaben (z.B. schließen bei Enter oder ESC).
Auch auf Tab und Shift+Tab möchte ich selbst reagieren.
Die kommen aber als Tastenereignisse nicht an. Ich habe auch nichts gefunden, wo die behandelt werden.

Hat jemand einen Rat?

[Union]

Musst Du Keydown überschreiben und dort auf Key = vkTab abfragen.

[stahli]

KeyDown feuert bei Tab im FMX nicht.
Ich habe aber auch noch nicht gefunden, wo das vorher abgefangen wird.

Delphi-Quellcode:

procedure TssCellEdit.KeyDown(var Key: Word; var KeyChar: WideChar; Shift: TShiftState);
begin
  // CodeSite.Send(IntToStr(Byte(KeyChar)) + ' ' + IntToStr(Key) + ' ' + IntToStr(Integer(ssShift)));
  if ((Key = 13) or (Key = 27)) and (KeyChar = #0) and (Shift = []) then
    SelectParentCell(Self, True)
  else if (KeyChar = #0) and (Shift = []) then
  begin
    case Key of
      33: // PageUp
        if (CustomItemsBox <> nil) then
        begin
          CustomItemsBox.ShouldFocused := True;
          CustomItemsBox.MoveFocusPageUp;
        end
        else
          inherited;
      34: // PageDown
        if (CustomItemsBox <> nil) then
        begin
          CustomItemsBox.ShouldFocused := True;
          CustomItemsBox.MoveFocusPageDown;
        end
        else
          inherited;
...

[Union]

Ich meinte das Form...

[stahli]

Da feuert Tab auch nicht (würde dann auch nicht wirklich helfen, da das Gitter das eigentlich intern regeln soll).

Ich vermute, dass "die Plattform" das vorher abfängt, finde aber den tatsächlichen Ablauf nicht.

[Union]

Ich habs doch getestet. Wenn Du das Keydown im Form überschreibst, kommt dort Tab definitiv an.

[stahli]

Oh sorry, ich habe da geschummelt... :oops:
Beim Formular habe ich jetzt OnKeyDown verwendet. Da kommen Tastaturereignisse (wenn ein Edit den Focus hat) an, aber nicht ein Tab.
Insofern habe ich gefolgert, dass das auch im KeyDown so ist.

Überschreiben bringt mir nichts, ich will ja mein Gitter in normalen Formularen einsetzen können.
Aber ich werde mir morgen das FmxForm nochmal genauer ansehen, das muss ja (logisch gefolgert) den Tab dann eigenmächtig filtern und anders behandeln.
Danke für Deine geduldige Hilfe!

[Union]

Das passiert in TCommonCustomForm.Keydown. Dort ist eine Abfrage die dafür sorgt dass das focussierte Control KEINEN Key mitbekommt. Danach wird dann der Focus auf das nächste focussierbare Element gesetzt. Danach wird nur noch der OnCanFocus Event aufgerufen in TControl.GetCanfocus.

[Thom]

Und da ist es wieder - das unausgegorene FireMonkey-Konzept: Anstatt jedem Control eine Eigenschaft WantTabs zu spendieren (ist nun wahrlich keine neue Erfindung - gibt's auch schon bei einigen VCL Controls), die standardmäßig false liefert und die Abfrage in TCommonCustomForm.KeyDown so zu gestalten:

Delphi-Quellcode:

 if (Key = vkTab) and (not Assigned(FFocused) or (Assigned(FFocused) and not FFocused.WantTabs)) then
  [...]

Aber nö - Delphi-Programmierer brauchen so was nicht...

Ich kann allerdings nicht sagen, ob sich da in XE4 etwas getan hat, da ich dafür nur die Trial und damit keine Quelltexte habe.

[stahli]

Eigentlich müssten nur "focused handler" und "change focus" getauscht werden.
Dann könnte man Key auf 0 setzen wenn man vkTab selbst behandeln will.

Wenn das in XE4 noch nicht geändert ist werde ich mal einen QC-Eintrag schreiben.

Delphi-Quellcode:

procedure TCommonCustomForm.KeyDown(var Key: Word; var KeyChar: System.WideChar; Shift: TShiftState);
var
  List: TInterfaceList;
  i, CurIdx: Integer;
  TabDirection : Integer;
  FocusObj: TFmxObject;
  Done: boolean;
  FocusPopup: TCustomPopupMenu;
  lIsDialog: boolean;
  NewFocus: IControl;
  procedure TraverseChildren(Container: TFmxObject);
  var I: integer;
  begin
    if (Container is TControl) and
       (not TControl(Container).Enabled) then Exit;
    for I := 0 to Container.ComponentCount - 1 do
      if (Container.Components[I] is TCustomActionList) and
         (TCustomActionList(Container.Components[I]).DialogKey(Key, Shift)) then
      begin
        Done := True;
        Exit;
      end;
    if (Container.ChildrenCount > 0) then
      for I := 0 to Container.ChildrenCount - 1 do
      begin
        TraverseChildren(Container.Children[I]);
        if Done then
          Exit;
      end;
  end;
  procedure OtherForms(IsMain: boolean);
  var I, J: integer;
      F: TCommonCustomForm;
  begin
    if Done then Exit;
    for I := 0 to Screen.FormCount - 1 do
    if (Screen.Forms[I] <> self) and
       (Screen.Forms[I].Visible) and
       (IsMain xor (Screen.Forms[I] <> Application.MainForm)) then
    begin
      F := Screen.Forms[I];
      for J := F.ChildrenCount - 1 downto 0 do
      begin
        if F.Children[J] is TMainMenu then
          TMainMenu(F.Children[J]).DialogKey(Key, Shift);
        if Key = 0 then
        begin
          Done := True;
          Exit;
        end;
      end;
      TraverseChildren(F);
      if Done then Exit;
    end;
  end;
begin
  { dialog key }
  FocusPopup := nil;
  lIsDialog := False;
  IsDialogKey(Key, KeyChar, Shift, lIsDialog);
  try
    if lIsDialog then
    begin
      Done := False;
      // 1. perform key in Focus Control
      if Assigned(FFocused) then
      begin
        FFocused.DialogKey(Key, Shift);
        if Key = 0 then
          Exit;
        FocusObj := FFocused.GetObject;
      end
      else
        FocusObj := nil;
      // 2. perform key in PopupMenu of Focus Control
      if (FocusObj is TControl) then
      begin
        FocusPopup := TControl(FocusObj).PopupMenu;
        if FocusPopup is TPopupMenu then
        begin
          TPopupMenu(FocusPopup).DialogKey(Key, Shift);
          if Key = 0 then
            Exit;
        end
        else
          FocusPopup := nil;
      end;
      // 3. perform key in other Menus
      for i := ChildrenCount - 1 downto 0 do
      if Children[i] <> FocusPopup then
      begin
        if Children[i] is TMainMenu then
          TMainMenu(Children[i]).DialogKey(Key, Shift)
        else if Children[i] is TPopupMenu then
          TPopupMenu(Children[i]).DialogKey(Key, Shift);
        if Key = 0 then
          Exit;
      end;
      // 4. perform key in other, no focus controls
      for i := ChildrenCount - 1 downto 0 do
      if Children[i] <> FocusObj then
      begin
        if Children[i].IsIControl then
          Children[i].AsIControl.DialogKey(Key, Shift);
        if Key = 0 then
          Exit;
      end;
      // 5. perform key in all ActionLists in Childrens
      TraverseChildren(self);
      // 6. perform key in all main menus and ActionLists in other forms
      OtherForms(True);
      OtherForms(False);
      if Done then Exit;
    end;

    { change focus } // DANN DAS ******************************************************
    if (Key = vkTab) then
    begin
      NewFocus := nil;
      Key := 0;
      List := TInterfaceList.Create;
      try
        GetTabOrderList(List, True);
        if ssShift in Shift then
          TabDirection := -1
        else
          TabDirection := 1;

        CurIdx := List.IndexOf(FFocused);
        for i := 0 to List.Count-1 do
        begin
          Inc(CurIdx, TabDirection);
          if (TabDirection > 0) and (CurIdx >= List.Count) then
            CurIdx := 0
          else
          if (TabDirection < 0) and (CurIdx < 0) then
            CurIdx := List.Count - 1;

          if IControl(List[CurIdx]).CheckForAllowFocus then
          begin
            NewFocus := IControl(List[CurIdx]);
            break;
          end;
        end;
      finally
        FreeAndNil(List);
      end;
      if Assigned(NewFocus) then
        NewFocus.SetFocus;
      Exit;
    end;

    { focused handler }  // ERST DAS *****************************************************
    if ((Key <> 0) or (KeyChar <> #0)) then
    begin
      if Assigned(FFocused) then
        FFocused.KeyDown(Key, KeyChar, Shift);
      if Assigned(FOnKeyDown) then
        FOnKeyDown(Self, Key, KeyChar, Shift);
    end;
  finally
    Application.FLastKeyPress := Now;
    Application.FLastUserActive := Application.FLastKeyPress;
  end;
end;

[Thom]

Oder so. :thumb:

[Darlo]

Entweder stelle ich mich ziemlich an oder das mit den Gesten ist nicht ganz durchdacht.

An sich ganz simpeler Programmablauf.

Tabcontrol mit paar Tabitems und jeweils einer TabChangeAction.
Die entsprechenden Actions zum Einblenden des richtigen Tabs sollen per link/rechts wischen ausgeführt werden.
Soweit so gut. Jetzt kam ich aber auf die absurde Idee sowohl TSwitche wie TTRackbars zu verwenden ;-)
Wenn man diese bedient wird leider die Action zur Navigation ausgeführt.
Bei Switch konnte ich das über eine Funktion die im MouseDown und MouseUp gesteuert wird umgehen. Wie soll man das aber bitte bei einer Trackbar machen????

[stahli]

Ich erzeuge aus der Datenschicht AniIndicators auf gebundenen GUI-Controls um eine längere Beschäftigung anzuzeigen.

Sichtbar werden diese erst durch Application.ProcessMessages. Und dann wird nix animiert, solange die Anwendung beschäftigt ist.
Zu laufen beginnen sie wenn der Prozess fertig ist und ich die AniIndicators nicht zerstöre.

Gibt es dazu Tipps?

Mann, Mann, Mann, da denkt man, man hat eine schöne tolle neue und leistungsfähige GUI...

Delphi-Quellcode:

procedure TssCtrl.StartAniIndicator;
begin
  if Owner is TControl then
  begin
    fAniIndicator := TAniIndicator.Create(Owner);
    fAniIndicator.Align := TAlignLayout.alCenter;
    fAniIndicator.Parent := (Owner as TControl);
    fAniIndicator.Enabled := True;
    RefreshData;
    Application.ProcessMessages;
  end;
end;

procedure TssCtrl.EndAniIndicator;
begin
  FreeAndNil(fAniIndicator);
  RefreshData;
end;

[Thom]

Ist doch ganz "einfach": :-D

Delphi-Quellcode:

type
  TFormHelper = class helper for TForm
    procedure PaintRects(const UpdateRects: array of TRectF);
  end;

procedure TFormHelper.PaintRects(const UpdateRects: array of TRectF);
begin
  inherited;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Time: Cardinal;
begin
  AniIndicator1.Visible:=true;
  AniIndicator1.Enabled:=true;
  try
    Time:=TThread.GetTickCount;
    while TThread.GetTickCount-Time<=5000 do //<- 5 Sekunden Blockierung des Hauptthreads
    begin
      Sleep(100);
      if Assigned(AniThread) 
        then AniThread.OnTimer(nil); //<- Animation(en) am Leben erhalten
      PaintRects([AniIndicator1.ParentedRect]); //<- Indikator neu darstellen
    end;
  finally
    AniIndicator1.Visible:=false;
    AniIndicator1.Enabled:=false;
  end;
end;

Natürlich ist wieder alles so verpackt (im Implementationteil deklarierte Objekte, im protected-Abschnitt versteckte Methoden), daß man auf "normalem" Weg nicht richtig herankommt. Und (T)AniThread ist unter Windows selbstverständlich kein Thread (wäre ja auch sehr naiv, so etwas aus dem Namen zu schlußfolgern), sondern ein normaler Timer, der logischerweise nicht funktioniert, wenn die Nachrichtenschleife blockiert ist.

Wenn ich dann so was

Delphi-Quellcode:

destructor TAniIndicator.Destroy;
begin
  if Assigned(FFill) then
    FreeAndNil(FFill);
  inherited;
end;

und so was

Delphi-Quellcode:

var
  [...]
  AniThread: TTimer;

sehe, weiß ich wieder, wo das durchdachte Design herkommt... :lol:

[stahli]

@Thom
Danke! Das schaue ich mir heute Abend mal an.

Da kommt mir wieder der Vergleich zu einer Spieleentwicklung in den Sinn (http://www.delphipraxis.net/175033-f...-schlecht.html). Wenn da ein Alientreffer verarbeitet würde bleiben doch die anderen Kugeln auch nicht ein paar Sekunden unbewegt in der Luft hängen. Echt zum :kotz:

Eine flüssige Progressbar braucht ja wohl auch entsprechende Klimmzüge. (Es gab mal einen Hinweis dazu, finde ich aber gerade nicht auf die Schnelle.)


...man sollte halt wohl doch auf den FireDog warten, der den Affen auf den Baum jagt... :cry:

Das schlimme ist ja, wenn man allein hier aus der DP ein paar Leute zusammensuchen könnte würde ein ähnliches aber vernünftig umgesetztes Konzept echt Spaß bringen.

Sobald ich im Lotto gewinne miete ich eine Garage...
(Alternative zu den LB habe ich ja schon. :) )

[greenmile]

Offtopic: Ich habe meine Firemonkey Entwicklungen erstmal auf Eis gelegt; bis das Teil endlich rund läuft. Ich denke, mit XE5 (oder halt Android) aktiviere ich es wieder, aber bis dahin kann und will ich mich leider nicht mehr damit rumschlagen. Schade, aber selbst meine Mac Projekte laufen nur mehr schlecht als recht und mit sehr sehr viel Gepfusche :(

[stahli]

Als TIdleIndicator würde das Ding (TAniIndicator) andererseits perfekt arbeiten.
Es rödelt nämlich sofort los, wenn die Anwendung gerade nix tut.
:wall:

[Darlo]

Zitat:

Zitat von stahli (Beitrag 1221605)

Als TIdleIndicator würde das Ding (TAniIndicator) andererseits perfekt arbeiten.
Es rödelt nämlich sofort los, wenn die Anwendung gerade nix tut.
:wall:

:thumb:

[cookie22]

Zitat:

Zitat von greenmile (Beitrag 1221459)

...Ich denke, mit XE5 (oder halt Android) aktiviere ich es wieder, aber bis dahin kann und will ich mich leider nicht mehr damit rumschlagen...

Wenn mit XE5 dann Android kommen sollte, musst du aber noch mindestens bis XE8 warten um es produktiv nutzen zu können. :P

[stahli]

Genau genommen fällt mir letztlich nur ein Grund für den aktuellen TAniIndicator ein:

Damit David I. in den früheren Werbevideos stolz eine Animationskomponente präsentieren kann, so dass die potentiellen Käufer natürlich unterstellen, dass man damit irgendwelche Aktivitäten der eigenen Anwendung darstellen kann.

Ich glaube inzwischen nichts mehr, was Emba präsentiert.
So verarscht habe ich mich noch von keiner anderen Firma gefühlt.

[Union]

Naja, jetzt gibt es ja die Umfrage. Die kannst Du ja entsprechend ausfüllen.

[Thom]

Seid mal nicht ganz so streng. :wink:

Auch in der VCL funktioniert die grafische Ausgabe nicht, solange die Nachrichtenverarbeitung blockiert wird. Hier hilft ja bekanntlich der Aufruf von

Delphi-Quellcode:

Application.ProcessMessages

, was auch unter FireMonkey möglich ist. Dann werden auch alle Animationen abgearbeitet und Veränderungen des Formulars sichtbar gemacht.

Wer aus irgendwelchen Gründen

Delphi-Quellcode:

Application.ProcessMessages

nicht verwenden möchte (zum Beispiel, damit der Anwender nicht inzwischen wild auf dem Formular herumklicken kann) könnte auch folgenden Classhelper verwenden, der nur die Animationen weiterlaufen läßt und veränderte Elemente aktualisiert:

Delphi-Quellcode:

type
  TCustomFormHelper = class helper for TCustomForm
    procedure Repaint;
  end;

procedure TCustomFormHelper.Repaint;
var
  N: Integer;
  UpdateRect: TRectF;
  Child: TFmxObject;
begin
  if Assigned(FMX.Types.AniThread) and Assigned(FMX.Types.AniThread.OnTimer)
    then FMX.Types.AniThread.OnTimer(nil);
  if ChildrenCount>0 then
  begin
    UpdateRect:=TRectF.Empty;
    for N:=0 to ChildrenCount-1 do
    begin
      Child:=Children[N];
      if (Child is TControl) and not TControl(Child).UpdateRect.IsEmpty then
      begin
        if UpdateRect.IsEmpty
          then UpdateRect:=TControl(Child).UpdateRect
          else UpdateRect.Union(TControl(Child).UpdateRect);
      end;
    end;
    if not UpdateRect.IsEmpty
      then PaintRects([UpdateRect]);
  end;
end

Verwendet werden könnte er wie in meinem ersten Beispiel:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Time: Cardinal;
begin
  AniIndicator1.Visible:=true;
  AniIndicator1.Enabled:=true;
  try
    Time:=TThread.GetTickCount;
    while TThread.GetTickCount-Time<=5000 do
    begin
      Sleep(50);
      Label1.Text:=FloatToStr(TThread.GetTickCount-Time);
      Repaint;
      //Application.ProcessMessages;
    end;
  finally
    AniIndicator1.Visible:=false;
    AniIndicator1.Enabled:=false;
  end;
end;

P.S.:
TProgressBar funktioniert damit übrigens auch ohne Probleme! :-D

[fgsoftware]

Zitat:

Zitat von cookie22 (Beitrag 1221625)

Zitat:

Zitat von greenmile (Beitrag 1221459)

...Ich denke, mit XE5 (oder halt Android) aktiviere ich es wieder, aber bis dahin kann und will ich mich leider nicht mehr damit rumschlagen...

Wenn mit XE5 dann Android kommen sollte, musst du aber noch mindestens bis XE8 warten um es produktiv nutzen zu können. :P

Mit XE 5 kommt hoffentlich erst einmal eine vernünftige Unterstützung für Firemonkey für Win/OS/iOS.

Und ich hoffe bei Emba mahlt schon mal jemand die neuen Styles für iOS 7.

Wenn dass dann alles vernünftig läuft, können dann von mir aus noch andere Plattformen zukommen.

Ich glaube aber, am Ende wird wohl nichts Halbes und nichts Ganzes dabei herauskommen.

Aber es wird wahrscheinlich so sein, dass Emba im nächsten Jahr stolz die Unterstützung für Android und Windows 8 präsentiert.

Am Ende wir man dann mit Firemonkey auf so ziemlich allen Plattformen eine Fish Fact-Demo zum laufen kriegen, und der Rest ist für die Hühner.

[Thom]

Ich habe gerade beim Lesen der (XE3-)FireMonkey-Quelltexte einen neuen Geniestreich der Entwickler entdeckt:

Delphi-Quellcode:

unit FMX.Platform.Win;

function WndProc(hwnd: HWND; uMsg: UINT; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
[...]
begin
[...]
        WM_LBUTTONUP:
          begin
            [...]
              GetCursorPos(P);
              ScreenToClient(Wnd, P);
              LForm.MouseUp(TMouseButton.mbLeft, KeysToShiftState(wParam), P.X, P.Y);
            end;
          end;
[...]
end;

Da ist doch tatsächlich jemand auf die Idee gekommen, die Koordinaten aller (!!!) Mausereignisse per

Delphi-Quellcode:

GetCursorPos()

zur ermitteln, statt aus lParam auszulesen. Im Klartext bedeutet das, daß nicht die tatsächlichen Koordinaten - zum Beispiel bei einem Klick - geliefert werden, sondern die, die bei der Auswertung der Nachricht aktuell sind. Das hat zur Folge, daß bei schnellen Bewegungen oder Verzögerungen auf Grund eines stark beanspruchten Hauptthreads reale und per Ereignishandler gelieferte Werte meilenweit auseinanderliegen können.
Genial! :thumb:

[Union]

Diese Genialität steckt auch noch in XE4. Viel besser jedoch sind die dort enthaltenen TODOs sowie auskommentierten Korrekturversuche.

Zitat:

Hey, hört mal auf zu programmieren, das Marketing hat RTM definiert!

[sh17]

Wie, das Zitat steht auf deutsch im Quelltext? Ist ja "toll".

[mkinzler]

Zitat:

Und ich hoffe bei Emba mahlt schon mal jemand die neuen Styles für iOS 7.

Stylesmehl als Goodie :stupid:

[stahli]

Zitat:

Zitat von Union (Beitrag 1221629)

Naja, jetzt gibt es ja die Umfrage. Die kannst Du ja entsprechend ausfüllen.

Wo findet man die?

[mkinzler]

http://www.delphipraxis.net/175723-t...ey-2013-a.html

[stahli]

@Thom

Ohne ProcessMessages klappt das bei mir nicht.
Anbei mal ein Testprojekt (XE3, ohne Exe) im Baustellenstatus.

Ich habe auch mal versucht, das Refresh in einen Thread zu packen.
Aber auch hier wird man ohne Syncronisation nicht weiter kommen.
In dem Fall könnte aber Invalidate reichen, wie ich es in meinem Framework einsetze.

[Thom]

@Stahli

Mit Threads sollte das nicht funktionieren. Soweit ich weiß, ist die GUI von FireMonkey auch nicht threadsicher. Sie baut unter Windows ebenfalls auf GDI auf, auch wenn einige Renderaufgaben von der Grafikkarte übernommen werden. Die vorgerenderten Abschnitte werden dann aber wieder als Bitmap zurück in den Hauptspeicher geholt und "ganz normal" angezeigt. Meiner Meinung nach ist dieses Konzept auch der Hauptgrund, weshalb trotz GPU-Unterstützung die Framerate unter FireMonkey so - ähmmm - verbesserungswürdig ist. Falls ich das falsch verstanden habe, kann mich jemand gern korrigieren. Ich hatte mir dieses Prinzip vor allem bei den Filtern bzw. Effekten angeschaut.

Um also die Oberfläche eines Formulars während lang andauernden Aktionen nicht einfrieren zu lassen, muß die Aktualisierung aktiv angestoßen oder die blockierenden Aktionen in einen Thread ausgelagert werden. In dieser Beziehung unterscheiden sich VCL und FireMonkey nicht.

Die Synchronisation von Threads geschieht über das Senden von Nachrichten:

Delphi-Quellcode:

unit FMX.Platform.Win;

procedure TPlatformWin.WakeMainThread(Sender: TObject);
begin
  if TThread.CurrentThread.ThreadID <> MainThreadID then
    PostMessage(FThreadSyncHandle, WM_NULL, 0, 0);
end;

Und solange diese nicht (vom Hauptthread) abgeholt werden, passiert hier ebenfalls nichts.

Ich schaue mir mal Dein Testprojekt an.

Ok. Gerade gemacht. Funktioniert doch auch ohne ProcessMessages... Das Problem in Deiner Demo ist, daß Du ProgressBar1.Max auf 100000 setzt. Damit da etwas Sichtbares passiert, brauchst Du einige Liter Kaffee.
Mit Sleep(50) hast Du rund 20 Schritte pro Sekunde. Macht für den gesamten Fortschrittsbalken 100000/20=5000 Sekunden oder 83,3 Minuten. :lol:

[stahli]

@ Thom

Danke für Deine Mühe.
Bin gerade noch mit meinem neuen Rechner beschäftigt. Delphi installiere ich als nächstes mit.

In meinem Testprojekt hatte ich zuerst nur ein Label getestet. Aus dem Test stammt die hohe Durchlaufzahl.
Da habe ich ohne ProcessMessages keinen Fortschritt gesehen. Später dann mit Progressbar und AniIndicator auch nicht.
Vielleicht hängt das auch von der Grafikkarte oder Leistungsfähigkeit des Systems ab?

Die Abläufe im FMX habe ich teilw. auch mal nachvollzogen, aber dann schnell aufgegeben.
Es wirkt alles sehr umständlich bis planlos.

[Thom]

@Stahli

Entschuldige bitte die verspätete Antwort - ich wurde in den vergangenen Tagen anderweitig beansprucht... :-D

So ein Schrott: Das scheint tatsächlich von der Grafikkarte/dem Betriebssystem abhängig zu sein. Bei meinem Netbook funktioniert das Update des Formulars ebenfalls nicht. Da muß ich noch mal etwas Zeit investieren, um dem Problem auf den Grund zu gehen.

[stahli]

Zitat:

Zitat von Thom (Beitrag 1222157)

Entschuldige bitte die verspätete Antwort - ich wurde in den vergangenen Tagen anderweitig beansprucht... :-D

Klingt so, als dürfte man sich für Dich freuen, was hiermit getan sei. :-)

Zitat:

Zitat von Thom (Beitrag 1222157)

So ein Schrott: Das scheint tatsächlich von der Grafikkarte/dem Betriebssystem abhängig zu sein. Bei meinem Netbook funktioniert das Update des Formulars ebenfalls nicht. Da muß ich noch mal etwas Zeit investieren, um dem Problem auf den Grund zu gehen.

Naja, ich weiß nicht ob sich das wirklich lohnt. Jemand mit Kompetenz und Interesse müsste denen wohl FMX abkaufen und komplett überarbeiten.
Alles andere wird Stückelei, wo man auch wieder nicht weiß, in welchen Fällen die Flicken helfen und wo nicht.

Ich werde erst mal mein Framework weiter mit FMX entwickeln aber mit einer möglichst reduzierten GUI.
Ich behalte aber unbedingt im Blick, das Ganze mal auf VCL (und/oder FMY?) zu portieren.

[stahli]

Zitat:

Zitat von Thom (Beitrag 1222157)

So ein Schrott: Das scheint tatsächlich von der Grafikkarte/dem Betriebssystem abhängig zu sein. Bei meinem Netbook funktioniert das Update des Formulars ebenfalls nicht. Da muß ich noch mal etwas Zeit investieren, um dem Problem auf den Grund zu gehen.

Nee, es ist doch alles in Ordnung. Man braucht nur ein Win8 64bit und FMX refresht super - wenn man zu Hilfsmitteln greift.
Wenn es auf bestimmten Systemen doch nicht unter Win8 64bit klappt, kann ich noch meine anderen Systemkomponenten aufzählen.
Aber inzwischen wird ja ohnehin fast nur noch für iPhone entwickelt, jedenfalls dem Eindruck nach...