links open in browser window

[scribe45]

I inherited a Help project in RoboHelp 6. I have both context-sensitive topics and am developing a total Help system. I am frustrated with several "features" of RoboHelp.

1) I can't figure out how to control how links open. I want them all to open in a small Help window, so when a user clicks a link, it opens in the same Help window. Instead, many of my links are opening in a full browser window. How do I control this?

2) When I edit code in their supposedly "TrueCode" mode, my changes do not "take" -- instead RoboHelp shows something else, and this happens even when I edit the file in another editor. I hate this!!! (One example: to try to fix the window-opening problem, I tried adding Target="Self" to links, but RoboHelp removes the quote marks)

3) Why no Back button? I saw the item about adding a back button with JavaScript and will try it. I find the lack of a Back button annoying in RoboHelp's own Help, which IMHO is not well organized or well-written (am I the last person on earth to understand that "display" is a transitive verb? Or that you don't open a "dialog" but rather a "dialog box?"

[Captiv8r]

Hi scribe45 and welcome to our community

It would be helpful to know that "RoboFlavor" you are using. RoboHelp for Word, where Microsoft Word is your editor, or RoboHelp HTML? I'm guessing RoboHelp HTML here.

If I guessed correctly, you are able to double click your link and choose the way it opens there. Basically your choices are opening a new window or a popup. I'm doubtful you are interested in the popup, as I'm guessing you want to open your context sensitive links in a specially sized and placed window. You may benefit by reading fellow Adobe Community Expert and fellow Adobe Certified RoboHelp Instructor John Daigle's article out on the Developer Center. You may do this by clicking here.

As far as TrueCode changing when you return to the WYSIWYG editor, it's been that way for as long as I can remember. WYSIWYG is ever "helpful" and will often rewrite your changes. It may be helpful to know what exactly you are changing and what RoboHelp is doing to "help you out".

As far as a Back button, are you referring to your Topic Preview pane? If so, there really isn't a need for one if you know where to look. Try right-clicking the topic in preview and look at the very top of your context menu.

Hopefully something here was helpful... Rick

[scribe45]

Thank you, Rick. Your comments are definitely helpful!

Yes, I am using HTML WebHelp with the RoboHelp editor. I wondered why the cursor changed when I hover it over a link in WYSIWYG, but I could not find any reference to double-clicking to open a dialog box, although I have seen that dialog box when I enter links. I assume RoboHelp wants me to choose, from Display in Frame, "Same Frame." What confused me about this is that a Help window, I believe, is not a "frame" -- a frame in web parlance is a part of a window that doesn't change and is independent of other parts of the window. Frames are annoying and not used much anymore. It also seemed to me that in one of the many RoboHelp Help topics I consulted that it stated somewhere that this feature did not work in WebHelp.

To make this even more bizarre, when I applied the "Same Frame" choice and looked at the code, here is what is added: target=_self. Oh my, RoboHelp can use its own non-standard form of Target="Self" but can't cope when I add the correct form.

I'm sorry for venting, but I really don't much care for RoboHelp. How much "help" is it giving me compared to how much grief? I am a good coder and know CSS very well. I just dislike a tool that does not let me use the knowledge I have, but instead assumes I'm an idiot. I also have a problem with an application that creates Help systems but whose own Help system is badly written and inadequate.

[HKabaker]

When I insert a hyperlink in text, I highlight the text and go to the Insert Hyperlink/Popup menu.

At the top is a fill-in field for the target.
Immediately below is a "Hyperlink Options" panel. First choice (default) is "Display in Frame" and the dropdown default is Page Default (none). It didn't take me long to understand that this probably meant the topic pane.

Other options are New Window, Same Frame, Parent Frame and Whole Page. I often use "New Window" but haven't selected the other options. Hmmmm........ wonder what they mean.

Then I go back to the topic and see my hyperlink highlighted.

But I want to change it. Now let's see .... hover cursor (just a popup hint)... Click once (nothing) ... Click twice...The dialog!

I'm glad they assumed I'm an idiot.

Harvey

[MergeThis]

Oh, my Gawwwwdddd!

RoboHelp added an underscore to the "self" target! Man the barricades, Molly, they're coming for us, next!

Wait till you update to RH7 and find that RH isn't using kadov tags anymore! Even worse, they're grouping 4-6 table list qualifiers to a line, instead of one per line! The gall!

OOOOOooooohhhhh, woe is us!!!!!!

[scribe45]

Ok, so I'm a minority in not liking RoboHelp. But doesn't it seem a bit off that this tool that creates HTML files doesn't conform to HTML code standards? That means anyone who knows how to code HTML and CSS is forced to figure out how something is done in RoboHelp when they know exactly how to do it in HTML. How is that helpful?

