Flare v5 - Preview failure...?

[danielg]

So far I'm very happy with what I'm seeing today in Flare 5, however: has anyone encountered the "Failed to compile document: Object reference not set to an instance of an object." error message when you right-click select the file (with ostensibly legal, well-formed XML structure), and choose "Preview"? Everything is apparently working normally with re: to complete & legal XML markup (it can opened in the WYSIWYG editor, no problem; if there was an issue, it usually meant broken XML markup/syntax, which we know, denies our saving the file).
Preview helps me quickly test all internal, external xrefs, besides allowing me to print, to hand back to my engineers for red-lining. Anyone..?
Thanks for any help, in advance.

[KevinDAmery]

Does this happen with every topic, or just some topics? Reason I ask is that most of my topics preview, but I have some that popped up that error in 4.2 (and from what you're saying presumably will continue to do so in 5.0). I haven't identified what the problem is exactly.

[danielg]

Hi, Kevin.

Perhaps you've already seen my response to my other posting. I tested Preview in v4.2 first thing this morning with the subject .htm I'm developing, and Preview works with this version, no problem. Attempting Preview with this or any other .htm topic file in v5 however still results in the same failure (with the same error message), even after a cold reboot. Hmm.
Have the developers there ever discussed the feasibility of offering output build utility of a single .htm topic file..? That would be slick; Flare would provide a dialog box giving the user the ability to direct where to copy the output, which would obviously be the subject .htm topic along with all asset files (graphics, .pdfs, media files, whatever the .htm has as interdependencies). Just a wild and crazy thought; it would certainly help me with red-lines communications.

Thanks & cheers, =dg=

v5previewfailure.gif

[KevinDAmery]

Have the developers there ever discussed the feasibility of offering output build utility of a single .htm topic file..?

I wouldn't know, as I'm not a Madcap employee. MVPs are Flare users who Madcap have invited to help address other user's questions on the forum, so I really don't have any inside knowledge of what the developers are doing.

[LTinker68]

... error message when you right-click select the file ... and choose "Preview"?

Does the same error occur if you click the Preview icon in the XML Editor toolbar, or does it only happen from the right-click menu?

[rob hollinger]

Daniel,
Any time you get an "Object reference error", Please open a bug ticket.
Id like you to get me this topic with its associated files if possible.

https://www.madcapsoftware.com/bugs/submit.aspx

[Sharon_G]

I opened a bug because I got the same error when I tried to preview or generate WebHelp as well. In my case I was using multiple instances of "Separator" in my toolbar to space out my icons.
When I removed all instances of "Separator" from the toolbar, I could generate and preview without the error. When I added back a single instance of "Separator", I could preview and generate. However, the moment I added a second instance of "Separator" the error came back. Perhaps mistakenly, I assumed that in 5.0 you can no longer use multiple instances of this class and that this was what produced the error. (The good news is that you can now add padding between toolbar items so you no longer have to use the separator hack.)
If you use mutiple separators on your toolbar I'd be curious to know if removing them solves your problem as it did mine.
Sharon

[danielg]

Hello, all.
Lisa, thanks for responding. I tested what you suggested, and I still get the same "object reference not set to an instance of an object" error message. I tried it with the subject file of course, and arbitrarily chose other .htms. Same result, regardless whether I initiate the Preview from right-click menu, or the XML Editor button.
Rob, sending you the subject .htm I'm developing with all of its assets won't happen; JTMS (just too much stuff ). Every .htm I've attempted to Preview in v5 has "failed to compile" anyway, so right away I can see it's not going to be worth the time & effort.
Sharon, thanks for the input. I don't think I have any separators in my .htm source (not 100% clear about just what that is, at least yet ).

Thanks, everyone. I've rolled back to v4.2 for the time being, and I'll check back when I can.

Cheers, =dg=

[rob hollinger]

Daniel,
When you get a chance, create a new skin, attach it to the target, then test the preview.

Sharon's problem came about because there was a style that had " " for the label.

Im wondering if you might have something similar causing the issue.

Have a great weekend

[danielg]

Daniel,
When you get a chance, create a new skin, attach it to the target, then test the preview.

Sharon's problem came about because there was a style that had " " for the label.

Im wondering if you might have something similar causing the issue.

Have a great weekend

Hi, Rob.

Which style(s)..? Hopefully just one or a few at most. Something obviously changed in the compiled code between v4.2 and v5; is there any plan to investigate/accommodate from Madcap's end..? Right now I'm in the Skin Editor, looking at Styles. It's not a big disaster, I guess, as I'm continuing to use v4.2 until this gets resolved. Hopefully soon; I for one really appreciate the v5 upgrade to the Internal Text Editor. Thanks & cheers, ,

=dg=

[Robotman]

Using Flare v5.0 I get an object reference error when building both webhelp and dotnet. I have created/edited new skins, new tocs, new outputs. Same error.

Error is:
Object reference not set to an instance of an object.

I don't get the error when creating a new sample application help in v5.

Still early in looking into this problem. I haven't opened a support item for it yet.

[Sharon_G]

Hi,
Yes, as dg said, removing the " " from the label field fixed the problem for me. The only issue I have is that I hadn't entered those characters in the label field to begin with. I checked in the 4.2 version of my project and they were there as well, but not causing any problems - so I guess the skin gremlins were at work. It is definitely worth checking to see if you have any odd label characters in your skin - even if you know you didn't add any.

I'm still interested in why these characters affected my ability to use the Separator multiple times.

I think this is a good illustration of why it would be very useful to provide a complete WebHelp SDK to the users of Flare who are interested. Right now there are so many hacks and tweaks that you need to know about in order to do anything beyond the basics. Complete SDK documentation for those of us who want to go further would be a beautiful thing

[danielg]

Hi,
Yes, as dg said, removing the " " from the label field fixed the problem for me.

Hi, Sharon. It was Rob that pointed it out; not I. Now: have you globally found/replaced all instances of this issue in your project(s)? Finding a single instance of it in an Internal Text Editor session will allow you to search every .htm in your project and replace with zip, i.e., erase it. We shouldn't actually be going here, however; every version of Flare heretofore has built our source error-free, but v.5 introduces issues with skin generating for what is now an indeterminate number of users, apparently. Please, can you be specific about which styles' Label attribute to search for?
Thanks & cheers, =dg=

[LTinker68]

If it's related to a problem I reported before, then it was only the label and/or tooltip fields of the toolbar items.

[danielg]

If it's related to a problem I reported before, then it was only the label and/or tooltip fields of the toolbar items.

Hi, Lisa. Apparently not; I checked each ToolbarItem style, and each has (not set) as their set parameter. There is one style here however that I created a long while ago, and only that one has text in the Label attribute, but not "". I'm viewing all of this from the Styles tab in the Skin editor; is there a better means to use to check this..? Thanks, =dg=

[LTinker68]

No, that's how I view it.

You could try opening the skin file in Notepad and look at the tags listed and see if any of them have an empty property.

Or if you have an old copy of the project (one created in v4.x), compare the old skin file with a skin file created in a new test project in v5 (compare using Notepad) to see what structural changes may have been made. That might narrow down what you have to look at in the Skin Editor.

[danielg]

No, that's how I view it.

You could try opening the skin file in Notepad and look at the tags listed and see if any of them have an empty property.

Or if you have an old copy of the project (one created in v4.x), compare the old skin file with a skin file created in a new test project in v5 (compare using Notepad) to see what structural changes may have been made. That might narrow down what you have to look at in the Skin Editor.

I'll take a peek at the skin file, but using an editor that won't potentially pollute the file with the ANSI char set, as simple Notepad can do if you're not careful. Not that I'll be editing anything... .

This all begs an answer to a question, tho' (albeit rhetorical); why should the end user be relegated to be doing any of this investigative process? Is it really incumbent upon me to 'fix it in my source', or more logically wait until v.5 can cleanly build the ~1 GB of source that v.4.2 still can build, without a single warning let alone error?

[KevinDAmery]

This all begs an answer to a question, tho' (albeit rhetorical); why should the end user be relegated to be doing any of this investigative process? Is it really incumbent upon me to 'fix it in my source', or more logically wait until v.5 can cleanly build the ~1 GB of source that v.4.2 still can build, without a single warning let alone error?

<also rhetorically, sorta>The user shouldn't have to - but, as those of us who have been in software development for a while will have learned the hard way, even the most rigorous inside testing program and beta won't find everything that the full user community will do with the software. As usually happens, the new Flare release has a case of new-versionitis (version 4.0.0 and 3.0.0 had some quirky bugs too as I recall, which were mostly fixed in the first round of patches). </rhetorical off>

Best bet is send Madcap a copy of your skin and hopefully they can use it to figure out what they broke in the application.

[RamonS]

Well, to be honest, MadCap could run better betas....but that's a discussion that runs outside of this issue. I agree with Kevin, send the stuff over to MadCap and they usually figure it out.

[danielg]

This all begs an answer to a question, tho' (albeit rhetorical); why should the end user be relegated to be doing any of this investigative process? Is it really incumbent upon me to 'fix it in my source', or more logically wait until v.5 can cleanly build the ~1 GB of source that v.4.2 still can build, without a single warning let alone error?

<also rhetorically, sorta>The user shouldn't have to - but, as those of us who have been in software development for a while will have learned the hard way, even the most rigorous inside testing program and beta won't find everything that the full user community will do with the software. As usually happens, the new Flare release has a case of new-versionitis (version 4.0.0 and 3.0.0 had some quirky bugs too as I recall, which were mostly fixed in the first round of patches). </rhetorical off>

Best bet is send Madcap a copy of your skin and hopefully they can use it to figure out what they broke in the application.

Well, to be honest, MadCap could run better betas....but that's a discussion that runs outside of this issue. I agree with Kevin, send the stuff over to MadCap and they usually figure it out.

Hi, guys.

Yeah, after a quick chat with Ryan yesterday afternoon, I posted a bug report with a copy of my skin file. As I've been expanding our service site output by merging in addition to creating new sites, I usually been setting dev environments up with copies of the .css, skin, etc.; this simple fact helped narrow the field of usual suspects.
I realize now I was really at risk getting tagged <whiner> </whiner> when it goes without saying that with a case like this, the expanded team effort is obviously better for making the product more bomb-proof. Thanks for your input & encouragement.
Cheers, =dg=

[rob hollinger]

The "Label" field for the Logo is not supported for the Logo style. Its not part of the property group.
Ive submitted a bug that the Skin editor only display the supported properties for each style.

Open the Skin to the styles tab.
Click on the Logo style.
On the right top, choose "Alphabetical List" to list all properties.
On label - Remove the "Click to see the version of FOXHelp" so it reads (not set).
Save and generate.

[danielg]

The "Label" field for the Logo is not supported for the Logo style. Its not part of the property group.
Ive submitted a bug that the Skin editor only display the supported properties for each style.

Open the Skin to the styles tab.
Click on the Logo style.
On the right top, choose "Alphabetical List" to list all properties.
On label - Remove the "Click to see the version of FOXHelp" so it reads (not set).
Save and generate.

After solving this issue for the test case I sent in with the bug report (of a smaller side project), I attempted to build the rather large service site output that's intended for authenticated users only. When "Generating output skins...Compiler (Internal Error): Object reference not set to an instance of an object." occurred, it was back to the drawing board.
Searching the Skins file in text mode, I could quickly see every instance of "Label" in the ToolbarItems group. As it turns out, we had created a style in this group ("About FOX"), and sure enough, it had a text string entered into its Label attribute. We're happy to report that all is well here with v.5 of Flare; we can now build and Preview single .htms at will.

Cheers, =dg=

[Sharon_G]

I know that I've said this before, but I'll say it again on this thread - and call me a whiner if you will...
If MadCap is not going to provide a UI that allows the user to configure all aspects of the Skin, then they should provide an SDK for those of us who want to go beyond the basics.
Is this an unreasonable request?
Sharon
Off to whine at somebody else now...

[danielg]

I know that I've said this before, but I'll say it again on this thread - and call me a whiner if you will...
If MadCap is not going to provide a UI that allows the user to configure all aspects of the Skin, then they should provide an SDK for those of us who want to go beyond the basics.
Is this an unreasonable request?
Sharon
Off to whine at somebody else now...

Just as a basic observation from this episode: it seems a reasonable request by any Flare user (i.e., esp. those of us with significant legacy Flare output that's released to the world) to be given a 'headsup.readme' of any code tweaks that might impact us as significantly as this one did. That is, if it's at all possible; I realize it doesn't take much to cause such a negative cascading effect, and it easily could have been far worse. The style editor is a *HUGE* sandbox to muck about in. It certainly doesn't make a lot of sense to me, to allow potential style attribute assignments that turn out to be denied in new version releases, i.e., that will cause the source build to break.

Just a food for thought; thanks for listening.

Cheers, =dg=

[sanjsrik]

I cannot believe that 5.2 versions later this is STILL an error that is just as cryptic and STILL unresolved? I am very amazed that no one at Madcap has made a more descriptive error message than this.

I'm using 10.2 and all of a sudden when trying to preview topics, I am seeing this EXACT error message and have no idea why. I've restarted both Flare and my machine and still getting this issue.

Anyone getting this on 10.2 preview topic?