H&M 7.1, PP 3.15, eWriter

[Tim Green]

OK then, don't use HTML for EWriter output. Use the same RVF viewer which you use for the H&M editor.

Then you can't have skins. That's out of the question, just like using other HTML engines.

For example if javascript is turned off in IE, it stops working in EWriter too

Not the end of the world, and irrelevant compared to all the other disadvantages of not using it. Nothing will ever be perfect, and all the alternatives you suggest have many, many more disadvantages.

[Martin Wynne]

Not the end of the world

Hi Tim,

It is if you want to Search in EWriter. That's one of the reasons why I have added a link to the same page in my online Webhelp on every EWriter page. Not only a swap to mobile devices if wanted, but on a desktop a swap to a different browser.

But having searched, there is no way back from Webhelp to EWriter. How about an address bar / URL entry box on EWriter?

OK, back to work. I've finished annoying you for today.

regards,

Martin.

[Rex Conn]

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

Not sure I understand how to use this to bring up the pane with, for example, "Search" displayed (as opposed to the default TOC). With CHM, I just passed the appropriate flag. With eWriter, I can select my topic with the TOC/Index/Search hidden, or my topic with TOC/Index/Search displayed. But I don't know how to make the Index or Search display instead of TOC.

Edit: Never mind, I found it (index.html?nav=index).

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.

Using the V2 WebHelp_SlateGrey.hmskin, I can get them to scroll, but not to select anything. Not a huge deal, but I do have some users who refuse to touch their mouse.

Thanks!

[Martin Wynne]

With eWriter, I can select my topic with the TOC/Index/Search hidden, or my topic with TOC/Index/Search displayed. But I don't know how to make the Index or Search display instead of TOC.

Hi Rex,

Use "index.html?nav=index" or "index.html?nav=search" as the topic URL. Make sure it is in quotes.

i.e. use code like this to display the Keyword Index:

Code: Select all

  viewer_str:='path\my_ewriter.exe';
  content_str:='"index.html?nav=index"';

  if ShellExecute(0,'open',PChar(viewer_str),PChar(content_str),nil,SW_SHOWNORMAL)<=32
     then ShowMessage('Sorry, unable to show the Help viewer.');

regards,

Martin.

[Martin Wynne]

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,

I would prefer functionality over speed. For example the Keyword Index in V3 drives me mad. Not being able to scroll through the whole thing is a big loss. The great advantage of an index over searching is that you can find things even when you don't know what you are looking for. Having to click the first letter of a word you don't know the terminology for completely destroys that.

OK, it takes a while to load. A rotating roundel is annoying, but a polite message saying "just loading that for you, please wait" is fine by me. And it gives you a few seconds to think.

What I would really like for the V2 skins in EWriter would be an option to have 3 columns instead of 2 columns. TOC + Index + topic pane. Then after clicking an item in either TOC or Index you can see if it is what you want, and if not click something else. Or while clicking items in the index, see where they fit in the TOC structure, without losing the index. At present in V2 clicking back to the index tab after finding that what you clicked wasn't what you wanted, loses your place in the index.

In V2 skins currently you can't see the Index and topic pane side by side. They are always in separate tabs. I seem to remember some skins in which the Index and Search tabs could be undocked? Did I dream it? Or is that in Webhelp only and not EWriter? Or am I missing something?

regards,

Martin.

[Tim Green]

Hi Martin,

Undocking panes doesn't work in EWriter -- at least not with the separate window method that's used in those skins -- that's why that option is deactivated in those skins there.

The issue with long TOCs and indexes on mobile devices isn't the time they would take to load. It is that they quickly start to behave strangely or grind to a halt when these elements grow beyond a certain size. Try publishing a project with a large index using one of the standard HM7 responsive skins and then open it on a mid-range Android phone and try to browse in the index. The current V3 index solution gets around this by hiding what is not currently rendered but still allowing you to do a lighting fast search of the whole index, because the search is performed in the compressed JSON object. I'll see if I can add an Expand All for desktop mode only though, although I can't promise this will make it into 3.2 if I still want to release that this week.

What I would really like for the V2 skins in EWriter would be an option to have 3 columns instead of 2 columns. TOC + Index + topic pane.

That's a major project. I'll keep it in mind for the future but it's not a quick job.

At present in V2 clicking back to the index tab after finding that what you clicked wasn't what you wanted, loses your place in the index.

I'll have to look into that. It's a scrolling problem, not something fundamental. In the standard HM skins and templates the TOC, index and search tabs only exist at all when they are visible. So when you switch back to them -- for example between the index and the TOC -- the page you were just viewing is thrown away and replaced with the page you want to view. For example, when you select something in the index the entire index is closed and the entire TOC is reloaded and re-synchronized. And when you switch back to the index the entire index page is reloaded and re-rendered. In the V2 skins there are separate iFrames for all three and they remain loaded all the time. So not losing your place when you return to the index would be a simple exercise -- it's simply a matter of not losing the scroll position in the existing page.

[Martin Wynne]

Try publishing a project with a large index using one of the standard HM7 responsive skins and then open it on a mid-range Android phone and try to browse in the index.

Hi Tim,

