H&M 7.1, PP 3.15, eWriter

Please post all questions and comments regarding Help & Manual 7 here.

Moderators: Alexander Halser, Tim Green

Rex Conn
Posts: 2
Joined: Sun Apr 10, 2011 2:56 pm

H&M 7.1, PP 3.15, eWriter

Unread post by Rex Conn »

I'm experimenting with converting my CHM help to eWriter, and have a few questions about creating the eWriter eBook:

1) The help says that the eWriter format supports the WebHelp skins, but that doesn't seem to be true for all WebHelp skins. I get errors when trying to use the V3 Responsive skins -- are they in fact not supported? It seems that the V2 skins are supported; any others that I could try?

2) If the v3 skins aren't supported, will there be new/updated v2 eWriter skins, or are they being deprecated in favor of the "full" webhelp?

3) Is there any way to bring up the eBook with a specific pane (contents, index, search) selected?

4) Any way to get it to remember the position of the splitter?

5) The up/down cursor keys don't work in the contents / index windows -- are they not supported?

Thanks for your help.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Martin Wynne »

Rex Conn wrote:1) The help says that the eWriter format supports the WebHelp skins, but that doesn't seem to be true for all WebHelp skins. I get errors when trying to use the V3 Responsive skins -- are they in fact not supported? It seems that the V2 skins are supported; any others that I could try?
Hi Rex,

EWriter (like CHM) is for Windows only, not mobile devices. So it doesn't need to be responsive, but you can use the native (non PP) responsive skins if you wish. You can use any skins in EWriter other than the PP V3 responsive skins which are intended for Webhelp on mobile devices. In PP the V2 skins are specifically marked for EWriter, and offer better functionality for the Keyword Index and multi-tabbed viewing than V3.
2) If the v3 skins aren't supported, will there be new/updated v2 eWriter skins, or are they being deprecated in favor of the "full" webhelp?
Definitely not deprecated -- EWriter is the future for integrated software Help! Tim will no doubt be answering about his plans for future PP developments and new EWriter skins.
3) Is there any way to bring up the eBook with a specific pane (contents, index, search) selected?
Yes, very easily. See context links: http://help.ec-software.com/index.html? ... ctions.htm
4) Any way to get it to remember the position of the splitter?
Over to Alex on that one -- put it on the Wish List here if it's important to you. You can set the initial width of the navigation pane in the skin settings. If you use one of the native responsive skins, the splitter position is controlled by the skin.
5) The up/down cursor keys don't work in the contents / index windows -- are they not supported?
Using a V2 skin the Up/Down keys and Home/End keys are working in the Index for me, and in the topics and Search results. But you need to click on the topic pane to focus it first. Likewise after clicking to focus it they work in the navigation pane for scrolling the TOC, but not to select items.

If you want to use the keyboard to select items in the TOC, click the Previous or Next buttons to focus them. Then you can use the Enter key repeatedly to select the topics in sequence.

There is limited keyboard support in EWriter, but Alex has just added Ctrl-0 zoom reset in the latest beta, and no doubt could add more. Using the native responsive skins, only the Home/End keys seem to work in EWriter (Alex?).

regards,

Martin.
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Tim Green »

Hi Rex,

Martin has provided detailed answers to pretty much everything so I just have a couple of additional comments. The V3 skins wouldn't make sense in EWriter because they are specifically designed to respond to phones, tablets and desktop browsers, and a large amount of what they do would be irrelevant there.
3) Is there any way to bring up the eBook with a specific pane (contents, index, search) selected?
The context links Martin was referring to there are actually also for accessing topics, but using CHM context numbers instead of topic IDs. In the V2 EWriter/WebHelp skins you have URL switches that you can include in your call to open with the search or index panes passively, or combined with a specific search in either pane. These switches work in EWriter because it actually has its own internal mini web server. See the "Using URL Switches" topic in the V2 WebHelp and EWriters skins section of the Premium Pack help chapter for details.
4) Any way to get it to remember the position of the splitter?
That depends on how long you want to remember it. You definitely won't be able to remember it across different viewer sessions, because there is no external storage for state data. Every time the viewer opens it comes with a clean slate. It is effectively like a fresh instance of a virtual machine containing only a browser. However, we have just updated the viewer so that cookies work as session variables. This means that you can store state data in a cookie and that will persist across multiple calls to the viewer from your application. It thus becomes possible to save state information. If I find the time before the release of the 3.2 update next week I'll add persistence of the splitter position and the top menu state (open/closed) to the EWriter skins with that.

The main thing the cookies as session variables are going to provide now is the ability for you to pass your own parameters to your own scripts in the skin with your URLs, for example with something like

Code: Select all

