Help window shrinks when compiled on build server

[Cecily]

I'm currently on Flare v4.0 (and hope to upgrade to 4.1 mid January) with Win XP. I compile the help locally, and whilst my content and project folders are in TFS source control, my output is not; the help is recompiled on a build server as part of a continuous build process.

The problem is that when the (re)compiled help is viewed from the end application, the default window is tiny, so a user has to resize it every time.

I have increased the size for the skin when I compile and a developer has done the same on the build server, to no avail.

Any ideas?

[doc_guy]

How is the help being called in the application? If you call it using JavaScript, you can set the window size exactly. If you are calling it using a pure HTML link, then the browser will pick the size to use for the new window.

[KevinDAmery]

Well, this is HTML Help so browser size shouldn't affect matters (that's a Webhelp thing...)

I've just been using the Size settings in the skin, and they've been working for me - although having said that I haven't done a build since moving to 4.x....

[doc_guy]

Duh. Sorry. Was reading new posts, and didn't pay attention to the forum.

It's not a resolution difference, is it? (Stab in the dark guess, while trying to save *some* face)

[Pete Lees]

Hi, Cecily,

Programmers can set the size of the help window when they pass calls to a .chm file. Is it possible that your application is setting the initial window size?

What happens if you delete or rename the file hh.dat in the hidden folder %UserProfile%\Application Data\Microsoft\HTML Help (for example, C:\Documents and Settings\Cecily\Application Data\Microsoft\HTML Help)? This is the file in which Windows records the most recent size and position of each help window, so by removing it you can roll back to the default settings for your help file.

Can you locate the HTML Help project (.hhp) file for your help file, open it in Notepad, and copy and paste the [OPTIONS] and [WINDOWS] sections into a reply? This will allow us to see exactly what settings you've chosen for the help file.

Pete

[Cecily]

Thanks, but that doesn't seem to be the problem. When it compiles on the build server, the dimensions specified in the skin are halved.

For now, I've increased the dimensions to the max on the laptop where I compile. Then, when the build server halves the dimensions, although the window is still a little small, it is more manageable.

Will upgrading to 4.1 have any effect, I wonder?

[Richard Ferrell]

This is a known issue, and should be corrected in a future version of Flare

[Cecily]

So the good news is that I should stick to my workaround and I don't need to log it; the less good new is that the fix isn't in 4.1. Thanks for the info though.

[sarah_downing]

Does anyone know if this issue has been fixed? I'm having the same problem in Flare 7.

[luvthepug]

I was running into this problem as well with Flare V7. I've some-what narrowed it down to when the file is compiled and published using the Batch Target rather than the html-specific Target. Since I'm not sure exactly where the bug is, this is what I do and it works:

> Start with a "fresh" output folder. Go to Build / CleanProject and delete the output folder.
> Delete any previous "catapult.log.zip" files in all publishing destinations and in your AppData temp folder. For example: C:\Users\<your_user_name_here>\AppData\Local\Temp
> Build and publish from the separate html Target and NOT a Batch Target.

[JasonSTI]

You might open your Skin file in Notepad, and see if there is anything set in the Anchors section. We ran into a problem a couple years ago where an invalid string got saved in there, and it caused the built window to appear very small, but only when using the command line build. Here is the topic where we discussed that issue. Hope that helps.