FireMonkey Problem

[arnof]

Hi,

ich mache gerade eine Anwendung die "überall" laufen soll, also in Firemonkey.

Nun erster Test mit Win = ok, Anroid Zugriffverletzung ......

Tokyo 10.2.x:

Warum: TMultiView, ich lasse es erscheinen und dann

Delphi-Quellcode:

procedure TCommonCustomForm.TriggerControlHint(const AControl: IControl);
var
  LHintString: string;
  LControl: IControl;
begin
  if AControl.HasHint then
    LControl := AControl
  else
    LControl := nil;
  if LControl <> FLastHinted then
  begin
    if Application.ShowHint and (LControl <> nil) then
    begin
      SetLastHinted(AControl);
      LHintString := AControl.GetHintString;
      if (AControl.GetHintObject = nil) or not (AControl.GetHintObject is THint) then
      begin
        SharedHint.SetHint(GetShortHint(LHintString));

SharedHint ist nil, dann knall es .....

Hint bei Button der auf dem Multiview ist entfernt nun gehts .....

[Uwe Raabe]

Soweit ich weiß, gibt es Hints nur bei Windows und MacOS. Aber das sollte jedenfalls nicht zu einem Fehler führen.

Kannst du das in einem Minimalprojekt reproduzieren und dafür einen QP-Eintrag anlegen?

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1407428)

Soweit ich weiß, gibt es Hints nur bei Windows und MacOS.

Jupp, Handy/Tablet hat ja praktisch keine Maus, bei welcher es ein "sinnvolles" MouseOver-Ereignis geben könnte.



FMX selber hat noch nicht lange Hints, daher wird dort bisher kaum jemand etwas eingetragen haben. Bei den Meisten ist somit HasHint nicht True und der nachfolgende Code wird nirgendwo ausgeführt und niemand könnte Fehler in diesen Funktionen entdecken.

[Uwe Raabe]

Um das alles etwas einfacher zu machen, könnte man eine Dummy-THintClass verwenden, die immer dann erzeugt wird, wenn keine andere Klasse registriert ist. Dann spart man sich überall die Überprüfung, ob SharedHint eventuell nil liefert. Wenn du mir den QP-Eintrag nennst, kann ich das im Comment unterbringen.

[arnof]

Zitat:

Zitat von Uwe Raabe (Beitrag 1407428)

Soweit ich weiß, gibt es Hints nur bei Windows und MacOS. Aber das sollte jedenfalls nicht zu einem Fehler führen.

Kannst du das in einem Minimalprojekt reproduzieren und dafür einen QP-Eintrag anlegen?

Das war ein Minimalprojet:

TMultiview

mit Toolbar und einem Button, der einen Hint hat

Auf einem Handy ist die Multiview ausgeblendet, sobald sie sichtbar wird gab es eine Schutzverletzung.

Wie ich oben geschrieben hatte, soll die Anwendung auf allen Plattformen laufen, also sind die Hints nicht sinnfrei, sondern bei Windows üblich.

[Uwe Raabe]

Probier mal folgenden Code in deinem Mainform:

Delphi-Quellcode:

type
  TDummyHint = class(THint)
  public
    procedure SetPosition(const X: Single; const Y: Single); override;
  end;

procedure TDummyHint.SetPosition(const X, Y: Single);
begin
end;

initialization
  THint.RegisterClass(TDummyHint);
end.

[Harry Stahl]

Zitat:

Zitat von himitsu (Beitrag 1407432)

FMX selber hat noch nicht lange Hints, daher wird dort bisher kaum jemand etwas eingetragen haben. Bei den Meisten ist somit HasHint nicht True und der nachfolgende Code wird nirgendwo ausgeführt und niemand könnte Fehler in diesen Funktionen entdecken.

FMX hatte schon von Anfang an Hint- und Showhint-Property, nur waren die als protected Property deklariert und es gab keine Behandlungsroutinge dafür. Mit meiner HS_FMXHints.pas unit (http://www.devpage.de/blog/firemonkey.htm, vgl. dort Beitrag 8) konnte man aber bis FMX2 runter Hints verwenden. Seit Delphi 10.1 sind die Hints öffentlich und werden auch behandelt.

Allerdings hat man selbst bei Delphi 10.2 bei einigen Komponenten "vergessen" diese Eigenschaften zu veröffentlichen, z.B. bei der TComboColorBox. Aber hier kann man bei Bedarf die entsprechenden Properties zur Laufzeit setzen, dann werden die auch angezeigt.

[Harry Stahl]

Zitat:

Zitat von arnof (Beitrag 1407425)

Hi,

ich mache gerade eine Anwendung die "überall" laufen soll, also in Firemonkey.

Nun erster Test mit Win = ok, Anroid Zugriffverletzung ......

Tokyo 10.2.x:

Warum: TMultiView, ich lasse es erscheinen und dann

Delphi-Quellcode:

procedure TCommonCustomForm.TriggerControlHint(const AControl: IControl);
var
  LHintString: string;
  LControl: IControl;
begin
  if AControl.HasHint then
    LControl := AControl
  else
    LControl := nil;
  if LControl <> FLastHinted then
  begin
    if Application.ShowHint and (LControl <> nil) then
    begin
      SetLastHinted(AControl);
      LHintString := AControl.GetHintString;
      if (AControl.GetHintObject = nil) or not (AControl.GetHintObject is THint) then
      begin
        SharedHint.SetHint(GetShortHint(LHintString));

SharedHint ist nil, dann knall es .....

Hint bei Button der auf dem Multiview ist entfernt nun gehts .....

Generell ist es kein Problem die Hint-Properties gesetzt zu haben, die werden auf den mobilen Plattformen einfach nicht berücksichtigt.

Ich weiß zwar nicht, was Du da überhaupt machst, aber Du solltest es genau so machen: Wenn Dein Code auf einer mobilen Plattform läuft, dann braucht er doch gar nicht ausgeführt werden, da dort keine Hints angezeigt werden. Kannst Du ja dann den Code mit den entsprechenden IFDEFS außen vor lassen...

[Uwe Raabe]

Zitat:

Zitat von Harry Stahl (Beitrag 1407462)

Generell ist es kein Problem die Hint-Properties gesetzt zu haben, die werden auf den mobilen Plattformen einfach nicht berücksichtigt.

In diesem Fall ist das aber ein Fehler in FMX. Der Zugriff auf SharedHint kann nil zurückliefern, da dort bei Bedarf THint.CreateNewInstance aufgerufen wird (eben um eine Instanz zu erzeugen). Allerdings sagt die Hilfe zu CreateNewInstance:

Zitat:

Returns an instance created by the first available registered class. This method can return nil if there are no classes registered or none of the registered classes can create a THint instance.

Es werden aber nur für Windows und MacOS solche Klassen registriert. Deswegen liefert SharedHint auf allen anderen Systemen nil und der Aufruf in TriggerControlHint verursacht eine Zugriffsverletzung.

Mein Code-Schnipsel weiter oben soll das beheben, in dem er eine Dummy-Klasse registriert, die in dem oben angesprochenen Fall einspringt.

[Harry Stahl]

Das Problem ist anscheinend immer noch nicht gefixt (also auch nicht in 10.3.1).

Nach einer verzweifelten Suche von mehreren Stunden nach einem unerklärlichen Fehler habe ich hier endlich dieses Problem für IOS und Android ausfindig machen können.

Wurde das von jemanden gemeldet?
Wenn nein, würde ich einen Eintrag machen.