• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Closing one help file closes another

New Here ,
Jul 21, 2006 Jul 21, 2006

Copy link to clipboard

Copied

Hi y'all, I've searched and searched for an answer to this so I hope someone can help.
I want to create a small floating window that acts as an 'always on top' menu with links to a full-screen help file. I want the user to be able to close the full screen help file, leaving the small window open. Oh, and this menu window is to be initially called from the full-screen window by user request, but once open it should stay open until specifically closed by the user.
I'm starting with the assumption that this requires two separate help files - right?
Trouble is, when the user closes the full-screen help file, the menu help file closes with it. If anyone knows how to prevent this, I'd be very grateful.

Views

1.3K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 22, 2006 Jul 22, 2006

Copy link to clipboard

Copied

South Coast,
That should be doable, depending upon exactly what involved. I take it that you want both windows to be WinHelp-related, right? I.e., you wouldn't want the always-on-top window to be a separate application that launches the WinHelp topic window, correct? Further, you want the first thing the user sees to be the full-screen WinHelp topic window, where the user can invoke the always-on-top menu window if they want to, but if the user closes the full-screen topic window, you want the menu window to remain visible?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jul 22, 2006 Jul 22, 2006

Copy link to clipboard

Copied

Tommy!

Nice to see you, bud. You have been missed!

Cheers... Rick

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 25, 2006 Jul 25, 2006

Copy link to clipboard

Copied

Hi Tommy and thanks for taking the time to repsond.

The answer to all of your questions is 'yes'.

In particular, I'd like the user to be able to use the menu window many times to call the full-screen help, closing the full-screen help each time and leaving the menu window open.

Hope this clarifies!

Best Regards, Simon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 29, 2006 Jul 29, 2006

Copy link to clipboard

Copied

Rick,
Same here - I try to keep in touch as much as my schedule and my computer will let me!
;-)

South Coast,
Sorry for the delay. Being on the road so much and troubles with my computer have made it hard to do much with the forums lately. Here's what I would suggest for your menu system:
1) As you've observed, using the normal external topic link mechanism in RoboHelp just results in the topic coming up in a specified window, but since it's the same instance of WinHelp (the same instance of winhlp32.exe), closing the topic window also closes your menu window.
2) The trick is to invoke a second instance of winhlp32.exe. To do that with your menu window, have your link that calls the menu use the EP macro (yes, I know the macro reference materials state that EP() is a deprecated macro, but it still works, and its ability to use Windows command line switches is what you want for the rest of the procedure).
3) Here's a sample of the menu-calling macro code:
Link Text!EP(`C:\WINDOWS\winhlp32.exe -i default_topic menufile.hlp',)
Result: Windows instantiates a second instance of winhlp32.exe and uses the "-i" command line switch to open "menufile.hlp" to the default topic, or whatever topic ID you specify. The menu appears in whatever window at whatever position you have set in the menu project properties dialog.
4) Close the topic window. The menu should stay visible and accessible to the user.
5) Now, in your menu, your links would have macros coded like this:
Link Text!EP(`C:\WINDOWS\winhlp32.exe -i External_Topic_ID externalfile.hlp',)
Result: another instance of winhlp32.exe is launched and opens your main Help file to the topic with the specified topic ID.
6) Close the topic window and click another link in the still-visible menu window - you should see that other topic open in a fresh WinHelp window.
7) The only drawback that I can see is that if you don't hard-code the path to winhlp32.exe, you get a message that Windows can't find that file in a path that Windows apparently thinks ought to be "C:\WINDOWS\Help\winhlp32.exe". I didn't have time to do more testing or troubleshooting on that issue - maybe next week when I get a chance to take a little vacation time ...

Let me know if this helps any. Good luck!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 31, 2006 Jul 31, 2006

Copy link to clipboard

Copied

LATEST
Thanks Tommy, this helps a great deal. I've got it working pretty much as I'd like it - the menu help file automatically opens in a very small secondary window (which allows me to hide all the buttons - can't seem to be able to do that in the main window) and sits quietly in the corner, always on top and ready for use.

One consequence of this solution is that if the user chooses not to dismiss the main help file, then they get another instance each time they click a link in the menu. Not a biggie; I can include a note advising them to close it each time I suppose. I can't imagine there'd be a way to kill all instances of winhlp32.exe except one...

I think I can see why hard-coding the path to winhlp32.exe might be a bad thing (beacuse the user's system may not be c:\windows, right?). However maybe I can get the developer to modify the installation routine for our application so that it finds winhlp32.exe and copies it to the same folder as our help files. Is there a dwonside to that, do you know?



Thanks again - Enjoy the vacation!
Simon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
RoboHelp Documentation
Download Adobe RoboHelp