RE the problem of nested windows when you OPEN ALL in a book...  The answer I 
got is, "Always expand docs to full screen -- use the tabbed interface."  

This is reasonable if you want your doc windows to always be fully expanded.  I 
use Maker documents as generated logs.  I personally don't want the the log 
file to take over the entire screen.  I guess what I have to do is display the 
log in an editable dialog box (logs need copy, at least), and not use 
FrameMaker.  Say goodbye to links into the user's documents.

I also use FrameMaker docs as a GUI for some plug-ins.  It's really a problem 
for me to convert those to dialog boxes...  I use tables, autonumbering, xrefs, 
hypertext, and other things that FrameMaker provides.  In fact, I see no reason 
that a GUI should *not* be built out of FrameMaker documents, effectively the 
same as HTML forms create a Web GUI.  But unless you want the GUI to be the 
entire screen, you can't get away with a Maker doc as a GUI.

RJ, I don't believe the API exposes much (or any?) control over the new windows 
-- for example, can I cause one window to be open at less-than fully expanded 
while others are fully expanded?  I beat my head against this wall during beta, 
and I logged the issue.  But I never heard anything about it.  As I recall, I 
logged other issues with the new windowing paradigm in the API... 

In my spare time (not!) I'm trying to devise workarounds, but you can see that 
they're prohibitive. What would be most excellent would be an API to create a 
pod or other GUI widget that wraps a FrameMaker document.  That's analogous to 
the old Pallette mode for a locked document.  Or analogous to popups in HTML.  
Imagine how rich the GUI could be if it could include FrameMaker documents!  
That's why I use FrameMaker as the GUI for TemplateMapper, for example...  It 
works very well.  I don't want to say goodbye to that capability.

Reply via email to