Copy link to clipboard
Copied
Hello, could someone help me with next problem?
Fm12 problem.
Script goes through book, opens file, saves it and then closes it. This operation is executed for all files in a book.
Problem occurs after 110 - 120 file is processed. Either FM crashes completely or finishes, but book is closed and not all files are processed.
I could attach the book and script to simulate the situation (in the case folder c:\temp, has to exist, log will be saved there)
Thank's a lot for any help.
Copy link to clipboard
Copied
When you open a file, FM by default checks cross-references to other files, which causes other files to be opened and closed in the background. As you have many files in the book, this might eventually hit some memory boundary due to possible memory leaks in the FM12 code (I know there are memory leaks but nobody really knows in which areas).
If you have not already done so, try the following approaches:
1) Make sure to tell FM not to update cross-references when opening files. This might not be an option if you need to have the cross-refs updated - in which case you need to go with scenario 3 below.
2) Open all files invisibly. This is much faster and causes some of the code not to be executed (which may bring down the memory requirements).
3) Open all files invisibly first (making sure FM does not check cross-references), then run the update book command to fix the cross-refs if that is required), then save all files, then close all files.
Let me know if any of these scenarios solves your problem, and which one did the trick.
Good luck
Jang
Copy link to clipboard
Copied
We have book where no cross references are used. And we found out that opening documents invisible helps to solve the problem. For some function we can use this approach. But we have function like find where we need to open documents visible and for this there is NO SOLUTION. And also when the user opens documents for editing and that for example tries to use Find, reaching the limit of 100 file, the FrameMaker will crash.
Copy link to clipboard
Copied
it should not be required to have more than a handful FM files open at any time. I cannot imagine a user that can mentally handle over 100 open FM files at the same time. Even when the user wants to run a Find command on all the files in an FM book, this can be handled without first opening all files. The user is only interested in the files that have the text snippet in them, anyway.
When you open the book only and then run the Find command on the book, FM will open and close the files as required. I have used this feature many times on large projects.
If you do need a scripted Find method, you can open files invisibly and make them visible when the Find function gives a hit in that document. But I seriously doubt that you need any scripting at all in your user scenario.
Copy link to clipboard
Copied
Do you go through the files "one by one" (open the file, process it, close the file, open next file ...) or do you open all files at once?
Have you checked the Windows Taskmanager? As FM 2017 is a 32-bit application, there is a memory limit of 2 GB. Once this is reached, you might run into this problem.
Copy link to clipboard
Copied
Yes, we do it that way. This is the script to simulate the problem.
/********************************************************************/
/*
* Program Name:
* HierarchicalBooks.jsx- Traversal through Hierarchical Books in FrameMaker
*
* General Description:
* Traverses through the books Folder and Group hierarchy and logs the details in a text file
*
*********************************************************************/
book=app.ActiveBook;
comp=book.FirstComponentInBook;
while(comp.ObjectValid())
{
doc=open(comp.Name);
nextComp=comp.NextBookComponentInDFSOrder;
prevComp=comp.PrevBookComponentInDFSOrder;
compType=comp.BookComponentFileType;
Log("BookComponent.log", "CompName-"+comp.Name);
Log("BookComponent.log", "comp File Type-"+compType);
Log("BookComponent.log", "Component Type(Fldr,Grp,file)-"+comp.ComponentType);
Log("BookComponent.log", "PreviousCompName-"+prevComp.Name);
Log("BookComponent.log", "nextCompName-"+nextComp.Name);
Log("BookComponent.log", "---------------------------------");
//process component here//
comp=nextComp;
}
Log("BookComponent.log", "Loop out");
if (comp.ObjectValid())
{
Log("BookComponent.log", "OK");
}
else
{
Log("BookComponent.log", "FALSE");
}
function open(filename)
{
openProp = GetOpenDefaultParams()
i=GetPropIndex(openProp,Constants.FS_FileIsOldVersion)
openProp.propVal.ival=Constants.FV_DoOK
i=GetPropIndex(openProp,Constants.FS_FontNotFoundInCatalog)
openProp.propVal.ival=Constants.FV_DoOK
i=GetPropIndex(openProp,Constants.FS_FontNotFoundInDoc)
openProp.propVal.ival=Constants.FV_DoOK
i=GetPropIndex(openProp,Constants.FS_FileIsInUse)
openProp.propVal.ival=Constants.FV_DoCancel
i=GetPropIndex(openProp,Constants.FS_AlertUserAboutFailure)
openProp.propVal.ival=Constants.FV_DoCancel
retParm = new PropVals()
docOpen=Open(filename,openProp,retParm);
docOpen.SimpleSave(filename, false);
docOpen.Close();
return docOpen;
}
function Log(logFile,textLine)
{
file=new File ("C:\\TEMP\\"+logFile);
file.open("a+", "TEXT", "????");
file.write(textLine+"\r");
file.close();
}
Copy link to clipboard
Copied
You are creating massive amounts of text file open and close events. Try building the log file in memory without writing it out for every single line to find out if that might be causing the problem. The first step might be accumulating the logs for the book component into a single Log operation. That brings down the number of text fiile open, append and close events by a factor 6.
Also, you could define the GetOpemDefaultParams once in the main body and pass it as parameter to the open( filename ) function. Not sure how FM scripts handle the memory allocated for these massive structures. This particular one can be reused. You do need to create the new PropVals as return value for each call, AFAIK.
Good luck
Copy link to clipboard
Copied
Sorry for delayed answer. We were trying the things from comments above but with no effect.
We need to process about 600 files by the script. It is special that FM10 didn't have this problem using the same script. There must be better memory clearance, which was somehow corrupted in higher versions.
Memory increases and is not released. In FM10 the memory kept the same level. But on FM11, 12, 14 memory cleaning fails.
During script execution memory increases and from some point the windows are not closing but stay opened, although in script we tried two closes (to be sure the file is closed)
After exception occurs the memory jump down.
Do you know if there exist some official bug for this problem?