MadCapxxx.js etc - What do they do?

[Cecily]

I have just upgraded to version 4. One of my projects now has compilation errors that it didn't before. They are all of the form:
Failed to copy linked file xxx to output. The file xxx already exists.

The files in question are all ones that I wasn't consciously using:
MadCap.css
MadCapBodyEnd.js
MadCapEffects.js
MadCapEffectsMenu.js
MadCapGlossary.js
MadCapUtilities.js

The compiled help looks and functions OK, but I don't like having unresolved errors every time I compile.

I have looked in Flare's help and here, but can't find anything. Any ideas, anyone?

Thanks.

[Richard Ferrell]

In Flare in the Content Explorer do you have a fodler named SkinSupport?

[Cecily]

Yes, but I don't use what's in there (as far as I know). The projects which do have a skin support folder were via a previous author and had been partly or wholly developed in RoboHelp, but they were OK in Flare 3.1.

The projects which are OK don't have such a folder and were created from scratch in Flare v3.x.

So should I just delete the folder?

[Cecily]

In the project that was newly giving me errors, I've successfully deleted all those SkinSupport files and no longer get compilation errors, so thanks for pointing me in the right direction.

However, I have inherited a related project that already had these errors and when I right click and Show Dependencies for the SkinSupporet files, it lists every/nearly every topic in the project. How do I discover what those topics are actually using them for and fix things so it compiles without errors (the actual output is fine, but I don't like having irrelevant errors, especially in case I then don't notice other, unrelated ones).

[Cecily]

Actually, the MadCapGlossary.js didn't have any dependencies, so I deleted that with impunity.

But please can anyone tell me what the other files do:
MadCap.css
MadCapBodyEnd.js
MadCapEffects.js
MadCapEffectsMenu.js
MadCapUtilities.js

I tried deleting MadCapBodyEnd.js, but the dependent topics had //**// //**// added to the top left corner, even though there's nothing visible there, so I had to revert to the previous version.

As I've had some problems with the build on a help server, I don't want to mess around experimentally deleting the rest of them, but would love to know how to get rid of the errors and/or the files.

Thanks

[RamonS]

Based on the original error it appears as that there is an issue with overwriting the files in the output folder. Did you try deleting everything that is in the output folder and then compiling again? I would be surprised if you still get the errors.

[Cecily]

Thanks for the suggestion, but I just deleted everything under Output, compiled and got exactly the same errors re MadCapxxx.js files already existing.

A previous author imported some of the content from RoboHelp on a Mac, so there are RoboHelp remnants around. Could they be a factor? Also, there are kanchor tags that may not be relevant, but I don't think you can check dependencies for kanchors, hence I'm reluctant to delete them.

Any more ideas, anyone?

[LTinker68]

Where are you checking the MadCapxxx.js files that you're seeing whether they have dependencies or not? Those files are generated automatically when you compile, so they're not in the project for you to check from within Flare.

Make sure the output isn't being built back into the content folder.

Also, are you using source control? Do you check-in the output files, and if so, do you build the output directly into the source control folder or do you copy them over after the build?

[Cecily]

Where are you checking the MadCapxxx.js files that you're seeing whether they have dependencies or not?

In Content organiser: Content > Skin Support. Is there somewhere else to do it?

Those files are generated automatically when you compile, so they're not in the project for you to check from within Flare.

Well, I may not know how they got there, but they are definitely there! And when I deleted one, it wasn't recreated at compilation and the compiled help had erroneous characters at the top of each page.

Make sure the output isn't being built back into the content folder.

No, it isn't. I just deleted everything in Output (as per RamonS's suggestion) and when I compiled, all the output was recreated in the Output folder.

Also, are you using source control?

Yes, the Flare project is bound to TFS.

Do you check-in the output files

No, only the Content and Project directories. The help is recompiled on a build server and creates its own Output directory there.


Thanks for your help in ruling some things out...

[LTinker68]

Where are you checking the MadCapxxx.js files that you're seeing whether they have dependencies or not?

In Content organiser: Content > Skin Support. Is there somewhere else to do it?

Ah, there you go. There shouldn't be a SkinSupport folder inside the Content Explorer. It'll be in the Content folder of the Output folder, but you shouldn't see it in the (project) Content folder in the Content Explorer. If you do, then it means that at one point the output was generated back into the project Content folder, which is very very bad. Shut down Flare then make a backup of your entire project folder (the parent project folder that contains the Analyzer, Content, Output, and Project folders). After backing them up, delete the SkinSupport folder that's in your project's Content folder. Launch Flare, open the project, and try to build it.

[Cecily]

the Content folder of the Output folder

At first I couldn't see one, but then found it buried several levels down (below Temporary).

at one point the output was generated back into the project Content folder, which is very very bad.

How bad? Are there other issues I should be watching out for (and I wonder how it could have happened in the first place)?

However, If I delete the erroneous SkinSupport folder, the binding with TFS is likely to get in a muddle, isn't it? And if so, the continuous build on the build server will fail (again) and the developers will complain... But I guess I'll have to bite the bullet and go for it anyway.

[RamonS]

You'd need to remove that folder from TFS as well otherwise it will come back to bite you.

[Cecily]

Thanks Lisa and Ramon. That's great: deleted in TFS and compiled fine locally, with no stray charcters in output. (Fingers crossed that the build server is OK too.)