What is the role of the MadCapAll.js file?
I am getting a compiler error/warning:
"Compiler: C:\Working_copies\OnlineHelp_merge\build\CIE\madcap\Content\05- Future Operations\04-Crisis Action Planning (CAP)
\01-CAP Home\A0 - NTP Intro.htm: Missing linked source file: C:\Working_copies\OnlineHelp_merge\build\CIE\madcap Content\SkinSupport\MadCapBodyEnd.js"
It is a nuisance for me. It does not cause a problem with the output products.
However, the SCM group that does the builds do not like to see any compiler problems in their status logs.
If there is a way for me to get rid of them, I would like to make my builds clean.
MadCapAll.js warning in build
-
wclass
- Propellus Maximus
- Posts: 1238
- Joined: Mon Feb 27, 2006 5:56 am
- Location: Melbourne, Australia
Re: MadCapAll.js warning in build
These are javascript files generated by Madcap during the compile - they contain functions to do display stuff like manage the search and index panels, among other things.
I don't know why it would be missing since Flare should create it, but the following might help to troubleshoot.
Different sets of java script files are generated depending on the flag as follows - Open the target that you are compiling, select the "Performance" tab, and look at the first option "Condense Javascript files".
If set, the "madCapAll" file is generated, otherwise a whole bunch of separate javascript files are created. If this flag was set and then reset maybe it got out of whack somehow. I'd try cleaning the project, and recompiling (with the option set to generate the file) and see how it goes.
I don't know why it would be missing since Flare should create it, but the following might help to troubleshoot.
Different sets of java script files are generated depending on the flag as follows - Open the target that you are compiling, select the "Performance" tab, and look at the first option "Condense Javascript files".
If set, the "madCapAll" file is generated, otherwise a whole bunch of separate javascript files are created. If this flag was set and then reset maybe it got out of whack somehow. I'd try cleaning the project, and recompiling (with the option set to generate the file) and see how it goes.
Margaret Hassall - Melbourne
Re: MadCapAll.js warning in build
I have similar problem and i'm faced with two solutions.
First, since these .js scripts are NOT needed for my project (we use the HTML as is in our product), I can remove the <script>...skinsupport...</script> lines from each .htm file Flare produces in the build. A custom PERL script will do this - but of course this produces risk when other writers create output and forget to run the script.
Second opiton, make sure the /skinsupport folder and files are located at the same folder level as your content. IF you look at output, notice that your folders have /skinsupport and /content at the same tree level? The downside to this solution is that I have to have my configuration manager agree to ship this folder in our product, even though I know it is not used - it only eliminates an error I shouldn't have to have in Flare Output.
I guess there's a third option - wait for Flare to include NOT entering these <script> statements into my final files - especially when I set the Advanced Target setting to "don't generate skins". Ugh... I guess I'll go the PERL route just because I can control the final outcome reliably.
Hope this helps.
First, since these .js scripts are NOT needed for my project (we use the HTML as is in our product), I can remove the <script>...skinsupport...</script> lines from each .htm file Flare produces in the build. A custom PERL script will do this - but of course this produces risk when other writers create output and forget to run the script.
Second opiton, make sure the /skinsupport folder and files are located at the same folder level as your content. IF you look at output, notice that your folders have /skinsupport and /content at the same tree level? The downside to this solution is that I have to have my configuration manager agree to ship this folder in our product, even though I know it is not used - it only eliminates an error I shouldn't have to have in Flare Output.
I guess there's a third option - wait for Flare to include NOT entering these <script> statements into my final files - especially when I set the Advanced Target setting to "don't generate skins". Ugh... I guess I'll go the PERL route just because I can control the final outcome reliably.
Hope this helps.