Firemonkey Workarounds

[Union]

Du könntest Versuchen, Delphi mit Delphi zu debuggen (Mit Prozess verbinden). Also zuerst den Debuggee starten, im Taskmanager die Prozeß-ID merken und dann Delphi nochmals als Debugger starten (aus der Kommandozeile mit Parameter /np) und mit der BDS.exe mit der zuvor gemerkten ID verbinden. Dann in die erste Instanz wechseln und Fehler verursachen, in die zweite Instanz umschalten und schauen, ob Du was siehst (z.B. BPL-Namen).

Mist, merke gerade das geht mit XE nicht mehr, ausser man startet bei mit /np.

[Harry Stahl]

Und wieder mal ein Mysterium gelöst...

Union, Deine Vermutung, es lag an den TMS-Komponenten, stimmte!!

Allerdings lag es nicht an den TMS-FMX-Komponenten, sondern an den TMS-VCL-Komponenten.

Als ich die defekte FMX speicherte und wieder lud, fiel mir auf, dass plötzlich folgende Einträge in der Form.pas-Datei drin waren:

GDIPCustomItem, GDIPTextItem, GDIPSectionItem,
GDIPImageSectionItem, GDIPHeaderItem;

Die gehören zu den TMS-VCL Komponenten und in der Unit GDIPHeaderItem ist auch eine Klasse "THeaderItem" drin. So kam es zu einem Konflikt. Wie das letztlich möglich sein kann, ist mir zwar ein Rätsel, aber gut.

Nachdem ich also die Packages der TMS-VCL-Komponenten deaktiviert hatte, konnte ich die Datei ganz normal laden.

So, jetzt muss ich das noch EMBA und TMS-Software erzählen... (na toll )

Wie war das eigentlich noch mal: Kann man Delphi nicht so einstellen, dass für bestimmte Projekte nur bestimmte Packages geladen werden? Dann könnte man das Problem vielleicht umgehen?

[Union]

Zitat von Harry Stahl:

Wie war das eigentlich noch mal: Kann man Delphi nicht so einstellen, dass für bestimmte Projekte nur bestimmte Packages geladen werden? Dann könnte man das Problem vielleicht umgehen?

Ja, aber die Packages müssen sich auch daran halten.

[Harry Stahl]

So, ich habe mal einen weiteren Workaround entwickelt und zwar für die fehlenden Hints in FireMonkey. Zwar hatte himitsu da auch schon mal was gemacht, das war aber eine Komponente und wenn ich das richtig sehe, wurde die nicht für XE4 bzw. XE5 weiterentwickelt (wenn ich hier was übersehen haben sollte, bitte Info).

Die Komponente von himitsu (eine tolle Leistung, wie ich finde) hatte zwar noch einige weitere Fähigkeiten, wie etwa Grafikanzeige im Hint. Aber ich denke für die meisten Anwendungsfälle wird das gar nicht benötigt und ich persönlich ziehe immer die Verwendung einfacher units vor, alles in einer Datei, da gibt es auch keine Probleme beim Wechsel von einer Delphi-Version zur nächsten (also nicht erneut Package / Komponenten installieren, usw).

Meine Lösung ist denkbar einfach (gerade mal 200 Zeilen) und bei Bedarf erweiterbar und funktioniert für XE2 bis XE5 sowohl unter Windows als auch auf dem MAC. Mann muss nur die Unit HS_FMXHints.pas in die jeweiligen Forms einbinden, wo man Hints verwenden möchte.

Im Oncreate-Ereignis der Form (oder in einer separaten Form-Procedure) setzt man dann die Hints mit einfachen Aufrufen wie

SetAHint (Button1, 'Dies ist ein Hint für Button1'); Bei Bedarf kann man vorgegebene Standardeinstellungen für die Hints mit der Procedure

SetHintSetting (TimeBeforeShow, TimeToShow: Integer; DynamicShow: Boolean; TC: TAlphaColor); überschreiben.

Bevor ich mir hier noch einen Wolf schreibe, verweise ich der Einfachheit halber auf ein kurzes Video, das ich auf YouTube gepostet habe.

Hier ist der Link: https://www.youtube.com/watch?v=eWGbhOexrJk

