Why is FM10 crashing when I change conditional text settings?

[scaton]

When I go from "show certain conditions" to "show all" in some, but not all, files in a book, FM 10 crashes.

I've tried saving as MIF, then reopening, but it still happens eventually.

Sometimes it happens with the first file I open, sometimes not until after several files have been opened and

had their conditions changed, so it doesn't seem like a memory leak.

[Tekscribe]

Your workarounds work for me: a) Cheers!, b) imagining (no resources for plotting) a Frame-less world, and c) do it, do it, do it 'till you're satisfied (whatever it is). This FM plague has been going on for a while with you - yes? Been a problem here since spring, maybe here and there before. Are there others out there with this FM affliction?

Is Adobe paying attention? I get no response from the engineering gang. Adobe corporate clearly lacks the courage to fess up and Do the Right Thing. Fix it. Sigh. Back to Frank's workaround a)

[Bob_Niland]

We're still using FM7.1/Unix, and don't see this problem, but I'm wondering, for those suffering, is there any change in behaviour if you use a separate .book for each combination of Conditions?

We do this for badge engineered product versions and domestic vs. export editions. You probably still have to perform the Show/Hide to all the shared component files within each book prior to rendering.

[Sten Möller]

I wonder if this whole thing has something to do with tables. It certainly has nothing to do with MIF or FM 8, at least not in my case.

I have a book with a TOC and then 19 chapters (files) and 7 condition tags. Recently my customer needed an 8th condition tag. OK. Added to all chapters. Works fine chapter by chapter. BUT when preparing to save the entire book, hiding condition tag indicators and then attempting to show/hiding only 1 condition, FM crashes.

After the crash, show/hide action caused FM to crash in the TOC and in two of the 19 chapters (files). But only these three. And what they have in common is tables with a varying number of condition tags for various rows. The other 17 chapters are fine and I can do whatever I want with them and all is well. But the files with tables are corrupt.

Then I copy backup files and do the revision work all over again and save the files. All is well, and I can show/hide anything within the files. So they appear clean. Start the book again and upon show/hide for the entire book the whole thing crashes again and it's the TOC and the same files that are corrupt again.

After hours of trial & plenty error I discovered that if after having redone the TOC and the two corrupt (again) files I saved every file with no condition tag indicator shown and show all, the book show/hide function detected this and I could then use show/hide to show only one condition. Update book & references & TOC and save as PDF, Everything worked! Until I tried to change the condition shown to another condition, when the whole thing crashed again. I later discovered that I could' even go via show all before showing only a new condition. C-R-A-S-H.

I eventually called Adobe Support and had a chat with a chap in India. He tried MIF, he tried to create a completely new document with a new set of condition indicators (on my computer, remote controlled) etc., etc. He couldn't get it to work, and the only thing he said eventually was basically to try to create new files again and there was nothing wrong with the FrameMaker application. To that I can only respond with a classic British expression: My foot.

I wouldn't mind updating to FM12 if it weren't for three things: This is the last update for this project and for the next project the customer wants to use an application that somebody in his company can handle (we'll see about that :-), I don' have any other customers using FrameMaker, and finally: FM12 is a costly thing to try, as there is no sign from Adobe that they have even acknowledged this problem. Thus I have no clue as to whether this problem has been acknowledged and sorted out. And then wasting a bunch of money for nothing seems rather stupid, doesn't it.

What I find most disappointing about the whole thing is Adobe's seemingly absolute silence in the matter. I have nowhere on the internet found them responding to it.

[Jeff_Coatsworth]

Are you completely patched up?

[Sten Möller]

Thank you for a swift response, but could you explain exactly what you mean by "patched up"? I'm no hacker and therefore not entirely into the computer lingo. I wouldn't have a clue as to what or how to patch up...

[Jeff_Coatsworth]

What version of FM 10 are you running? Check Help > About and Help > Updates to see if there are any patches that need to be applied.

[Sten Möller]

OK. This is Version 10.0.2.419, part of the Technical Communication Suite 3.0.52 updated in accordance with the Adobe FrameMaker help page after my licensing for the product had allegedly expired... According to Adobe application manager there are no further updates?

[Arnis Gubins]

You're patched to the latest version of FM10.

FM9 & 10 were a bit dodgy in a number of areas, with condition indicators being one of them. FM12 is much more stable (than those) in all respects.

You can download the trial version of FM12 to see if the same crash still occurs in the same three files (update a copy of all files in the book first and you may need to create  new FM12 version of the book file - the book updates can be wonky). If it does, then you know that FM is still borked. If not, then you have some options for future projects.

[Sten Möller]

Hmm. You're onto something. The trial version might be an idea. 'Tis only sad that - in case it works - I would have to fork that much money for getting a bug in an application fixed. If I had mucked up like that, I would certainly fix the bug for free. New versions are to be paid for in order to get more possibilites and improved functions, not to get a function already paid for to function at all...

[kevindi]

We have been using Structure FM for over 10 years, migrating templates along the years and currently have FM10 in production environment.

In my experience the only time I have had this issue is when the condition being set has a system variable assigned to it, in our case the system date 'Current Date (Long)'. The effect is the document component file becomes corrupt and the system crashes.

As a test you could remove the system variable from the template and confirm that setting the condition does cause the problem. You would then need to clean up the template do a MIF wash and recreate the template.

[Sten Möller]

Thank you for that suggestion, but it doesn't apply in my case. My condition has no system variables assigned to it, it's just a simple implementation of the show/hide function for different maintenance intervals in maintenance instructions. As I wrote, the corruption comes up only in the three files with tables.

[max_drawdown]

@Tekscribe,

It's a pleasure to join you in sharing @Frank Steller's workaround a).