myviewer.exe mybook.ebk "index.html?overview.html&license=beginner"
You only need to pass this with one call and it will then be saved in a session variable cookie for the entire session. Then you could read the cookie on every page load and do something to the page on the basis of it before displaying it. Since the cookies persist for the entire session, this also means they persist on new calls from your app, which reload the entire UI within the viewer. For example, you could hide or display texts on the page based on style names, or load different boilerplate texts into named <div> containers on the page. These can be saved in topic files without TOC entries, which will be excluded from the search as long as their IDs start with an underscore (e.g. _text1, _beginnerlicense).,
Definitely not deprecated -- EWriter is the future for integrated software Help! Tim will no doubt be answering about his plans for future PP developments and new EWriter skins.
I'm very much open to suggestions on this. The current EWriter skins are still a bit top-heavy and not as fast as I would like, for example. My first next project in that direction would be some slim EWriter skins using WebHelp 3 technology but without the mobile device overheads, so you get the benefits of the radically improved browsing speed within EWriter.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Simon Dismore
Posts: 454
Joined: Thu Nov 16, 2006 1:29 pm
Location: London, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Simon Dismore »

Tim Green wrote:we have just updated the viewer so that cookies work as session variables.
Just out of curiosity, wouldn't sessionStorage and localStorage be more appropriate/efficient/easier to code etc?
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Tim Green »

Simon Dismore wrote:Just out of curiosity, wouldn't sessionStorage and localStorage be more appropriate/efficient/easier to code etc?
No. And for a while at least, we still have to pay lip service to older versions of Windows that don't run IE11. And since WebView is always the current version of IE it wouldn't work there.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Simon Dismore
Posts: 454
Joined: Thu Nov 16, 2006 1:29 pm
Location: London, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Simon Dismore »

Tim Green wrote:
Simon Dismore wrote:Just out of curiosity, wouldn't sessionStorage and localStorage be more appropriate/efficient/easier to code etc?
No. And for a while at least, we still have to pay lip service to older versions of Windows that don't run IE11. And since WebView is always the current version of IE it wouldn't work there.
Oh, I thought local storage was supported all the way back to IE8.
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Tim Green »

Simon Dismore wrote:Oh, I thought local storage was supported all the way back to IE8.
Hmm... I thought there were at least wonky performance issues pre-11 but I'll have to check that. What I just discovered is really interesting is that localStorage persists across sessions in EWriter. That opens up some fascinating possibilities, but also some possibilities for some rather nasty bugs:

The problem is that localStorage for EWriter is globally the same domain anywhere on the current computer. I just tried writing a value in one book stored in one location and I was able to read it from a completely different book in a different location and a completely new session. So anything you store in one EWriter book is persistently available to ALL other EWriter books. It would probably be necessary to change the internal domain to avoid this, and until that is possible my personal instinct would be to use sessionStorage only. :?
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Simon Dismore
Posts: 454
Joined: Thu Nov 16, 2006 1:29 pm
Location: London, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Simon Dismore »

Tim Green wrote:
Simon Dismore wrote:The problem is that localStorage for EWriter is globally the same domain anywhere on the current computer. I just tried writing a value in one book stored in one location and I was able to read it from a completely different book in a different location and a completely new session. So anything you store in one EWriter book is persistently available to ALL other EWriter books. It would probably be necessary to change the internal domain to avoid this, and until that is possible my personal instinct would be to use sessionStorage only. :?
That makes sense. Is the ewriter host domain or port configurable? I suppose domain-specific storage would be for title-specific settings, with a shared local storage for settings that apply to all titles, e.g. splitter position, maybe font size. Perhaps you could fake the title-specific stuff by using a naming convention, e.g. localStorage.setItem(<%TITLE%>+'.currentpage',<%TOPICID%>). Interesting stuff!

This stack overflow discussion might be useful if you are trying localStorage in IE8, btw.
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Tim Green »

Hi Simon,

Just did some more testing: IE8 is really a non-issue because the EWriter/WebHelp skins don't support it anyway, and all post-XP versions of Windows can and should install IE11.

On ports: Every EWriter viewer instance has a different port number, starting consecutively with 8000, but localStorage is still persistent across all of them. You can't change the domain because it's 127.0.0.1 (i.e. localhost) and storage is clearly persistent for the whole kit and caboodle. My suggestion for this would be to use a prefix based on the book name for all persistent localStorage values and to only do this for innocuous things like slider position and header state. And never put critical data like license keys or user license levels there, only use sessionStorage for that, if at all.

PS: It's important to be aware that localStorage is easy to enumerate: Anything on the same domain can read out all the keys and values stored there. As long as it passes the same domain test it's available to any other page on the domain.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Martin Wynne »

