Walter noted:

There are several problems here with FBtoC translation.

> 1. Multistyled edit fields are not supported
>
> 2. The SCROLL BUTTON ID and the EDIT FIELD ID have to be the same
> value in order to link them together. Since the FBtoC paradigm treats
> edit fields as buttons, this can't happen - if they are the same
> value, the SCROLL BUTTON replaces the  Edit Field (which then
> disappears). I can make the IDs different, but then the two are not
> linked.



Walter,

 From you vantage standing on the FB hill looking up at the FBtoC  
hill, you are right: FBtoC's handling of Edit Fields is not yet  
perfectly implemented.

However, what you can'f see from the FB hill, you can see from the  
higher FBtoC vantage: FBtoC allows perfect integration of the new--  
and vastly superior HIView controls that solve all the problems  
related to FB Edit Fields.

I encourage you to consider responses to Eugen Rosu's March 10 post  
"Roomy Edit Fields" in which he lamented the fact that FB Edit Fields  
are limited to 32K (about six typewritten pages) of text. A  
HITextView embedded in a HIScrollView suffers no such limitations as  
I demonstrated in the code I posted that modifies the FBtoC example  
found here to load an entire dictionary of words:

   FBtoC_1.0.5 -> Examples -> Text -> Scrolling text view (10.4)

Note that the code used to create the scrolling field is very short.  
The heavy lifting is automatically handled by the nib built in  
Interface Builder.

HITextViews offer the same formatting possibilities as Edit Fields  
with the additional capability of loading styled RTF files. When  
built with a nib in Interface Builder, HITextViews offer automatic  
scrolling as well as easy copy/paste capability.

The disadvantages to HITextViews are a learning curve-- they are best  
suited for working with Carbon Events, and the need for a work around  
to directly print them. But speaking from experience, the advantages  
greatly outweigh any disadvantages.

Ken