What do you call a large index and a mid-range Android phone?

I just had a look at your own Help ( http://help.ec-software.com ) on my Huawei Y6 phone, and the index worked perfectly. It scrolled all the way to the bottom, and to and fro anywhere in between, and opened any item I clicked. I spent several minutes testing it.

That's both in the native Android browser and in Google Chrome.

The H&M Help certainly seems large to me. The Y6 is a long way below the top of the range, it cost me about £70. It appears to be possible to pay 5 times that for a smartphone.

regards,

Martin.

[Tim Green]

Hi Martin,

What do you call a large index and a mid-range Android phone?

Hmm... It's been a while since I last tested, but that was what I tested with. Back then it hung up completely on several Android phones. I'm beginning to have a suspicion that some of these things may have been influenced by the local LAMP (Linux Apache MySQL PHP) server system I've been using for most of my testing.

Be that as it may: I just finished the full-expand support for the index on desktop browsers in V3 this morning. You will be able to set a config variable to true and then you will get a fully expanded index on desktop browsers. For the moment I'm still leaving it as it is on tablets and phones. That would be the next step and that would require more flexibility, with the added ability to open and close sections at will as well. Just getting the full expand without interfering with anything else was nearly two days' work. Adding the dynamic features as well would mean changing the code on a deeper level that I don't want to do until I've had more time for thorough testing.

It should also be possible to make sure that the current scroll positions in the search results and keyword index panes are always kept or restored in the V2 EWriter skins when you switch back to them. That should also be in the 3.2 update, which I'm now pushing to next week because of all this.

[Tim Green]

Hi Martin,

At present in V2 clicking back to the index tab after finding that what you clicked wasn't what you wanted, loses your place in the index.

This behavior is restricted to Windows 10 and it turns out to be caused by a bug in the WebView there. This has been corrected in the Windows 10 Anniversary Update just released so I'm not going to make any modifications for it. I spent an inordinate number of hours on it before finding that it was fixed in the update, and doing anything to get around it would be complicated and any solution would have potential for causing other problems.

The problem is that the bug causes the scrollTop value of the container contents to flip back to zero as soon as the container is hidden. This happens so fast that you cannot catch the previous position with any of the event handlers used to switch panes etc -- it is already zero by then. There is also no onblur event that works fast enough to catch it in the needed state. The only way to catch it would be by constantly polling the element's scrollTop at quite a high rate and comparing the values between individual polls, and that would add overheads that would outweigh any benefits.

The bottom line is, the scroll position stays put in Windows 7 and 8 in EWriter and will also do so in Windows 10 as soon as the Anniversary update is installed.

[Martin Wynne]

At present in V2 clicking back to the index tab after finding that what you clicked wasn't what you wanted, loses your place in the index.

This behavior is restricted to Windows 10

Hi Tim,

It is also happening in Windows7 here (IE11). Just to be sure it is not something I've done, I just tried compiling to EWriter using a different PP3.15 V2 skin exactly as supplied (WebHelp_Mango).

Just to be sure I have explained it properly, in the index tab I scrolled well down. Clicked an item. It opened in the topic tab. Clicking back to the index tab and the index is back at the top, the previously clicked position is lost.

Sorry to hear that you have been spending many hours solving stuff posted by me. Please don't -- it's a lovely sunny day here today. Put it on the to-do list for a rainy day.

I posted them only because you said you were open to suggestions.

p.s.

The only way to catch it would be by constantly polling the element's scrollTop at quite a high rate and comparing the values between individual polls

Would it be possible to poll it in the onmousemove event of the links in the index?

regards,

Martin.

[Martin Wynne]

p.s. While I was typing the above my Windows10 (on SurfacePro3) updated itself, and is now working correctly as you describe.

Martin.

[Tim Green]

Hi Martin,

I can't reproduce the error on any Windows 7 VM, unfortunately. I'm just updating an old version of W7 on an old hardware machine but that will probably take until tomorrow to be ready. If I can reproduce it there I could try saving the current scroll position on mouseover and click on the index links and restore it on returning only if the position is not zero (so that it doesn't interfere on systems without the bug). However, if I can't reproduce it I'm going to leave it as it is.

[Tim Green]

Hi Martin,

Updating an old Windows 7 hardware system to current took, literally, 3 days. I have a feeling MS want people to upgrade to W10...

Strangely, I can reproduce the scroll bug in EWriter on hardware but not in a virtual machine. I've also found a way to fix it, because no onscroll event fires when the scrollTop flips back to zero. So I can store the last position reliably with onscroll and restore it on returning only if the current position is no longer what it was on leaving. Easy peasy, also for the Search tab...

[Martin Wynne]

Easy peasy, also for the Search tab...

That's great Tim, thanks for all your efforts.

I know what you mean about MS. Since they stopped nagging me at 5 minute intervals to upgrade my Win7 system to Win10 free, now when I go to Windows Update it sits there saying "Checking for updates" for hour after hour after hour after... Not sure what to do about it.

There was a massive update to Win10 a few days ago, and then an update to the update, so I can't believe there aren't some related fixes for earlier versions. But MS clearly don't want me to have them.

Martin.