I stand by my statements that their own Help is poorly-written and not very helpful. I suppose I'll just get more derision, but I have STILL not gotten my links from context-sensitive Help windows to open in the same window. My files were moved to our application today and I tested the links and --- they still open in a full browser window, even though they worked the way I want in the Preview function.

I set the links to "Display in Frame -- Same Frame" (whatever the RoboHelp developers think that means) but they still open in their own full browser window from within the application. If you go to RoboHelp's Help, and click their definition of "frame" (which actually doesn't supply a defintion) you get cryptic statements about the "Display in frame" options. The most likely-to-be-correct choice seemed to me to be "Same Frame" (even though a window is not a frame).

I guess I'm not enough of an "idiot" to make any sense out of this. It's certainly wasted a lot of my time compared to just typing some simple HTML code.

[HKabaker]

Probably if you could leave your little snit out of the forum, you might frame your question in a way that can elicit practical advice from a bunch people who may have more patience than others.

You haven't been very clear about what your problem is, but here's a thought or two:

Where is the code for calling your help topic? Did the application developers write it? Are you using RH's CSH interface? Seems to me that the first call will control where the topic appears. Anything in RH would be secondary, to the extent that it's possible.

Another way of putting this is, if the "help" link in the main application is opening a new window, that's what RH is going to fill.

Is your problem that each new help call opens a new window rather than using the first one? In other words, you have to close each help window to avoid open windows piling up on the screen? That's another issue we've discussed.

Or do you want the RH structure to be constant, so
--the help topic opens in the topic pane of a new WebHelp window, or,
--if a WebHelp window is already open, we replace its topic with a new one in the same frame. (??)

This, too, is something we've explored in the forums. I haven't heard of a perfect solution, but a few of us have accomplished something.

Bottom line is: Just because RH isn't doing what you want it to do, that doesn't mean RH can't do it.

About coding:

There's still a lot of css code out there on the Web that may not meet the latest recommended format (W3C recommends but can't legislate). But it still works in browsers because they haven't forgotten all the "old" stuff.

On the other hand, there are some forms of syntax that are "deprecated" in the W3C recommendations for css. That's the closest they come to declaring something obsolescent.

You point specifically to

target=_self versus Target="Self"

Some questions you need to investigate:

What does RH put in the output file? Is it the same as in the RH source topic code?
Is the older expression deprecated? Does lower case target="self" work as well as Target="Self"?

Or you can just spend your time "just typing some simple HTML code."

Please return with a question someone can answer.

Harvey

[MergeThis]

I've got a great idea! Let's just ignore the whole "compliant-html/css, back-button, dialog box" subject, shall we?

Let's just try to figure out what is actually needed. That, of course, will require scribe45 to specifically state what is happening/not happening, and how that behavior should change. Also, scribe45 should realize that RoboHelp uses the "Start Page" to create that dreaded frameset environment (which contains the toolbar pane, the navigation (TOC, Index, Search) pane, and the topic pane. Calling a topic directly (not through the Start Page) essentially displays the topic "naked."


Good luck,
Leon

[Amebr-ke0mH4]

1) I can think of two possibilites for this:
a. You are using a standard webhelp layout with a TOC pane and a topic pane. You want the links to overwrite the topic in the topic pane. This is the option we use. We just select Page Default (none) in the Display in Frame list.

b. You want hyperlinks to open in a small window separate from the main WebHelp window. I haven't tried this, but I would assume you could create a new Window definition, and specify that as the "frame" for all links that you want to display in that type of window.

2) target=_self is the correct "self" syntax. I think HTML 4.0 is the html being used, so you can specify with or without quotes. Yes, it is a bit annoying that custom html coding is "fixed" but the application is designed as WYSIWYG, and I would suspect most people won't be getting under the bonnet to look at it. Plus as the app is now part of Adobe, I suspect each release will become more standards compliant.

3) I've always just used the browser back button. Maybe I'm missing something here? The RH help I just looked at has little Previous Topic and Next Topic buttons just below the Contents/Index etc icons. I *think* it's the offline version, but I can't check at the moment, as I'm having some weird PC problems which won't let me access the Tools menu in Robohelp.

[scribe45]

I really do appreciate your help, and I want to apologize for offending anyone. I think my antipathy to RoboHelp began years ago with a totally different version, plus, with my current project, I came in behind someone else who recommended the company buy RoboHelp (at a cost of $1000), started the Help and had very little done before she quit and they hired me. My work involves more than doing this Help system, but I wish I could have been here to review and recommend tools... and maybe I would have ended up with RoboHelp anyhow. I don't want to waste the company's $1000 investment, so I just have to master this tool, even if I do have a laundry list of complaints about it.

