FMX+Crossplatform+Hilfe anzeigen

[TigerLilly]

Wie handhabt Ihr das mit Hilfe oder andere Info anzeigen bei Crossplatform? Welches Format bevorzugt Ihr und wie bindet Ihr das ein? Und womit erstellt Ihr das?

Danke für Info!

[himitsu]

Wir nutzen Help&Manual und lassen die HTML-Hilfe erzeugen.

Das ist jetzt zwar VCL, aber prizipiell ist es ja egal, ob man Application.OnHelp benutzt, oder z.B. im Form.KeyPreview auf VK_F1 reagiert.



Bei uns, im zentralen ApplicationServer/WindowsService läuft, ein TIdHTTPServer (aber egal was), der unsere Hilfe ausliefert.
Es ginge auch direkt im Programmverzeichnis oder auf einer Freigabe (SMB), aber der IE/Edge stufen standardmäßig das Intranet als unsicher ein (z.B. JS und CSS wird dabei krankhaft blockiert),
aber irgendein dubioser WebServer gilt dagegen als sicher.
(Help&Manual bietet auch eine eigene WebServer-App, für dieses Problem, aber zumindestens "damals" war Jene einfach nur grauenhaft und man mußte dringend von deren Nutzung abraten, weil sicherheitstechnisch öffnete sie Scheunentore, so groß wie die Erde)

Man könnte die Dateien sogar als Ressource in eine EXE/DLL linken und dann via res-Protokoll.


Bei uns steht die Verlinkung/Zuordnung in einer synchronisierten Datenbanktabelle, also z.B. FormName + optional der CompnentName
oder HelpKontext (selten) direkt an Komponenten oder Menüs/Dialogen (nicht HelpIndex, weil wilde Nummern sind ja nichtssagend)
oder manuell im Code ein Application.HelpKeyword('...');
und in der Hauptform (oder z.B. einem zentralen Datenmodul) dann TApplicationEvents drauf und dort im OnHelp die Behandlung.
-> also wenn jemand F1 drückt, dann vom AciveControl, über die übergeordneten Panels/GroupBoxen/TabSheets, bis zur Form schauen, ob/wo etwas zugewiesen ist und das Erste anzeigen
-> entweder in einen programminterne TWebBrowser oder an den Default-WebBrowser im System

Also gespeichert ist hier in der DB das Objekt (FormName/ComponentName) und dazu dann der nur Name der Hilfeseite (ohne HTML) oder alternativ eine URL (z.B. in unser Redmine)



PS:
https://docwiki.embarcadero.com/RADS...TML-Hilfetypen
https://www.delphi-treff.de/tutorials/tools/html-hilfe/
https://stackoverflow.com/questions/...my-application
...


Der Hilfe-Button von TaskDialog, MessageDlg usw. bietet leider nur den HilfeIndex.
(aber die VCL-Version dieser Dialoge kann man "hacken" und dem VCL-Button einen HelpKontext zuweisen)



Hier ein Auszug, als Demo, wie man selber auf das F1 reagiert und dessen Infos interpretiert.

Delphi-Quellcode:

{$IFDEF VER220 DelphiXE}
function THelpModul.ApplicationEvents1Help(Command: Word; Data: Integer; var CallHelp: Boolean): Boolean;
{$ELSE}
function THelpModul.ApplicationEvents1Help(Command: Word; Data: NativeInt; var CallHelp: Boolean): Boolean;
{$ENDIF}
const
  cIndex = 'index';
var
  Log, HomePath, HelpPath, Browser, Params, Link, Anker, S: string;
  Internal: (iIExplore, iDefault, iExtern);
  OverrideLink, B: Boolean;
  C, C2: TWinControl;
  F: TCustomForm;
  i: Integer;
