RESOLVED -- link to file error -- but file "clean"?

[Phlawm53]

Having cleaned up MANY "Unresolved link to file" errors, I have two errors I can't fix.

In Flare 6.1, I'm generating a Word target of a project I'm cleaning up. Where I've had "unresolved link to file" errors, I've used Find in Files to find the referenced files (they were removed from the project), and cleaned up the malformed links to them. It's worked pretty well, BUT…

I can't figure out how to fix the last two error messages that specify the same to-from file, as follows:

Code: Select all

D:\FlareProjects\XXTech\REVISED_XXTECH_WORD_DOC\Content\REVISED_SOURCE_for_IMPORT_to_FLAREv0100\SQL Injection Mitigation for NET.htm: Unresolved link to file: D:\FlareProjects\XXTech\REVISED_XXTECH_WORD_DOC\Content\REVISED_SOURCE_for_IMPORT_to_FLAREv0100\SQL Injection Mitigation for NET.htm. File may not be included in the output.

I open the file and look at it in both WYSIWYG and XML source modes, but cannot find any links. If i search for ".htm" I find no occurrences.

And the topic files are being built into the Word output.

ALSO, if I delete the references to the file from the project's TOC, the error persists.

SO how can I resolve this error?

Cheers & thanks,
Riley

[Phlawm53]

------
How I fixed my own problem.

After deleting the files reported as the source of the error from the TOC did not change the error, I went to the project's directory of files and moved those two files out of the project entirely.

I then re-gen'ed the project. This time Flare reported not only the same opaque errors as before, but two new errors pertaining to "unavailable linked files". In the list of error messages I double-clicked the new errors to open the files. There I found references to the files that were previously being reported as the source of the errors.

I deleted those references and re-gen'ed: Voila, no error.

Bottom line is that the error messages weren't helpful. In fact they were opaque and misleading.

Cheers & hope this helps someone,
Riley

[JudyH]

A lot of time has passed since your post, but I did find it helpful -- thanks. I had a similar situation. I tried your tactic of temporarily moving the one file mentioned to see what additional error information Flare would return on a compile, and I did get more information on the files making the problematic call. (This was in Flare 7.)

In fact, I've found it useful to compile to Word even if Word is not the intended output type because that compile tends to flag problems that don't appear for, say, a PDF target.

[Phlawm53]

By the by, a tool I find useful when tracking down vague or opaque Flare link-to-file errors is jEdit (http://jedit.org/).

Among jEdit's many plugins are Project Viewer. Project Viewer enables one to search files contained in a directory for a string and list the files where the string was found in jEdit's HyperSearch Results tool. I find using jEdit for this purpose to be a bit more pleasant than using Flare's own Find in Files tool — jEdit enables me to more easily view and work with a project's files.

What I've done more than once is take the file name in a Flare linked-to error and search all of the Flare project's topic files for that file name. I can then go through the list of HyperSearch Results until I find a mal-formed cross-reference or links, then use Flare's XML Editor to fix the problem.

------
By the by, jEdit is also a wonderful CSS editor. I run jEdit in conjunction with Flare's own CSS Editor. jEdit, especially when equipped with some Plugins for CSS code completion, enables me to do things faster than clicking my way through the CSS Editor's GUI.

Finally, jEdit with the Project Viewer plugin makes it very easy to work with Flare's Page Layouts and Table files, especially when changing colors. Instead of clicking one's way through multiple Page Layout or Table settings, one can do a Find/Replace across all files (perhaps aided by REGEX), and replace one old color spec with the new one.

Cheers & hope this helps,
Riley
SFO

[GaryUK]

I had this too and struggled to find the source.

We produce PDF output with conditionalised hyperlinks that only work in the help. My problem was that I had included a link to a topic for the help which didn't use the title of the topic as the text for the link. For example, I had a hyperlink sentence as part of another set of instructions ("Open the project", instead of the real title "see Opening Projects"). I searched the pdf output for the problem topic title and examined every occurrence without success. Only when I searched the source code did I find more hyperlinks to the real target topic name, which I hadn't conditionalised. My fault all along.

I have to say though that Flare was not very helpful in identifying the problem, because the error referred to the target topic, not the topic with the problem. Sometimes its very accommodating in opening the offending topic when you double-click on the error, but not always.

[LTinker68]

I have to say though that Flare was not very helpful in identifying the problem, because the error referred to the target topic, not the topic with the problem. Sometimes its very accommodating in opening the offending topic when you double-click on the error, but not always.

If you know what the target topic is, then you can open it and view its File Links, which will show all the topics and other files that are linked in some way to that target topic. Won't necessarily narrow down which topic has the problem, but at least it identifies a subset of topics (and TOCs and snippets, etc.) to look at to see if those topics or other files contain the bad or unconditioned link.