FrameMaker consistantly crashes, everytime, when doing a save file after doing a cut and paste of table data from one open FrameMaker file to another. This only happens with a specific table. I have had this happen consistantly over the past year with various docs and table data. Usually it occurs when trying to cut & paste data that has edit tacking turned on, but in this instance this is not the case. FrameMaker is fully up to date. Running WINXP
Internal Error 10024, 6379539, 6372417, 6385921, FrameMaker has detected a serious problem and must quit.
Have you tried a MIF wash?
FM7 does this a lot (Error 7013, as it happens), with right run-in anchored frame moves. Less so with table moves.
By the time the crash occurs, it is usually the case that the real problem, corruption elsewhere in the document, has already happened and beed saved. Saving out as MIF, and re-opening sometimes flags the damage.
Thanks for the info! It would probably take at least 3 months to go through corporate purchasing if it would go through at all.
Maybe eventually the fmerror@adobe.com guys will get tired of getting error attachments from me.
Hi turboeclipse,
We can try one more step here.
Goto c:/(drive) of your computer and Program file-->Common Files and you will find a Linguistics folder there,kindly rename that folder to Linguistics_old and then try and launch Framemaker.
If it does not gets launched,kindly name it back to the original name Linguistics.
If it launches,go ahead and perform the steps that were making it crash and take a look it that works.
Regards
Harpreet
> This only happens with a specific table.
If you can isolate the trigger factor, that would enable two things:
1. other FM users, some with Support, could confirm and re-report,
2. Adobe would be able to find the root cause quicker.
Is it a specific Table Catalog table, regardless of content, or
specific table content regardless of table format?
Possibly unrelated anecdote ... as I've mentioned, when we get Err7103
crashes, it's often well after the real damage has already happened.
We have seen cases where huge sections of a document appear to
vanish. In at least one instance, the content did not disappear.
It got moved into a table cell, and was largely invisible.
I can imagine that hidden table structures of sufficient complexity,
or sufficient degeneracy (e.g. unbalanced tags, garbage structs,
containing cross-refs to self*), could make the document unstable.
________
* When the size of the .fm file increases with every save (and no
changes), circular cross-refs are a likely cause.
OK I spent some time looking into this. The issue occurs with a specific table. The problem occurs even when all the data and ruling have been cleared. So the problem is
with the table itself. See below. Copying this table from one .fm doc to another and performing a save causes FM to crash. I am going to try and see if deleting specifc rows or columns affects it.
> The issue occurs with a specific table.
That specificity is not specific enough.
All instances of tables of the same specific (Table Catalog) format?
Or just a specific set or row/column data?
> The problem occurs even when all the data and ruling have been cleared.
You may only think it's empty. You could have rows and columns not visible, and things going on in the format (Table Title and footer defs, for example).
> Copying this table ...
Copying the anchor point, or just the row and column contents?
Create an empty table of FM default Format A.
Copy in your rows and columns.
Crash?
Nothing is hidden, no title, no foot defs, no anything as far as I can tell. Other tables using the same exact format or default table formats copy in no problem. I don't see a way to select it via anchor point. I don't know what else to do at this point. There must be some sort of circular reference somewhere. I checked the exisiting cross-references but none list this table.
North America
Europe, Middle East and Africa
Asia Pacific