begin
  Log := '';
  try
    {$REGION 'originalen Hilfeaufruf loggen'}
    case Command of
      HELP_CONTEXT:      S := ' - HELP_CONTEXT (Display topic in ulTopic)';
      HELP_QUIT:         S := ' - HELP_QUIT (Terminate help)';
      HELP_INDEX:        S := ' - HELP_INDEX/HELP_CONTENTS (Display index)';
      HELP_HELPONHELP:   S := ' - HELP_HELPONHELP (Display help on using help)';
      HELP_SETINDEX:     S := ' - HELP_SETINDEX/HELP_SETCONTENTS (Set current Index for multi index help)';
      HELP_CONTEXTPOPUP: S := ' - HELP_CONTEXTPOPUP';
      HELP_FORCEFILE:    S := ' - HELP_FORCEFILE';
      HELP_CONTEXTMENU:  S := ' - HELP_CONTEXTMENU';
      HELP_FINDER:       S := ' - HELP_FINDER';
      HELP_WM_HELP:      S := ' - HELP_WM_HELP';
      HELP_SETPOPUP_POS: S := ' - HELP_SETPOPUP_POS';
      HELP_KEY:          S := ' - HELP_KEY (Display topic for keyword in offabData)';
      HELP_COMMAND:      S := ' - HELP_COMMAND';
      HELP_PARTIALKEY:   S := ' - HELP_PARTIALKEY';
      HELP_MULTIKEY:     S := ' - HELP_MULTIKEY';
      HELP_SETWINPOS:    S := ' - HELP_SETWINPOS';
      else               S := '';
    end;
    Log := Log + Format('CallHelp: Command=%d%s   Data=%d'#10, [Command, S, Data]);
    if Command = HELP_COMMAND then
      Log := Log + '   Keyword/JumpID="' + PChar(Data) + '"'#10
    else if (Command = HELP_CONTEXT) or (Command = HELP_CONTEXTPOPUP) then
      Log := Log + '   ContextID=' + IntToStr(THelpContext(Data)) + #10
    else
      Log := Log + '   Keyword/ContextID/JumpID nicht erkannt'#10;
    {$ENDREGION}

    {$REGION 'nicht alle Komandos verarbeiten (z.B. wird beim F1 ein HELP_SETPOPUP_POS vor dem HELP_COMMAND aufgerufen)'}
    //if not (Command in [HELP_INDEX, HELP_CONTEXT, HELP_COMMAND, HELP_WM_HELP, HELP_QUIT]) then
    //  Exit(True);
    case Command of
      HELP_INDEX, HELP_CONTEXT, HELP_CONTEXTPOPUP, HELP_COMMAND, HELP_WM_HELP, HELP_QUIT: ;  // mit CASE, da IN einen zu kleinen Wertebereich zur Verfügung stellt
      else Exit(True);
    end;
    {$ENDREGION}

    {$REGION 'HELP_QUIT: das Hilfefenster soll geschlossen werden'}
    if Command = HELP_QUIT then begin
      FreeAndNil(FormWebBrowser);
      Exit(True);
    end;
    {$ENDREGION}

    ...
 
  finally
    TDM1.LogEvent(Trim(Log));

    {$REGION 'weitere Behandlung der Hilfe (F1) abbrechen'}
    Result   := True;
    CallHelp := False;
    ApplicationEvents1.CancelDispatch;
    {$ENDREGION}
  end;
end;

[Rollo62]

Zitat von himitsu:

Wir nutzen Help&Manual und lassen die HTML-Hilfe erzeugen.

HM ist super, aber egal womit, ich würde auch immer auf HTML gehen.
Es gibt auch die Argumente dagegen, dass manche Kunden keinen Browser installiert haben oder haben dürfen, aber das sind wohl Spezialfälle.

Alternativ dazu ginge dann auch noch PDF, wobei diese Kunden dann wohl auch keinen AdobeReader erlauben.

[himitsu]

Zitat von Rollo62:

Alternativ dazu ginge dann auch noch PDF, wobei diese Kunden dann wohl auch keinen AdobeReader erlauben.

Das ist doch heute in vielen Browsern integriert ... obwohl, neee


CHM ist intern auch "nur" HTML, aber für diese "zip"artige Datei braucht man einen Viewer, der auch nicht mehr vorinstalliert ist.

RTF ginge dann noch ... zumindestens im Windows (k.A. ob andere Systeme einen Viewer/Programm ala WordPad standardmäßig mit dabei haben)




Wie gesagt, bei uns kann man das einstellen, also ob im StandardBrowser (ShellExecute) oder in einer internen TForm mit TWebBrowser
oder gezielt in einem externem Programm (z.B. direkt Firefox aufgerufen und als Parameter übergeben)

Anfangs hatten auch Mehrere den internen TBrowserBrowser genommen, weil sie keinen Externen wollten, aber ich glaub aktuell nutzen alle ihren Standardbrowser.

Einige gehen sogar direkt auf unsere OnlineHilfe, also "unseren" AppServer, anstatt den Eigenen (obwohl der ja dennoch vorhanden ist, für andere Dinge, ala DMS und einige Hintergrundaufgaben).

[Alexander Halser]

Zitat:

Wie handhabt Ihr das mit Hilfe oder andere Info anzeigen bei Crossplatform?

Dieser Thread ist zwar schon ein paar Wochen alt, aber vermutlich nichtsdestoweniger aktuell. Ich bin der Chefentwickler von Help+Manual, welches hier gelobt wird (danke für die Blumen).

Das Thema platform-unabhängige Hilfe beschäftigt uns ja schon lange. Und da wir in wenige Monaten unsere erste "größere" MacOS-Anwendung rausbringen werden, stehen wir nun selber, ganz praktisch, vor dem Problem: wie machen wir's denn?

Für eine cross-platform Anwendung möchte ich 1 Hilfeformat, nicht verschiedene. Dieses eine Format heißt ganz klar HTML (oder in Help+Manual: WebHelp). Macht H&M ja auch ganz wunderbar, navigierbar, mit Volltextsuche. Entweder ist die Hilfe online, oder lokal im Programm mit dabei. Die meisten Mac-Anwendungen scheren sich nicht viel um die Doku, da gibt es einen Menüeintrag, der verlinkt auf die Webseite, fertig. Eine kontextsensitive Hilfe klappt so aber nicht. Ja, die Webhelp-Ausgabe von H&M unterstützt kontextsensitive Aufrufe. Aber das Programm hat keine Kontrolle über das Browser-Fenster und mit jedem Aufruf erzeugt dieser ein neues Tab... Standardbrowser können wir also vergessen, für eine funktionierende Programm-Hilfe benötigen wir die Kontrolle über den Hilfe-Viewer.

Dazu kommt das Format selbst: eine mittelgroße Doku enthält schnell mal mehrere hundert Dateien. Kann man in einen Ordner packen und mit dem Setup ausliefern. Zum Glück unterstützt der Project-Deployment-Dialog in Delphi auch Wildcards und rekursive Ordner... wie hab ich mich gefreut, als ich endlich die 387 Einzeldateien in meinem MacOS-App-Bundle drin hatte! </Ironie Ende >

Ich hätte gerne das HTML in einem komprimierten Container, einer einzigen Datei. Zwecks einfacheren Verteilens, und einfacheren Öffnens und überhaupt, der Ordnung wegen.

Damit es das endlich gibt, haben wir das nun gebaut.
Wir haben es Ziphelp genannt.

Ein "Ziphelp" ist eine Zip-Datei mit beliebigen HTML Inhalten, sprich: einer kompletten Web-Anwendung. Ergänzt um eine gewöhnliche "sitemap.xml". Für anwendungsspezifische kontextsensitive Hilfe haben wir das Sitemap-Format um unser eigenes XML-Schema erweitert. So können wir in dem "Ziphelp" auch Kontextnummern, assoziative Stichwörter (a-keywords) und weitere Metainformationen speichern.

Fehlt noch ein Viewer für Delphi. Der ist nun auch fertig.

Die ganze Sache ist noch recht frisch, mehr Alpha als Beta, doch im Prinzip funktioniert alles. Wenn komplett, können wir es als Open-Source veröffentlichen, denn die Quellcodes arbeiten alle mit Delphi-Standardkomponenten (Delphi XE 11.3). Ein Download des Paketes findet sich am Link unten.

Das Paket enthält:

1. Eine "Ziphelp"-Datei (ZiphelpDemo.Zhelp.zip)
2. Die Ziphelp-Komponente, welche das Zip öffnet und liest (Source, platform-unabhängig)
3. Ein Hilfe-Viewer-Fenster als Template (Source), um einen eigenen Hilfeviewer zu integrieren (FMX + VCL)
4. Eine Demo-Anwendung (Source) mit integriertem Viewer zum Testen (FMX + VCL)
5. Fertig kompilierte Demos mit Hilfe zum einfachen Ausprobieren

Was noch fehlt, ist die exakte Dokumentation des Ziphelp-Formates bzw. der darin enthaltenen Sitemap. Die Demo-Hilfe enthält ein vollständig definiertes sitemap.xml zur Ansicht. Der Rest ist derzeit im Quellcode ausführlich dokumentiert.

Ich würde mich sehr über Feedback freuen. Hier oder per Email unter alexander.halser (ät) ec-software.com.

Download:
https://www.helpandmanual.com/downlo...emo-source.zip


Screenshots:

[skoschke]

Zitat:

Alternativ dazu ginge dann auch noch PDF, wobei diese Kunden dann wohl auch keinen AdobeReader erlauben.

Kostet zwar ein paar $ aber um PDF's anzeigen zu können geht auch der Gnostice Documentviewer als Komponente im Programm selbst, ohne dass ein Acrobat oder ähnliches installiert sein muss!

Ciao
Stefan

[Harry Stahl]

Ich nutze seit 4 Jahren diese (eigene) Lösung und komme damit sehr gut zurecht: https://www.crosshelp.de/
Also auch alles HTML-Dateien, die in einen eigenen Container gelinkt werden.
Man muss nur eine Datei weitergeben (oder unter Windows zwei, falls man alternativ eine externe ShowHelp.exe verwenden möchte).
Projekte von Windows-Help können übernommen werden.
(Auf der Seite gibt es auch einen Link zu einem kurzen Video, wo es erklärt wird).

So habe ich unter Windows, MacOS und Linux die gleiche Lösung...

Ach ja, unter VCL kann man das natürlich auch verwenden.

[Harry Stahl]

Kleiner Nachtrag: Habe die App auf Version 1.1 mit einigen Erweiterungen aktualisiert und zudem liefere ich nun auch eine Binary für die MacOS Plattform mit (so dass man alternativ auch diese App als externe Anwendung aufrufen kann, um die Hilfe anzuzeigen).

Hier gibt es auch noch ein kurzes Video dazu: https://youtu.be/p6nFRpyQMIA?si=Ie7XmraIpOfrZCPM