I notice this from you:

We simply update the book with ALL conditions showing - its ugly but there's no crash - and the x-refs get updated. Next we set the desired show conditions, then update with All Cross-References check box cleared - no crash. We are able to get on with work, produce PDF, etc.

I have so much text conditionalized here that entire paragraphs and even pages of material vanish or appear with the conditions. That is, pagination changes when (enough) conditions change. After clearing the All Cross References check box and updating, are they accurate?

Best regards,

[Matt-Tech Comm Tools]

Given that you're on FM10, not the current version, I wouldn't expect Adobe to be issuing a patch anytime soon...

I didn't have any crashes like you describe, but wiped my machine and reinstalled Win7, TCS4, et. al. I suspect the culprit was having installed, uninstalled, reinstalled TCS components for the last year as needed for clients and beta programs.

Problem solved (other than the pain and stress of reconfiguring and restoring needed files from backup.

-Matt

[Guest]

Matt -

Definitely not what I want to hear!

Wiping the machine and reinstalling everything seems daunting, but I guess it could be worth a shot if it solves this issue. Luckily for me, my books are small enough that I can set the conditions for each file in the book separately and FM doesn't crash. However, for other users with massive book files and a large number of conditions to show/hide, doing this manually is just not ideal.

Smitty

[Matt-Tech Comm Tools]

Yep, unfortunately for me, the answer wasn't what I wanted to hear either!

Such is the price we pay for "progress", eh?

[Tekscribe]

Matt,

I do not agree with your assertion not to expect a patch just because Adobe coughed up a new version recently. They do still support FM10. What I do expect from them is a thorough investigation and can only hope they can find the culprit.

Anyway, as mentioned above, testing a trail of FM11 on my laptop under the current conditions is easier than waiting for IT to wipe the machine, set it up again, and for me to reinstall everything. It's a mystery. A mystery.

[Matt-Tech Comm Tools]

I can't speak on Adobe's behalf for anything, but in my many years, I don't recall getting an update on anything but the current version of the product...

I do hope that the FM11 trial works for you, but if not, I recommend trying it on a machine that's not previously had FM and Acrobat, as that seems the common theme here.

Keep us updated!

-Matt

[Tekscribe]

Installed trial FM11. It crashes too with the same mega-book. Still awaiting news from Adobe engineering.

[Moira_D]

Hello,

I wonder, did you ever manage to solve this? I have the same problem, I have tried all of the mentioned fixes and am stumped as to what to do next.

TIA

Moira

[Tekscribe]

No. There is no resolution yet. I met online with Adobe Engineering (India) last month and they decided to investigate further. I have forwarded more crash logs and files for various other circumstances where FM10 crashes. They have not provided any update.

My projects have many conditions and books have many files. IMO, FM seems to have trouble with x-refs where the x-ref source and the target are subject to conditions. As long as everything is set to Show All, there are no problems with book update. If I set books to only specific conditions and select All Cross-References in Update Book, FM crashes like a house of cards.

I am still not sure if it is an FM bug, or something to do with Win7, 64-bit. My local desktop support dude says O/S is not likely an issue. Adobe (India) says they tested with Acrobat X present; so, it is not Acrobat causing problems. Still not sure if security software Symantec Endpoint is the culprit; it is not displaying any popups warning of blocked program operations.

It is still an illusive mystery. I cannot get answers anywhere. Instead, my team has evolved some workarounds so we can still work and hope to deliver PDF/Help.

[Moira_D]

Thanks for the reply. I have checked all my x-refs to make sure thay don't change conditions mid-cross reference. I too am looking at workarounds.

Moira

[Tekscribe]

Do not know what you mean by mid-cross reference. All a user has to do is ensure the condition for the target of the x-ref agrees with the x-ref itself (i.e. the target condition is set to Show).

[Moira_D]

There is this: http://forums.adobe.com/message/4064837 and this: http://forums.adobe.com/thread/854040.

This sort of thing has caused Frame to crash for me but I have checked and fixed all my x-refs now

[Tekscribe]

Thanks for these references. I did not know FM is/was fickle with Default Para Font. I have seen the cloaked/uncloaked x-ref thing before. It is not an issue for me now, despite hundreds of x-refs in my publishing architecture.

It seems FM10 is fragile when it comes to x-refs and conditions. A wide variety of circumstances can cause it to quit. I suspect Adobe has a bug here and does not know how to fix it.

[Jeff_Coatsworth]

Possibly - but until someone can create a sample set of files that consistently blows up, they'll never get a handle on it.