Mif2Go Prev and Next navigation macros

Fri Nov 7 06:51:30 PST 2008

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 <jowens at magma.ca> 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.
>>   <jeremy at omsys.com>  http://www.omsys.com/
>>
>>
> 
> _______________________________________________
> 
> 
> You are currently subscribed to Framers as jowens at magma.ca.
> 
> Send list messages to framers at lists.frameusers.com.
> 
> To unsubscribe send a blank email to 
> framers-unsubscribe at lists.frameusers.com
> or visit http://lists.frameusers.com/mailman/options/framers/jowens%40magma.ca
> 
> Send administrative questions to listadmin at frameusers.com. Visit
> http://www.frameusers.com/ for more resources and info.
> 
> 