Env Windows 10 1909, FM 2019 15.0.5.838 (x64)
My client has a process, coded in c++, to add line numbers to a structured document. I know... why! The line number has to be outside of the text frame, so it could not be a element, and the inbuilt line numbering was not customisable. The line numbers are required for legislative review. Another customer uses a similar process for the same reason. another process removes the line numbers.
Recently after this process was run, sometimes the line numbers would not stick, that is not be there when the document was saved, and worse, other changes would also not stick.
To cut to the chase (this has taken me many hours), the symptom is that after the process to add or remove line numbers was performed, when clicking the X to close the document, FrameMaker displayed a Save File dialog, even although the document had been saved by the code. Saving manually via File->Save also made no difference.
After clicking Save FrameMaker showed the following dialog.
After clicking OK FrameMaker showed the first dialog.
Clicking Don't Save would allow the document to be closed. Sometimes the document when opened, woudl not have the line numbering on or off as expected. I also expect that the loss of other changes was related to subsequent processing, where the code has very little error checking, so would continue, if the FDK calls returned errors.
The other symptom is the presence of temporary or intermediate files as shown below. How many there were seemed to influence whether changes were lost.
Now the bizarre bit. My customer could re-produce this problem at will, usually at a critical time, while I never could. In investigating why this was, I worked out that the failure did not occur with certain workspaces, mine for example. In drilling down to work out why, I discovered it was the complete absence of the 'Element Validation' panel/pod, that is Structure->Validate has never been run with the workspace, so the //palette element attribute app-data="#lt;palette kit-data=#quot;3 32 #quot;/>" does not exist in the fws or cfws file for the workspace. Once the 'Element Validation' panel/pod has been shown, and the //palette exists, even if the 'Element Validation' panel/pod has been hidden, the problem does not occur! Bizarre.
I will update FM2019 in my own environment to see if the problem still occurs as well as testing with 2020. It looks like the error dialog regarding an internal error and the temporary or intermediate files have been reported by others. Maybe the absence of the 'Element Validation' panel/pod was a factor there too?
I am not sure how I can report this as a bug to Adobe!
Time to put my head down!
Jon
 
13
Replies
Hi Matt,
Many thanks for taking the time to reply.
Isn't it a moot point to suggest not using the line numbering process? The line numbering process is what is having the problem. I am sure you are not suggesting that the customer manually add thousands of line numbers, remove them, rinse and repeat?
In any case, the work around of having the Element Validation panel/pod in the workspace, hidden or shown, allows the process to work perfectly, and alleviates the horror of having to do it manually.
With changing the preferences are you referring to either Automatic Backup on Save or Auto Save?
With these checked FrameMaker creates a *.backup.fm or a *.auto.fm. These are not what this bug creates. These preferences are not used in my customers environment as any saves, CTRL+s for example, are automatically sent to the back end CMS system, and any processes that change documents also save automatically.
If I rename one of the temp/intermediate files, created by the bug, and open it in FrameMaker I see a copy of the original document at various stages of the line numbering process.
Jon
AdChoices