Your comments were considerably more helpful to me than the RoboHelp Help. I now realize that 1) RoboHelp talks about "frames" because a full help window (with TOC) actually uses frames, and 2) what I want to do may not be possible.

Here is what is happening. Our application is not Windows-based, but rather uses "portlets" -- a "page" in the application may have 7 or 8 portlets that load independently (the user can configure his page to have the portlets he wants). The user can right-click a portlet to get a menu of options that includes "Help." When the user clicks this Help option, he gets a small single-topic window, without frames or TOC. The Help file is given the same name as the portlet. This is the instruction I got from the developers, who showed me how to find the portlet name. This is all working just fine.

Here's the problem: I have links inside those single-topic windows. When you click a link inside these windows (the context-sensitive help associated with the portlets), the link opens a full browser window. The small window with the portlet Help remains. The new window does not replace the old window. What I intended (and was trying to make happen with those RoboHelp choices from "Display in frame" in the Hyperlink window) was for the link to replace the previous window -- to appear in the small single-topic window.

When I preview a topic, the links DO open in the same size window, but maybe that is not surprising. The application may act differently. If RoboHelp can only control how a link behaves when the link is in a full (with frames) Help window, then maybe none of the "Display in frame" choices will make any difference. Is it possible that I just can't have any links in a context-sensitive window? Or is this something the developers could change by specifiying that windows replace windows?

Can you see how it seemed to me that I could fix how the links should behave in the HTML? It certainly seems logical that a simple "target="self" would work, and I did not know why RoboHelp was changing the code. Was it to insure that the code would NOT work (as in "commenting out" lines of code?) RoboHelp Help is not big on explaining what its features are actually doing.

If I cannot have links inside a context-sensitive, single-topic small window, then I need to rethink the design of my Help system. The developers gave this very little thought and seemed to think the context-sensitive help would be enough to guide the users, but I can see that it is not enough. We DO need a full (with TOC) Help system, as not all features are just a portlet. Some features involve tabbed pages that have no "Help" link. This is a very complex EMR (Electronic Medical Records) system, with a lot of features that need explaining... So, at present, I am mixing the two kinds of Help -- context-sensitive and full Help, with TOC. The developers automatically add "Help" to all right-click menus, so they are working on a concept of context-sensitive Help. I can create a file for all those "help" menu items, but the help will not be as helpful as I'd like if I can't put links to related topics inside the window.

I have not tried RoboHelp's "related" button feature because I prefer to just put the links in the window than have users do the extra step of clicking a button, but I could try that if the "related topics" pop-up would give me links that would open inside the small window. It just does not seem acceptable ot me to hav Help windows going outside the system to a full browser window that leaves the previous window open.

Regarding the question about whether the project files and output files are the same -- the output file is clearly different, but both use the target=_self format. I don't know if we're using the RH CSH interface. I will try to get more information from the developers as to whether they have somehow set these windows to work this way.

Regarding creating a new "Window" defintion--- I did look into that, and you can specify a "one pane" window, but I don't want a Help topic to be confined to one pane. The same topic that is a context-senstive topic also appears in the TOC, sowhen the user is accessing it from the full Help, the topic should open in the right pane, like every other topic accessed this way. The "window" definition does let you set a window size and choose to make it resizable or not. But it is not this "window" feature that is controlling the context-sensitive windows, since they are not set to a separate "window" definition, so it is not clear that this strategy would actually work.

Have I explained the problem better? My purpose is to create useful and helpful Help. RoboHelp is the tool I've been given to do it, and I am not experienced with this tool. If anyone can tell me if I can get those links to open in the same window as the previous single-topic small window, I would be most grateful. Otherwise, I may have to rethink my whole design.

Again, I am sorry if I was overly critical and offended anyone.

[HKabaker]

Very clearly.

You are not using the RH CSH interface.

The preliminary answer is to let RH put target=_self in the output files' links and see how that works. (And stop fretting about html standards for a moment).

Please report back.

Harvey

Harvey

[Peter Grainge]

Send me an email via my website.

I will send you a RH project that is doing what I think you want. If it isn't, then perhaps by explaining why not, we can get what you want.

[scribe45]

HI!
I let my developers know my problem with windows and we now have context-sensitive windows that are resizable, but the links still open full browser window and leave the previous window open. I think this is a developer issue since I have tried everything in RoboHelp and nothing makes any difference. The context-sensitive windows have no right-click menus, so no chance to see the code and figure out what's really happening. It's very frustrating and does nothing ot change my (mostly negative) views about RoboHelp.