Tim Green wrote:
Definitely not deprecated -- EWriter is the future for integrated software Help! Tim will no doubt be answering about his plans for future PP developments and new EWriter skins.
I'm very much open to suggestions on this. The current EWriter skins are still a bit top-heavy and not as fast as I would like, for example. My first next project in that direction would be some slim EWriter skins using WebHelp 3 technology but without the mobile device overheads, so you get the benefits of the radically improved browsing speed within EWriter.
Hi Tim,

My hope for the future of EWriter would be to get away entirely from using a web browser for the HTML rendering and do the whole thing in Delphi, similar to the old HM5 EBook format. This would do away with any worries about security, local storage, use of cookies, and all the funnies in IE etc., such as the right-click menu cursor issue. Doing it all in Delphi would mean you can do anything you want, and it works on all systems.

It's not such a fanciful idea. David Baldwin's THtmlFrameViewer component already supports a browsing history and most CSS, and is only lacking in javascript. If you do everything in Delphi you don't need javascript, and the code is now open source for anyone to try. What's more it runs on Wine for my Linux/Mac/CrossOver users, which EWriter doesn't. This is a bit of bog-standard H&M Webhelp output opened in THtmlFrameViewer:
hm_frame_viewer.png
I've already made several changes in the code to allow easy zooming, file links and call-backs. My intention is to implement the expanding/collapsing TOC in Delphi, and all the other javascript stuff such as toggles, and to add a search function using the Zoom Indexer.

But that's just me messing about. I'm sure if the EC Software wizards put their minds to it, EWriter could be transformed into an amazing stand-alone application with no reliance on any web browser. :)

Martin.
You do not have the required permissions to view the files attached to this post.
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Tim Green »

Hi Martin,
My hope for the future of EWriter would be to get away entirely from using a web browser for the HTML rendering and do the whole thing in Delphi,
That reminds me of Dr. Johnson's remark on the dispute over the authorship of Shakespeare's plays, where he said that they were "either written by William Shakespeare, or by someone else of the same name."

What benefit would you get from expending a huge amount of effort to recreate the wheel like that? And what genuine disadvantages do you have when using the IE WebView in EWriter? Remember, you are NOT using an open clone of the IE browser. That is a frequent misunderstanding regarding WebView: It's not the browser, it's just the HTML rendering engine with CSS and JS support. It is effectively an HTML virtual machine in a sandbox.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Martin Wynne »

Tim Green wrote:What benefit would you get from expending a huge amount of effort to recreate the wheel like that?
Hi Tim,

It would be a better wheel. When something crops up which you don't like, such as the poor right-click menu in WebView, you can fix it in your own code. And it is not such a huge amount of effort -- David Baldwin, and no doubt others, has already done all the heavy lifting. His HTML rendering engine is very pleasant -- frames, tables, borders, background-colors, hover effects, everything you could want. And if it isn't what you want you can change it. Have you ever tried to change anything in IE?

My problem of course is that I always want to change things. For example there is no obvious reason why the Earth should revolve anti-clockwise.

regards,

Martin.
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Tim Green »

Martin Wynne wrote:It would be a better wheel.
That is physically impossible with the state of HTML rendering engines at the moment. Either it would be based on an existing engine, which would be redundant, or it would be garbage. There is nothing in between, because an HTML engine is either 100% perfect or completely useless. It would be shooting yourself in both feet to publish a commercial product like Help+Manual with anything except the standard engine for the platform, which is the IE WebView in the case of Windows.

This is so far away from the realm of possibility that it is not worth discussing. It is never ever going to happen.
My problem of course is that I always want to change things.
Then you're going to have to build your own. :?
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Martin Wynne »

OK then, don't use HTML for EWriter output. Use the same RVF viewer which you use for the H&M editor. You already have the topics in RVF format, so you have a head start. I'm using Sergey's TRichView in my application and it is very capable, as you know. But I have changed it a bit. :)

Seriously, there is no reason why the HTML rendering has to be full-featured perfect for EWriter. It is required only to provide 100% rendering for the sub-set of HTML that can be produced by the RVF to HTML converter. Since you know what that is, you could develop the EWriter renderer accordingly.

Martin.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: H&M 7.1, PP 3.15, eWriter

Unread post by Martin Wynne »

Tim Green wrote:It is effectively an HTML virtual machine in a sandbox.
Hi Tim,

This is not strictly true. For example if javascript is turned off in IE, it stops working in EWriter too (with no explanation to the user of what's happening). One of my users has already remarked about this (he allows scripts to run only in Firefox, not in IE). No doubt there are other settings in IE which affect EWriter in the same way.

I have added a <noscript> warning on my page template about this.

regards,

Martin.
Post Reply