MadCap Software Forums

Of course, Murphy's Law says that right after I rave about this on Twitter, it won't work...

I successfully output a huge project to a WebHelp Mobile target a month or so ago. When I just tried to recompile it, I'm getting the dreaded and decidedly unhelpful error "Object reference not set to an instance of an object".

I've tried cleaning the project, and compiling on two different machines (one running XP and one running Windows 7).

I know this problem has come up numerous times in other threads -- any new ideas?

Tech support helped me with this one. I had hidden a style (in my case it was <a>, I think, but could have been any of the hyperlink styles) so if you have hidden any styles in the interface recently, unhide them and try recompiling.

Best of luck!

Thank you very much for the suggestion! I had recently disabled some styles, so I was hopeful. Unfortunately, it still didn't work. I will contact tech support as well, before I waste any more time on this one.

It would help immensely if the error message told you which object it is your referencing.

jbrock wrote:It would help immensely if the error message told you which object it is your referencing.

I fully agree, but as far as I know the error is what bubbles up from the .NET runtime. That the .NET runtime is suboptimal is a widely known fact.

I'm getting the same error on one of my projects. Of course, it's the one I need to publish today. Did tech support have any helpful suggestions?

I'm just now getting back to this topic after we decided not to use mobile output for our last release. Madcap Support quickly traced it to empty style property. (I can safely say I never would have figured it out.)

Open the stylesheet in a text editor. If a line in the stylesheet says
delete the line from the file. (I expect this error might also appear if styles other than the font are empty.)

They did file a bug.

I've had this problem a couple of times, which has been related to the Target when it has been set as the primary target (Make Primary).
By doing so a reference to the target is made in the UserData.fluserzip file. You can find that file under the Project > Users folder. For some reason the reference/link, doesn't always reset when setting the primary target in Flare. So when you try to run your Primary target it just gives up. Maybe worth checking if all else fails.

I just ran into this same error today. And ChoccieMuffin's comment "I had hidden a style..." was what did the trick for me. Once I went in and enabled the couple of styles I had disabled, I was able to generate output again.

I consider it a bug if there is a feature to hide styles, but using that feature breaks the software.

FYI - I'm using the latest version (7.1) as a demo version to do a pilot project (importing content from an in-house tool) before we buy Flare at my new gig.

HeraTech wrote: FYI - I'm using the latest version (7.1) as a demo version to do a pilot project (importing content from an in-house tool) before we buy Flare at my new gig.

i don't know if this matters to you, but remember that you will get some dummy content when you're using a demo version without a license code.

Just throwing in my $0.02.

I had a project that threw up the Object Reference error for a PDF build but not an HTML build. The culprit was a body tag in one of my topics had a condition applied. The error would appear when Flare got to the pagination step of the build. Apparently, Flare cannot paginate topics that have all the content in the body excluded.

I removed the condition from the body tag, and placed the condition on the TOC item instead. It worked fine after that.

If you get this error on a PDF build, you can run the "Files With Condition Tags" report (Flare 7.1) and look for any Body tags that have a condition applied.

In case it helps someone else, I'm adding my experience to the first topic googling the message found.

I was getting it on compile of HTML5. The problem was a link that had somehow gotten a strange ID (possibly a legacy from Robohelp conversion weirdness). In this case id="a1"". Removing the id entirely fixed the compile issue, but I assume you could probably just change the id to something valid if you need it.

It didn't cause any problems in HTML Help (CHM) output or in Webhelp, but failed with the "Object Reference" error for HTML5.

CORRECTION: it does cause a problem in HTML Help and Webhelp. The significant factors are:
1) a MasterPage is attached to the target being build.
2) a weird id such as id="a1"" appears in the topic code.

I'll submit a bug report to Madcap in the hopes of getting better error messages, or at least more diagnostic information in future.

Amber

Hi,

FYI:

Starting using Flare 9, I got this message in the next situation:
I added a snippet that contains an image to a topic for which no pagelayout is selected. Next I opened the stylesheet and defined for the IMG tag a max-width of several cm (8 to be exact). When generating the output (PDF) Flare goes in to a loop with message “object reference not set to an instance of an object” given from .NET 4 runtime. To solve this I reset the style for IMG to default and deleted the temporary output folder.
I can imagine that the snippet looks to the topics' pagelayout if there are styles that must be used or inherited and when not found this error occurs.
Even if tried to open the pagelayout (that was NOT assigned to the topic containing the snippet) which also contained an image, the same error occurs.
A task manager kill for flare was needed to get out of this loop.

Greeting,
Rene Severens

Hi All!

I had the same problem - ID10086 - "Object reference not set to an instance of an object" during building. They were all CHM Targets in my case.

The whole situation is a bit complicated. I tried removing various folders from the Content folder. Then I figured out that it is caused by two topic files. When those files were removed from the Content everything worked.
So, then I tried to figure out what was wrong with those files and found out that they contained cross-references to invalid XML files in the Content folder.
The files were invalid because they contained the following line:
<p class="TopicLine" xmlns="http://www.w3.org/TR/REC-html40"> </p>
So, the whole problem, which took me about a day to fix btw, was cause not by having invalid files but by CROSSREFERENCING to invalid files.

Hope this will help to somebody in need:)

post edit - yes, and the files were converted from RoboHelp too