This was mostly what Jeremy likes to call "pilot error." I'd put the dll's in the Mif2Go folder, but I should have put some in the Frame fminit\plugins folder, and some in the windows\system32 folder.
Once I had that right, we uncovered an obscure and minor bug, which OmniSys fixed promptly. Mif2Go is now doing what I need. Jim Owens wrote: > Thanks as always for the prompt response. > > I've tried your suggestions, but without success. To spare others, we > can continue off-list until this is resolved. > > > Jeremy H. Griffith wrote: >> On Wed, 05 Nov 2008 15:21:53 -0500, Jim Owens <[EMAIL PROTECTED]> wrote: >> >>> I'd like to use these, but I'm having trouble. >>> >>> The latest beta revision history file for Mif2Go explains that the >>> $_prev and $_next macros have been updated to support browsing backwards >>> in true sequence, even across chapter breaks. (Formerly, according to >>> the documentation, the "Prev" button would leap from the first topic of >>> a chapter to the first topic of the previous chapter.) The history file >>> also says that the [FileSequence] section has been deprecated. >>> >>> I've downloaded and installed the latest dwhtm, m2gframe, and m2rbook >>> dll's. >> First, please recheck that you have the *very* latest betas. We >> update them quite often, and this is a feature we just completely >> recoded with many improvements. It does work for the User's Guide. >> >>> I've set StartingSplit=Yes as suggested in the history file. For >>> personal preference, I've set UseNavButtons=Yes. Because the >>> [FileSequence] section is deprecated, I haven't added it to my ini file. >> That's all good. >> >>> I've referenced a macro for [Inserts} Top=, and in the macro I've >>> invoked <$_prev><$_next>. >> Correct. >> >>> The buttons appear in the output as expected, and within a given chapter >>> they work. However, they do not go from chapter to chapter. At the end >>> of a chapter, the Next button does nothing. At the beginning of a >>> chapter, the Prev button does nothing. In addition, for the first topic >>> in a chapter, the text in the Prev button reads "Test File from Mif2Go". >> So the inter-chapter links are not working. See if you have >> a .lst file in your working directory; if not, you may not have >> the latest m2rbook and m2gframe DLLs installed. You should also >> have a file m2g_log.txt, which may contain entries descriptive >> of the problem, another new feature. If so, we'd like to know >> what the log says. >> >>> There is a special consideration regarding my Framemaker source: each >>> chapter begins with a single paragraph tagged either "Chapter" or >>> "Appendix", followed by an "h1" paragraph. I am using the h1 paragraph >>> as a split point. >> That should work. >> >>> The Chapter and Appendix paragraphs are not used as split points. They >>> provide for some fancy formatting on the chapter title page and in the >>> TOC. Each one contains a ChapterNumber variable, some autonumber text >>> (set to white), and a Frame Above. I have assigned "=Delete" to them in >>> [HTMLStyles], but I suspect that they are causing an HTML file to be >>> created anyway. Regardless of how I set StartingSplit (Yes or No), the >>> output includes an HTML file named for the chapter, and this file >>> contains three <a name=> elements, as well as the standard header and >>> footer that we use on all pages. >> Yes. The history file really isn't the full doc; that will be >> in the next User's Guide, in final production right now for 52. >> But this file is indeed created, and necessary. When you use >> [Automation], though, it is not retained in the Wrap directory, >> so it does not become part of your deliverable. >> >>> This file is the one linked from the "Test File from Mif2Go" button. >> That is *not* right. However, we see the problem. Even though >> you have marked the para for Delete, it is still there, and >> Mif2Go knows it. You see, StartingSplit simply allows a >> split before the starting para, provided that para is indeed >> set to Split in [HTMLStyles]. It sounds like yours isn't. >> So as far as Mif2Go is concerned, the first file is still part >> of the deliverable. Does the Prev button on the first file >> actually link back to the previous file? If so, the links >> *are* working; likewise, the Next button at the end should >> link to the first (removed) part of the next file. >> >> In that case, what you need to do is fairly simple. Just use >> Frame conditional text to remove the first unwanted part of >> each file for this output. Mif2Go can handle hiding this >> condition for you, another newly-added feature. That's the >> easiest way to get what you want. >> >> This isn't a bug; Delete has a more limited purpose, by >> design. It only removes the paragraph content, and any >> Frames Above/Below, from the output. But the para content >> is still usable in macros; in fact, we use such paras that >> way for special purposes in producing the User's Guide. >> Delete does *not* remove any anchored frames or tables >> that are anchored in the Deleted para, so it is also used >> to remove anchor paras that are not wanted in HTML output. >> Conditional text would, in that case, remove the figures >> and tables too, not what you want. >> >>> If I comment out Chapter=Delete, I get the same file, but containing >>> the Frame Above referenced by the Chapter tag. >> Right, but in that it's not used anyway, conditioning it >> out would be better. >> >>> I even tried deleting the Chapter tag in one chapter. With >>> StartingSplit=Yes, I still get a "Test File from Mif2Go" Prev button on >>> the first page of the chapter, and the button opens an empty page >>> (except for the headers and footers). With StartingSplit=No, I get a >>> blank Prev button at the beginning of the chapter, and this button does >>> nothing; and the Next button for the last topic of the preceding chapter >>> still does nothing. >> You still have *some* content before the first h1, though. >> That's the problem. >> >>> I hope I haven't provided too much detail. I would like the Prev and >>> Next buttons to work end-to-end. >> That should happen as soon as the first h1 really starts >> the file (because the content before it is conditioned out). >> >>> Once they're working, I'd also like to >>> use graphics for the links instead of text (as in <a >>> href="next_topic.htm"><img src="Next.gif"/></a>). >> You mean, instead of buttons, right? You can do that by editing >> the [NavigationMacros] themselves, replacing the <$$_*title> in >> each with your <img> tag. Note that the user will no longer >> know where the link will take her, though; we advise against this. >> >>> P.S. I considered writing my own macros, but I came up against this >>> problem: when writing the last topic in Chapter 1, I haven't processed >>> Chapter 2 yet, so I can't define the link to Chapter 2's h1 topic. I >>> seem to need two passes, one to define all the topic file names, and >>> another to add links to any topic file names that occur later in the >>> document. Is there a way I can do this? >> It's not really necessary. We had a similar system before the >> rewrite of the <$_prev>/<$_next> code, and it was hard to maintain. >> That's one of the main reasons we made this enhancement. >> >> If you continue to have any problem with this, please send us a >> trimmed-down test case, like a book with two or three one-page >> files, so we can help you further. Include the .book, .fm, .mif, >> both .inis, .prj, and *all* output files (including the log), >> all in one .zip. We'll look into it promptly. >> >> HTH! >> >> -- Jeremy H. Griffith, at Omni Systems Inc. >> <[EMAIL PROTECTED]> http://www.omsys.com/ >> >> > > _______________________________________________ > > > You are currently subscribed to Framers as [EMAIL PROTECTED] > > Send list messages to [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > or visit http://lists.frameusers.com/mailman/options/framers/jowens%40magma.ca > > Send administrative questions to [EMAIL PROTECTED] Visit > http://www.frameusers.com/ for more resources and info. > > _______________________________________________ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.