general question about embedding docs in an app

[David Schwartz 426]

I'm using a pagecontrol to add tabs with TMemos that I go into at design time and add text that gives tips on different aspects of the program. I'm not aware of any controls that offer fairly full edit features at design time (eg., a full rich-edit editor), but the trade-off is you have some baggage with all of the text stuffed into the EXE. (Given all the other crap the compiler puts in, 10k of self-doc text isn't even a blip.)

 

What would be more useful would be a tab with a TWebBrowser on it that goes to an embedded server that runs a wiki or wordpress installation, that could be used any time to access or update the docs, including adding screenshots and whatnot. 

 

The point is to have something that travels with the program and can be updated from within it, rather than the usual help files that usually require a separate app that's usually restricted to the dev organization.

 

Ideally, that wiki or WP site would be on a real server somewhere, but we have these crazy restrictions for anything that goes onto a web server, and it practically takes approval from Executive Staff to authorize it. But an embedded web server  and a small sqllite db that can be copied as a single file would not be a problem.

 

Are there any VCL components that would enable something like this? (I'm not looking for just, say, some HTML components.)

Edited October 7, 2020 by David Schwartz

[Der schöne Günther 316]

I don't quite understand where sqlite comes into play. What did you have in mind?

 

I have been using the TWebBrowser to display rich help documents for a few years now, and it works very well. However, there was never a need to run a full server behind it, I am just displaying local files. This way, the content can easily be changed / updated by our service personal, or even the client himself (for example, when not happy with a translation).

[Rollo62 536]

I would recommend those HtmlComponents, they can show HTML nearly as good as a webbrowser.

[Fr0sT.Brutal 900]

I too can't realize what's the principal advantage in running a web-server from an app and talking with it over direct display but I'd advice opensource and fully native THTMLViewer which I successfully use as help engine in one of my projects.

Edited October 7, 2020 by Fr0sT.Brutal

[Der schöne Günther 316]

This might come across as ignorant and disdainful, but I never understood why one should pick self-created html renderers above a "true" webbrowser that certainly supports a wider range of HTML/CSS (and JavaScript)?

 

Quote

These components support most of the HTML 4.01 specifications 
with many additional popular HTML 5 enhancements.
Many Cascading Style Sheet properties are also supported.

 

[Rollo62 536]

@Der schöne Günther

Depends on what you need, the HtmlComponents are a complete RichEdit-like Editor, and ends up as complete reporting solution.

with all the possibilities it should have (scripting, interactive options).
So it can create and display the HTML, if you need that, so e.g. for translations the app could be switched into "trnanslation" mode
for special users.

 

Anyway, for a pure display webbrowser is fine too, but David asked for "components" explicitely, so I think they are a good choice.

On the downside you can see what happens if TWebBrowser-support is broken, as it was in some older versions and for other platforms,

or now the messy change to Edge browser.

Sometimes its good to have your own viewer in the backpack.

[Alexander Sviridenkov 357]

1 hour ago, Der schöne Günther said:

This might come across as ignorant and disdainful, but I never understood why one should pick self-created html renderers above a "true" webbrowser that certainly supports a wider range of HTML/CSS (and JavaScript)?

 

 

This quote if for HtmlViewer project. HTML Component Library supports almost all HTML tags and CSS properties on all platforms (including mobiles) for all Delphi versions from Delphi 5. Works on all Windows versions starting from XP, has no external dependencies, is more safe (JS is not executed) and gives you full control on loading external files (images, stylesheets, etc). Also it can be used for rendering HTML in any other control (trees, grids, etc) and another libraries (FastReport, ReportBuilder, etc) using GDI, GDI+, DirectX. plaint text or custom renderer.

[Angus Robertson 574]

2 hours ago, Der schöne Günther said:

This might come across as ignorant and disdainful, but I never understood why one should pick self-created html renderers above a "true" webbrowser that certainly supports a wider range of HTML/CSS (and JavaScript)?

Because pure Delphi renderers are far less likely to have security holes than proper browsers, partly because they don't usually run scripts, but you also have control over what external links they load if any.  We all know clicking on dodgy email links is the main way nasties like ransomware gets onto networks, sometimes just displaying an external web page.  

 

Sure they don't usually handle all the latest browser capabilities, but that is the compromise you make for safely, and you design your pages to match their capability.

 

ICS includes a  Web Browser sample using the THtmlViewer component with tick boxes to enable or disable links and external graphics. and also log all HTML and HTTPS protocol.

 

Angus

 

[Fr0sT.Brutal 900]

3 hours ago, Der schöne Günther said:

This might come across as ignorant and disdainful, but I never understood why one should pick self-created html renderers above a "true" webbrowser that certainly supports a wider range of HTML/CSS (and JavaScript)?

For older Windows, it could be Webbrowser if it hadn't had giant heap of troubles.

For transition stage, it couldn't be neither Webbrowser (too old and deprecated) nor Edge/whatever chromium clone - because of compatibility.

For newer Windows, it probably would be that built-in chromium clone.

But if you only want to display some simple HTML page, whole browser engine could be an overkill. This is where custom native implementations come in. At least with them you have full control over what's going on.

[Uwe Raabe 2057]

40 minutes ago, Angus Robertson said:

Sure they don't usually handle all the latest browser capabilities,

This may as well be the case for the specific browser currently installed at the customers system. That is another point for the component solution, as you definitely know the capabilities.

[Arnaud Bouchez 407]

Why not just a TRichEdit component?

 

It is easy to store the information in a simple wiki-like format - a MarkDown subset for instance - then convert it into RTF and display in the TRichEdit component.

Edited October 7, 2020 by Arnaud Bouchez

[David Schwartz 426]

Displaying content is not the issue, which is why I said I'm not looking for something like HTML Components. TMemos show normal text; TRichEdits show fancier markups; and TWebBrowser shows HTML. 

 

The point is not DISPLAYING but being able to EDIT, SAVE, and VIEW from within the app.

 

The options to SAVE the data are:

1) edit the components in the IDE (TMemo, TRichEdit)

 

2) hard-code the text in the code

 