Die Lösung hat 1-2 kleinere Einschränkungen, wird im Video angesprochen.

Die Unit könnt Ihr frei verwenden wie Ihr wollt, Nutzung natürlich auf eigene Verantwortung.
Das Teil ist sicher noch ausbaufähig (und kann man wohl auch ein wenig "schicker" schreiben), aber ich denke, dennoch ganz nützlich, insbesondere, wenn man sonst keine Möglichkeit kennt, Hints in FMX-Anwendungen zu verwenden.

Ich gebe ja die Hoffnung nicht auf und erwarte das von Haus aus in einer der nächsten Delphi XE-Versionen.

Screenshot und Unit anbei.

[Harry Stahl]

Na, kaum gemacht, schon hat mich eine der "Einschränkungen" eingeholt. Ich benötige in einem Projekt doch die OnMouseEnter und OnMouseLeave Ereignisse, da wär es dann blöd, wenn die überschrieben werden.

Habe die HS_FMXHints.pas daher geändert, so dass eine Überschreibung nicht stattfindet, wenn für die Controls schon Events vorhanden sind:

Delphi-Quellcode:

procedure SetAHint (ic: TObject; txt: string);
begin
  if ic is TButton then begin
    TButton (ic).Hint := txt;
    if not Assigned (TButton (ic).OnMouseEnter) then TButton (ic).OnMouseEnter := EventEnter;
    if not Assigned (TButton (ic).OnMouseLeave) then TButton (ic).OnMouseLeave := EventExit
  end;

  if ic is TSpeedbutton then begin
    TSpeedButton (ic).Hint := txt;
    if not Assigned (TSpeedButton (ic).OnMouseEnter) then TSpeedButton (ic).OnMouseEnter := EventEnter;
    if not Assigned (TSpeedButton (ic).OnMouseLeave) then TSpeedButton (ic).OnMouseLeave := EventExit
  end;

  if ic is TLabel then begin
    TLabel (ic).Hint := txt;
    if not Assigned (TLabel (ic).OnMouseEnter) then TLabel (ic).OnMouseEnter := EventEnter;
    if not Assigned (TLabel (ic).OnMouseLeave) then TLabel (ic).OnMouseLeave := EventExit;
  end;
end;

In den dann bereits verwendeten Events muss man die Aufrufe auf die Hintunit selber ergänzen, also in

OnMouseEnter mit HintEnter (self, sender)
OnMouseLeave mit HintExit (self, sender)

Konkretes Beispiel:

Delphi-Quellcode:

procedure Tfrm_Main.sbNewMouseEnter(Sender: TObject);
begin
  TSpeedButton (sender).StyleLookup := 'sbNewStyle2';

  {$IFDEF MSWINDOWS}
  if AktFormStyle = 'ObsedianStyle' then begin
    TSpeedButton (sender).FontColor := TAlphaColors.Black;
  end;
  {$ENDIF}

  HintEnter (self, sender);
end;

procedure Tfrm_Main.sbNewMouseLeave(Sender: TObject);
begin
  TSpeedButton (sender).StyleLookup := 'sbNewStyle1';

  {$IFDEF MSWINDOWS}
  if AktFormStyle = 'ObsedianStyle' then begin
    TSpeedButton (sender).FontColor := TAlphaColors.White;
  end;
  {$ENDIF}

  HintExit (self, sender);
end;

Die aktualisierte Unit habe ich beigefügt.

[jaenicke]

Zitat von Harry Stahl:

Habe die HS_FMXHints.pas daher geändert, so dass eine Überschreibung nicht stattfindet, wenn für die Controls schon Events vorhanden sind:

Du könntest daraus auch eine Klasse machen und dir beim neu Zuweisen der Events die Original zugewiesenen schlicht merken.

Die viel sinnvollere Variante ist aber TVirtualMethodInterceptor zu benutzen und die Prozeduren MouseDown usw. direkt abzufangen ohne die Events überhaupt anzutasten...
http://docwiki.embarcadero.com/Libra...hodInterceptor
Denn die Events sollten wirklich nur für die direkte Benutzung einer spezifischen Komponente benutzt werden, nicht für so allgemeine Funktionalität.

// EDIT:
Höchstens ist die Frage, ob das ganze die Performance zu stark beeinträchtigt.