[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: FrameSGML@xxxxxxxxxxxxxxx, "Free Framers" <framers@xxxxxxxxx>, framers@xxxxxxxxxxxxxx (Framers List)
Subject: Re: [FrameSGML] Frame 7 Structured App Problem
From: DW Emory <danemory@xxxxxxxxxxxxxxxxxx>
Date: Sat, 04 Oct 2003 08:25:39 -0700
In-Reply-To: <4.2.0.58.20031001021414.009d3c50@pop3.globalcrossing.net>
References: <BB9F74C0.BB96%jroot@publisys.com><4.2.0.58.20030930163855.009d3e60@pop3.globalcrossing.net>
Sender: owner-framers@xxxxxxxxx
CAUSE OF THE PROBLEM WAS FOUND, AND ITS VERY UGLY. As you recall, the client, who was running Frame 7, was having all sots of anomalous behaviors when he installed the upgrade to my SGML catalog production application in a folder under StructureTools\sgml. The upgraded application performed without a hiccup on my platform running FM+SGML 6.0. One of the first things I asked the client was whether he had ever edited the maker.ini file. He'd never even heard of that file, and swore up and down that he hadn't edited it. I also verified that, when he had reinstalled Frame 7, and also installed the patches and upgrades, whether it had been installed in a different location. he firmly avowed that it had not been moved. Since I knew the location of the Frame 7 installation last year, and the earlier version of my application which he used last year ran without a hitch, it was not necessary to update the appdef file for the upgraded application, because all the new files had exactly the same filenames as the earlier version, and those new files were installed directly over the older versions of those files in the same folder that was used last year. Nevertheless, I had the client fax me the appdef from last year, and verified that it was exactly the same as the appdef on my platform (except that $STRUCTDIR was replaced by $SGMLDIR on my FM+SGML 6 platform). We were trying to solve the problem over the telephone. I'd tell him to do something, he'd do it, I'd have him verify that he'd done exactly what I'd told him to do, and then he'd run the application again. Each time we changed something, I'd tell him to re-read the appdef file, then check the Read/Write Rules file with the application selected. Each time, the rules checked OK, but then when he attempted to import the same test file I was using, some (but not all) of the elements in the resulting Frame file were red because they had incorrect capitalization of the element names. Not only that, but it was impossible to change the names of those red elements to their correct names. Finally, in desperation, I told him to take out $STRUCTDIR everywhere in the appdef file and replace it with the full pathname. That was it. Everything worked as it was supposed to. No more red elements. The only thing I can figure is that, when the client reinstalled Frame 7, and/or installed the patches and upgrades, the install process either wiped out or mis-defined $STRUCTDIR in the maker.ini file, or did something else which made $STRUCTDIR invalid. MORAL OF THE STORY: With Frame 7.0, don't trust that $STUCTDIR gives the correct path. Replace it in the appdef file with the full pathname. That way, if the client reinstalls Frame 7 or installs patches or upgrades, appdef will be unaffected. FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory <danemory@globalcrossing.net> ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **