Can you fix your help project (via coding) after importing a topic from an output file by mistake?

[SteveCTWriter]

Yes - I admit it - I imported html topic files from an output folder of another RH project into the help project I am currently working on (the source files were lost and I needed to bring over a lot of legacy content in a hurry). However, I completely forget that the RH output html file contains unique Java scripting that is used to render the topic properly in a browser, but that same Java Script causes havoc when you open it up in as a source file in another RH Project. Needless to say, it has caused numerous weird things when I went to publish and view my files (but, surprisingly, you don’t really see or notice them in the RH Design WYSIWYG view or preview mode).

The bad news is that it took about 2 weeks for me to notice the issue (the help output is viewed on a special console running Linux with a QT browser that I only view occasionally). The good news is that is that I figured out what the problem was (that took some hours) and I can restore my help project back to a time before I did the "naughty deed".

I am now at a crossroads - do I:

• Try to re-enter all of my content from the last two weeks? (Actually, to avoid repeating the same mistake twice, I will need to re-enter the text manually and NOT cut and paste from the RH output files!)
• Or locate and find the offending HTML coding in my topic files (if that is even possible)? Has anybody documented what the RH output file JavaScript code injects into your files, and what files they affect?

[Captiv8r]

Hi there

The article linked below may be of value to you.

Click here to view

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7, 8 or 9 within the day! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[Peter Grainge]

You missed the third option, fall on your sword.

Take a look at Rick's well worn instructions. http://www.robowizard.com/RoboWizard/NewProject.htm#MonthlyScry/062004.htm

You should be able to do some search to find the affected topics or in the Topic List, add the column Modified Date. (Right click on the headings)

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

Thank you for suggesting Rick's column. It gave me the idea of using the Edit > Find and Replace in Files command and searching for all instances of "script" in my topic files.

I only found three topics (out of 225) that had JavaScript code in them, and I removed all code between the <script> commands. After I republished my project and viewed it on my console with the QT browser, however, it didn't solve the issue. Maybe if I described the issue I'm seeing in more detail, it may help.

The help for the home (default screen) displays correctly the FIRST time you view it. However, if you move off that help screen to another help screen (using breadcrumbs, hotlinks, or the TOC), and then return to that screen, that screen no longer displays correctly (proper styles are not being applied to the text). Also, all other screens thereafter display incorrectly. What's weird is that the help files I found the JavaScript in them (and removed) are not even the ones being accessed when the issue occurs.

Is this problem an indication of a JavaScript issue within the browser? If so, what over places (besides the topic files) could be throwing off the browser and possibly I missed in this "cleansing" process?

[Peter Grainge]

Sorry I didn't pick up on your first post stating you are having this problem with QT browser. It isn't a supported browser so first let's establish whether the help works on Windows using IE and / or FF.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

