TOC Link Question

[jkpalmer]

Please excuse the lengthy description to follow:

I am responsible for managing multiple Flare projects.

My webserver is named "docpub".

Locally, the server directory for "docpub" is C:\inetpub\flare

On my Flare development machine I have mapped a drive letter (X:) to the machine ("docpub" which is the same as C:\inetpub\flare)

Internally (on our local network), we can access the webserver using the URL of - http://docpub
Eternally (on the web), we can access the webserver using the URL of - http://documentation.ourwebsite.org

I have used Flare to create a "master menu" project/application which I have published to the C:\inetpub\flare directory.

In the interest of keeping my project content distinctly separate from any other directories that may reside in the C:\inetpub\flare folder, I decided to add another subfolder named "flare" (probably not the best decision, but it works for me) and all my "content" projects are published to this directory.

For this discussion, I have one project "ProjectOne"

"ProjectOne" has three targets - "TargetX", "TargetY", and "TargetZ"

When I publish "ProjectOne", my targets are set up as follows:
file///X:\flare\ProjectOne-TargetX
file///X:\flare\ProjectOne-TargetY
file///X:\flare\ProjectOne-TargetZ

In the setup of my "master menu" project, I created a Master TOC as follows:

Main Menu
ProjectOne
TargetX
TargetY
TargetZ

In order to get my "master menu" to work correctly (and it is currently working just fine) both internally and externally, I must code the link properties for each as:
../../ProjectOne-TargetX
../../ProjectOne-TargetY
../../ProjectOne-TargetZ

When I do this, the links in my TOC all appear as broken.

Question - Is this expected behavior or am I doing something incorrectly?

Jim P.

[roboHAL]

Hey Jim. I'm not sure I completely understand your post, nor do I read any info as to the version of Flare and the type of target output you are creating. I'll assume it's HTML5 output created with Flare V12. My reply, however, would likely be same regardless of Flare version. In the TOC Properties General tab I believe you have to use the Select Topic... option (radio button) and then input a specific URL beginning with http://. I do not believe link properties of "../" as if to convey a relative path would work in your case, especially for the pages accessible via the web. Offhand and just at face value it seems to me you need at least two table of contents entries; one with the internal link and one with the external link. You could then conditionally tag those entries in order to produce one set of output meant for internal and another set of output meant for external.

[jkpalmer]

Thanks. I know that my request is a little confusing.

The webserver sits in, what my IT folks describe as, the "DMZ" on our in-house network.

I can publish to one location and anyone connected to the in-house network can access the website using a machine_name/folder and anyone external (only internet access) can get to the website using a published domain name.

I have all this working but in Flare and the website, but all the links in the TOC are "broken" but they work.....

Kinda strange but maybe I'm just looking for some kind of "confirmation" that this is the only way I can make it work.

Jim P.

[ChoccieMuffin]

I have something similar, where users can only see a help nested inside another help if they have that product installed. I have added the .CHM files to the TOC, which shows them as broken links, but it works fine.

[roboHAL]

Thanks. I know that my request is a little confusing.

The webserver sits in, what my IT folks describe as, the "DMZ" on our in-house network.

I can publish to one location and anyone connected to the in-house network can access the website using a machine_name/folder and anyone external (only internet access) can get to the website using a published domain name.

I have all this working but in Flare and the website, but all the links in the TOC are "broken" but they work.....

Kinda strange but maybe I'm just looking for some kind of "confirmation" that this is the only way I can make it work.

Jim P.

Jim, I don't mean to belabor this, but when you indicate "all the links in the TOC are "broken" but they work", to me this doesn't make sense. A broken link shouldn't work. In this case I'm defining "work" to mean you click on an entry in the table of contents and it opens something - a topic, website, another table of contents, etc. I'm sure you've heard the expression "if it ain't broke don't fix it".

[ChoccieMuffin]

Jim, I don't mean to belabor this, but when you indicate "all the links in the TOC are "broken" but they work", to me this doesn't make sense. A broken link shouldn't work. In this case I'm defining "work" to mean you click on an entry in the table of contents and it opens something - a topic, website, another table of contents, etc. I'm sure you've heard the expression "if it ain't broke don't fix it".

Can't speak particularly for Jim, but in my case the links in Flare appear as broken links because I don't bother putting the other .CHM files that I want the user to see in the required folder in my project, I just happen to know what folder they will appear in the end user's setup. So although they appear broken in the TOC, when the help file is compiled and installed to the default directory (the same directory the .CHMs I've linked to) then it all works beautifully. I just have to accept the warnings that appear in my build report.
This is an extract from my TOC:

Code: Select all

  <TocEntry
      Title="[help file name]"
      Link="/Content/[help file name].chm"
      ReplaceMergeNode="false" />

[roboHAL]

ChoccieMuffin, Flare has a Broken Links "report" accessible from View>Project Analysis. Do you mean to say an item appears on this report/list and when you access the item and corresponding link text, it "works" as in opens the link?

[ChoccieMuffin]

ChoccieMuffin, Flare has a Broken Links "report" accessible from View>Project Analysis. Do you mean to say an item appears on this report/list and when you access the item and corresponding link text, it "works" as in opens the link?

Yes, it appears as a broken link in Analyzer. When working in Flare, it is broken. (I suppose I COULD copy the .chm into the \Content folder but I don't want to, as it's created by a different Flare project, so there's no point. If I did copy the CHM I'm guessing the link wouldn't be broken, but I haven't tried it.)

When the help file is compiled and the application is installed on the end user's system, if they have the OTHER application on their machine the link in the compiled "master" help works. If they don't have the other application installed then they don't have anything to click on. So in my books, that works fine.

[roboHAL]

Got it. Thanks for the clarification ChoccieMuffin. I knew I was not completely understanding this thread (I did mention this early on in the thread ). In this case we are talking semantics. When Flare indicates the link is broken, it is with respect to what Flare has visibility to at the point in time the report/query is run. If within project "A" the chm and/or path to it does not exist in project "A", yet you have a link pointing to the location (and name) the chm will eventually be in (or is in currently but the output files from project "A" are not in but eventually will be), then this is perfectly acceptable and can be considered "by design". And if Jim's case is very much the same as yours, then the answer to his question is "no", he is not doing something wrong and "yes" it is expected behavior that the TOC links appear broken.

[jkpalmer]

Thanks to all who weighed in on this topic.

All of your comments and suggestions make sense, and I have the confirmation that I was looking for.

Thanks again!

Jim P.