3) maintain a separate file -- easy for text, modest for RTF, more complicated for HTML and help files

 

The data can go into a DB (eg,. sqllite) or just some other kind of file.

[Alexander Sviridenkov 357]

HTML + images inside ZIP. Similarly to DOCX.

[Guest]

I use a RichEdit for that (in-app docs). RTF in essence. A superuser may edit the docs and send the local table with tests to me for update in the exe resources. Choice is made upon the fact that i have a good editor/viewer without distribution hazzles and because the specific needs are met by the RichEdit. If i had the need i would absolutely look at the "native renderers" out there and especially HTML Component Library because it is capable, well written and maintained.

 

@Der schöne Günther I use native Delphi on the client side mainly because of distribution and secondly because of security. PDFs are also an attack vector.

I use native Delphi on the server mainly because of security, then stability, then control (with sources).

 

HTH

[Fr0sT.Brutal 900]

15 hours ago, David Schwartz said:

The point is not DISPLAYING but being able to EDIT, SAVE, and VIEW from within the app.

Edit and save is not an issue as long as you don't need WYSIWYG editor. Nowadays if I'd got such task I'd probably use Markdown format and automatic conversion to HTML. Markdown is very friendly for edit and provides all basic features without excess complexity.

Btw, all side files could be saved inside single HTML as base64-encoded nodes. They would be harder to view and modify though.

Another option for HTML is to implement custom container (like zip) with all contents and substitute required resources via callbacks (like OnGetImage(URI: string) or something similar)

Edited October 8, 2020 by Fr0sT.Brutal

[David Schwartz 426]

On 10/8/2020 at 12:31 AM, Fr0sT.Brutal said:

Edit and save is not an issue as long as you don't need WYSIWYG editor.

Well, I would like WYSIWYG in this case.

[David Schwartz 426]

On 10/7/2020 at 11:36 PM, Dany Marmur said:

I use a RichEdit for that (in-app docs). RTF in essence. A superuser may edit the docs and send the local table with tests to me for update in the exe resources.

This sounds exactly what I'm looking for.

 

I'm curious what you use for that "local table" that you mention, and how you "update in the exe". Does this extract something to a table when the program runs, and always use the extracted version? (Kind of like embedding a .hlp/.chm file into the EXE)

 

Or does it run from some resource in the EXE unless it's going to be edited, then do something like a "copy on write" to allow it to be edited?

Edited October 9, 2020 by David Schwartz

[Guest]

@David Schwartz, yes, that is it. Really simple.

 

The editor/viewer is DevExpress "RichEdit Control" (they have 2 "levels"). I show it in a separate form because DX provides a well-enough working "local ribbon" for the control. So when in "Debug/Superuser" mode i show the ribbon for the RichEdit. I also put up a tab with a grid with "keys" and "values" (values being the RTF text chunk for each "key". I store this in a TDataSet compatible memory table (kbmMemTable). I use the memory tables streaming facilities to load and (in superuser mode) save the whole lot to one file. This is a desktop client for "Admin/Controllers/Analysts" so i can expect an middle to upper level device (Win32 of course) and the time for the streaming is hitherto no problem. And yes, i check the file at start-up and emit it to disc/stream from the exe's resources.

 

The in-app docs are centred around the "per-client" implemented BI specific for a client. Even if "business models" are similar they have their own nomenclature and specifics. So, because of this, and because i never felt comfortable with the VCL end-user help system (that is more suitable for application handling specifics like explaining about a grid's sorting functionality, a dropdowns possible keystrokes, drag-and-drop options and such stuff), i have an "About <data/object>" button in the ribbon/menu system (<data/object> matches the "key's" canonical-title-field) that opens the view/editor and positions the cursor in the memorytable. Yes, the RichEdit is DB-aware.

 

It is rather effortless to implement application specific things and setting for the "pages". "Simply" add a column in the memory-table and link it to a control. Set it readonly/editable for the "Debug/Superuser" mode.

 

I have not dug into internal links between pages but is should be doable. I imagine an click event handler and a simple syntax like [lookup: "key"]. Also i can put up another DBGrid so the user can drag keys into the document to create a link (or an insert-link-keystroke for keyboard users). I am however reluctant to introduce link as that will entail the need for a link-checking/maintainer a-la old HTML-site editors (i do not even remember the names of those... frontend? - i am transgressing).

 

The only reason really for having the file compiled into the exe is startup/first-display-occation speed. I could easily (but i should keep it simple) add a check for an updated memory table file on my server and update an on-disc file in idle-time. I stream to disk because i have a set of per-user-persistence files stored on disk) so they are centrally managed already. In my 15-years old predecessor project i fetched all of these things from the SQL database but that 1) clutters up databases with "irrelevant" metadata, 2) depending of course of infrastructure generally takes more time. And that in turn beggars progress-controls and progress information and that... and so on.

 

HTH

[Arnaud Bouchez 407]

https://www.trichview.com/features/trichview.html is a nice component if you find the default TRichEdit too limited.
It is very customizable, and easy to work with in your use-case, if I understand correctly.
It has plenty of samples, and good support. But it is Windows only.

Edited October 11, 2020 by Arnaud Bouchez

[David Schwartz 426]

Thanks, I have TRichView in my own personal library, but the company doesn't. It is an excellent product.