The current ("bad)" help files work perferectly under IE, Mozilla Firefox, and Chrome. And, yes, Peter, you are right that the QT browser is "officially" not supported. However, the WebHelp I was generating for it was working fine from the beginning of my project until several weeks ago. As part of my investigation into this issue, I restored my help to a point several weeks ago on my viewing machine and it works fine, so I know something happened in the intervening time (like me starting to import topics that were output files).

Let me also throw out something else strange I noticed in this intervening time (approx. two weeks). For some topics, I noticed that when I pasted some content from another source (e.g., Word or an html file), and I went to apply an existing RH style to it by double clicking on that style and asking to reapply that style to the text highlighted, RH would (sometimes) generated spurious "local" formatting on top the style that you choose in addition to applying local" formatting on other sections of content within that topic. The insidius part of this anomaly was that you didn't notice this formatting change in either either Design View or Preview Mode (unless you happened to be looking at your styles dropdown), but ony after generating and viewing the help. I've attached a document where I try to explain what is happening.

Any theories or ideas?

[SteveCTWriter]

I just realized you can't attach a document in these forums... Pehaps I can email to anyone who is interested? It's got four screen grabs with text and callouts.

[Peter Grainge]

When you reply there is a camera icon. Use that to insert the screenshots so everyone can see.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

OK - here is the documentation of this weird issue (hopefully, you can read the htlm code in the screen images):

1. In this topic, I cut and pasted some text into the table you see at the bottom of the screen. I had to reapply the “TableBody” style to this text. After doing this, I moved my cursor to the “Keyboard" text on top. Notice that it is displaying the "TABLEBODY" style, although visually, it is displaying the correct style on screen (“Heading 1”).  

2.     In HTML view, notice the addition of the class= “TableBody”> code for this “Keyboard” text.

3.   I then reselected Heading 1 for this “Keyboard” text.

4.   Notice that the class= “TableBody”> code is now removed for this “Keyboard” text and has just the proper <h1> tagged assigned.

[Peter Grainge]

In the first screenshot, the fact that the style is in CAPS is telling you the style is not in the CSS. Because the class tag is H1 you are seeing that in the second screenshot. All that is happening in the next two is you are applying H1 with no class.

Is there a class TableBody as part of H1? Seems an odd combination.

Is the clean up to search on what you have shown in the second screenshot and replace with <h1>?

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

Peter - I finally figured out this weird thing in RH. It probably only affects me, but here's what happens.

When I open a new, blank topic, the default placeholder text appears. Instead of deleting the text, I open up another topic, copy the first few lines (which includes Header 1), and paste it into the new topic. For some strange reason, sometimes RH includes the class TableBody as part of the Header 1 style. In addition, when the cursor is over the Header 1 content, you see the TABELBODY style style as shown in an earlier figure, even though on screen it looks perfect. I then have to manually reapply Header 1 style to the text to override the class TableBody.

My advice - be wary when copying text to or within RH. Thanks to you and others, from now on I am now using the PureText utility for my copying and pasting...!

[Peter Grainge]

I think you need to look at the code in the source topic from which you are pasting. I have never seen anyone report that problem so it seems odd that it would do it for you.

Try going back to your old way until it happens again and then check the source.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

As always, Peter, you are right. After doing more research, I noticed that this junk code was in in 95% of my topics. I must have inadvertently copied this junk code from a topic at the beginning in my project which wound up in virtually all of my subsequent topics. I suspect this all came about from my initial importing of RH output files into my project early on.

It would be nice if RH could somehow recognize an "output" file during the importing of an html file and notify the user in a warning, such as: "Are you SURE you want to import an output file such as this?"

[Peter Grainge]

No sir, not Always.

No doubt Adobe could do something to warn you that a topic being imported is an output file. That is something you could suggest.  Please follow this link.

http://www.Adobe.com/cfusion/mmform/index.cfm?name=wishform&product=38

Sometimes though the problem is that people publish to the source folder. You could request that is also covered but I think that might be rather more difficult.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

I ran into this same issue yesterday. Again, the "TABLEBODY" style was applied locally on top of text using "HEADING1" (the correct style). Likewise, this happened unbeknownst to me, until I saw it pop up on the Style Menu when my cursor was placed over the text. In Design mode, it correctly rendered it as "HEADING1", but in HTML mode, I saw the TABLEBODY" style applied along with "HEADING1".

Because this was a brand new topic and I had checked the HTLM code before entering text, I can confidently say that RH generated this spurious code (vs. it being copied from another topic by me). In addition, it seem to have happened when I was adding content in the topic (in Design mode) right after I did a combination of key commands (like maybe highlight, delete, scroll?), but I'm not sure exactly what they were.

I hope to someday figure out the exact key commands that creates this issue so I can present this to Adobe (and to this forum).

[SteveCTWriter]

I ran into this same issue again, where my "TableBody" style was applied locally on top of other text in a topic (in today's case, on top of using the "Normal" style). This time, however, I noticed a few more things when this happened:

1. I had two topics open (say "A" and "B").
2. In topic "A", I had my cursor in a table where I had just made some changes (uses the "TableBody" style).
3. I clicked Save Component (floppy disk icon) while still in topic "A".
4. I went back to topic "B" and had my cursor in text (uses "Normal" style).
5. I noticed that the asterisk (*) did not disappear from topic "A" (like it should after you do a save), and the floppy disk icon was grayed out. Thought that was a little strange.
6. I closed topic "A" and it prompted me to save the changes. I chose Yes.
7. I went back to topic "B", and placed my cursor in in the same paragraph that I was in in Step 4. I noticed immediately that "TABLEBODY" displayed in the style dropdown box instead of the "Normal" style. The fact that the style was in all caps told me that this the style must have been applied by locally (as has been the case all along with this issue). I switched to HTML mode, and I verified that the "TableBody" tag was indeed placed along the normal style.

This explains why I couldn't produce this issue at will - it seems this RH bug only occurs after you try to save a topic using the Save Component (floppy disk icon) and it doesn't "register" at first. Then, when you finally get the topic to save, weird things happen...

I am using RH version 9.0.2.271 on a Windows 7 platform. I assume that this version has the latest patches, as when I run Help > Updates, it says all applications are up-to-date.

[SteveCTWriter]

I realized that I may have reversed Steps 3 and 4 in my posting above, so this could be how it happened (from a programming view, this seems to makes more sense to me anyway):

1. I had two topics open (say "A" and "B").
2. In topic "A", I had my cursor in a table where I had just made some changes (uses the "TableBody" style).
3. I went to topic "B" and had my cursor in text (uses "Normal" style).
4. I went back to topic "A" and clicked Save Component (floppy disk icon).
5. I noticed that the asterisk (*) did not disappear from topic "A" (like it should after you do a save), and the floppy disk icon was grayed out. Thought that was a little strange.
6. I closed topic "A" and it prompted me to save the changes. I chose Yes.
7. I went back to topic "B", and placed my cursor in in the same paragraph that I was in in Step 4. I noticed immediately that "TABLEBODY" displayed in the style dropdown box instead of the "Normal" style. The fact that the style was in all caps told me that this the style must have been applied by locally (as has been the case all along with this issue). I switched to HTML mode, and I verified that the "TableBody" tag was indeed placed along the normal style.

[SteveCTWriter]

OK - still another "incident" today:

1. I was working with both my RH project and a Word (2010) doc opened so I could compare content and occasionally copy and paste text snippets from Word into RH. (FYI - I am using a special utility that only pastes text - NO formatting is included.)
2. I had "left" RH for awhile (i.e., it was in an "inactve" window), and then decided to go back to RH to either type (or paste some text) into one topic that was opened. After I clicked Save Component (floppy disk icon), I noticed that the asterisk (*) did not disappear from the topic (like it should after you do a save), and the floppy disk icon was grayed out. However, this time when I went to close the topic, I did NOT get any prompt to save the changes - the topic just closed.
3. I reopened the topic and it did retain my changes. In this instance, there were no other topics opened in RH, so I couldn't see any "collateral" damage anywhere else.

I never mentioned until today's post that I normally have several apps open on my PC (usually Word, Excel, Outlook, and IE) while working in RH. However, with 4 GB of RAM on my laptop, I don't think that should be an issue nowadays. Based on today's events, however, I am beginning to wonder if there is some sort of memory cache issue going on between RH and the Windows OS?

[Peter Grainge]

I don't think the issue is related to other apps being open. I think it is more likely related to which tab RoboHelp thinks has focus.

Instances of RoboHelp not clearing the asterisk when Save Component has been used have been reported. Personally I use Save All.

Maybe as well as click a tab you could try clicking in the Design Editor to see if that makes any difference.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

Peter - thanks - I hadn't realized that this issue of RoboHelp not clearing the asterisk when you click on Save Component has already been reported. Based on my experiences, I'm going to add that "collateral" damage may result in another open topic when this occurs, and make my own submission on the RH bug/feature page.

FYI - I used to use "Save All" for all of my saves, but after I started adding images in my current project, the time it took to do a save went from a few seconds to over 30. I like to save often (due to the numerous crashes and other anomalies I've experienced in RH over the last few months), so waiting 30 seconds is intolerable.

[Peter Grainge]

There's something seriously wrong then. If you cannot replicate this in another project, some detective work is needed.

Tablebody has not been reported and 30 seconds is way too long. Your project is on your local drive and not on a network I hope.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[SteveCTWriter]

The project is on a local drive. Good news, though - I tried using "Save All" in my project and the time is down to about 10-15 seconds. That's tolerable for me. I think it improved after I cleaned up  the junk code than came in as a result of importing the RoboHelp html output topic. I'll be starting to use this method again.

BTW - What do you mean by "Tablebody has not been reported"?

[Peter Grainge]

Not reported by anyone else.