ContextID in EWriter book

[Tim Frost]

Help! I just discovered that the contextID values in all of our programs have stopped working in the v7 EWriter book. They only open the first page of the book. We are using command-line parameters like "index.html?contextid=2268". What setting have I missed in the project or premium pack skin? It worked fine with the old standalone Ewriter.

Later: OPT_CONTEXT is included in the options for the EXE in our INI file.

[Martin Wynne]

Hi Tim,

See: http://help.ec-software.com/index.html? ... ctions.htm

regards,

Martin.

[Tim Frost]

Thanks, but I already read that page, which does not mention contextID. The ability to continue use help context IDs was a fundamental factor in our decision to move from CHM to EWriter. If by directing me to that page you are implying that you believe this feature is no longer supported in EWriter, then that is a significant undocumented change in V7.

We have over 400 uses of contextID in our programs, but at least we now have a common function to spawn the ebook, so I should be able to write our own lookup code, if necessary, to work around this issue. That's why I am hoping I have just made a simple configuration error!

[Simon Dismore]

It didn't work for me either, using "index.html?contextid=20600" etc – with and without quotation marks – after the file name. Works OK in WebHelp.

[Tim Frost]

Workaround! (Hopefully temporary)

1. Currently, we build HTML and EXE from the same INI file; I split this into two separate files.

2. After building the HTML, I added a step in Finalbuilder to run 7ZIP and add/update hmcontextids.js from the HTML output folder into the baggage files of the .hmskin file for the EXE build.

3. Building the EXE next, from its own INI file, results in an ebook which now accepts contextid values on the command line.

[Martin Wynne]

Sorry Tim, I thought you were asking how to do context help in EWriter.

I can't get the context ID numbers to work in EWriter, and I can't find any reference to them in the Help. Tim and Alex are saying that EWriter is just the same as Webhelp in an executable wrapper using IE, but several discrepancies like this keep cropping up.

The Context Tool can export a cross-reference map file, so it's not too difficult to write a function to look up the required topic ID name for any context number. Just a bit more work. It's strange how progress always means more work instead of less.

Martin.

[Tim Frost]

No need for an apology! If I sounded annoyed, it was not by you, just by the prospect of having to write code to do a lookup and include it in every application (as well as always arranging to create and include the latest table each time we build). But as you will see above it seems just to be a glitch in EXE generation and I have already rebuilt our e-book help with my workaround. However it will be important that the EXE operation updates the JS file automatically on each build also, as part of a fix.

I was sure I had seen an e-mail or posting from Tim G or Alexander showing how to do context IDs, but I cannot locate it now. It think it was not in the separate EWriter documentation either, but was something we needed to enable us to drop CHMs.

[Tim Green]

Update on this: Context IDs and other URL query components are not currently supported in the current version of EWriter, even though they may be supported by the WebHelp skins you are using to generate the EWRiter file. This is going to be added in a future update. At the moment you do have to reference the topic filenames in your calls.

Sorry about that, but there appears to have been a problem in the code passing the code into the internal viewer. It is definitely on the to-do list, however.

[Tim Frost]

Thanks for the confirmation. My workaround is ugly, but it seems to do the job for now. We have made too many changes to the document in recent weeks to allow us to revert to H&M 6 for the eBook, and the idea of writing our own lookup to allow us to retain all our IDs was impractical.

[Simon Dismore]

I tried a variant* of Tim Frost's workaround but got 404 errors.

It seems that EWriter ignores the 'Extension for HTML files' setting in the HTML Export Options. I was generating WebHelp with ".html" file extensions. I had to make a version of hmcontextids.js with ".htm" extensions. Once I did that I found Tim's approach worked fine.

* @Tim Frost, my variant was simply to copy my project's .\HTML\hmcontextids.js to the project's .\Baggage\ after compiling WebHelp. When compiling to EWriter this baggage file is automatically copied to .\~tmpexe\ before the .exe file is assembled, but when compiling to WebHelp a new context id script is generated in .\HTML\. This variant avoids the need to update skin files.

@Tim Green. There's something strange going on with the file timestamp though: the date modified of the version in .\Baggage\ was today 15:17 but the timestamp of the one in .\~tmpexe\ was 12:18. I know they are the same file because I changed a context ID at 15:16 just before compiling to WebHelp.

[Alexander Halser]

Hi Tim!

We have fixed the problem in the EWriter eBooks with an update today. The build number is still version 7.0.5 build 3681, because there is actually no change in H&M, but merely in the eBook exe template.

Download:
http://www.helpandmanual.com/downloads.html?upd

The eBook exe template has received an update that fixes 2 problems:

a) Context sensitive help calls with context numbers now work in eBooks

You can specify the context number in two ways - simply with the number as the first parameter or with the full page url.
Examples:

Code: Select all

myebook.exe "index.html?contextid=20600"
myebook.exe 20600
myebook.exe "index.html?mytopic.htm"

b) Menu and window captions in the eBook can now handle Unicode characters

This worked before, but a (for example) Russian eBook with Russian menu captions displayed on a Russian Windows only. Now the same eBook works on any Windows installation and properly shows Russian text, wether the Windows version is English, German or Chinese. We could enable unicode characters in the eBook viewer without adding too much to the EXE size, it's just 50 KB larger than before.