Hi Ken,

Once I realized that container information was IN the Manual, but not well
referenced, and in some cases not easily searched for, I found, starting on page
577, a couple of pages discussing Containers in detail.  This SHOULD BE
referenced in the Index more prominently - and cross referenced in several cases,
since it is many instances of the word "container" before you get to Appendix C's
excellent description.  Until you already know what it is, it's not easily
found.  I'm surprised the Index Letter V, doesn't have a Variable section in
which all of these kinds of things are discussed - or at least a cross reference
to Appendices B and C.

Thanks loads for all the extra references.  I think I can get a "handle" on the
subject now. (since a container IS a "handle" or so it says!)  <grin>

Joe Wilkins

PS  --  I have to admit that I prefer all lowercase letters to all UPPERCASE
letters, but maybe someone needs to write a routine for BB that will
appropriately capitalize some letters, even if bowerbirds shift keys ARE broken,
which they really MUST be; don't you think?

Ken Shmidheiser wrote:

> Joe Lewis Wilkins wondered:
>
> >Along the way, somewhere, I missed this "container" thing - except
> >to know that it exists.  The Release 3 Reference Manual doesn't tell
> >exactly how one is created (that I have found), though several
> >references to container$$ are made with regard to other items (EDIT$
> >statement and the like).
>
> Joe,
>
> This is from the FB^3 Release # Reference manual under EDIT$ function, p. 178:
>
> Item               Size
> Pascal String      255 bytes + length byte
> Edit Field         32,767 bytes
> Container          2 gigabytes
>
> A more comprehensive explanation of containers appears beginning in
> Appendix C on p. 595, IV Containers, which in part explains:
>
> "Containers are compiler managed handles that hold up to 2 gigabytes of
> ASCII or numeric information. Containers may be identified by a double
> dollar sign (DIM myContainer$$) or in a DIM AS statement (DIM AS
> CONTAINER myContainer).
>
> "Containers are always global."
>
> --- snip ---
>
> Containers are stored in the application heap as relocatable blocks.
> You can extract the handle to these blocks as follows:
>
> hndl& = [@myContainer$$]
>
> --- End info from manual ----
>
> In most respects containers are handled a lot like strings and EDIT
> FIELDS, but they hold a bunch more data. Here is how you read data
> into them:
>
> container$$ = EDIT$(efID) : REM fill container with TEXT from and EDIT FIELD
> container$$ = %resID% : REM fill container with TEXT res ID resID%
> container$$ = &hndl&  : REM fill container with contents of hndl&
>
> and here is how you extract it:
>
> EDIT$(efID) = #container$$
>
> You empty a container just like an EDIT FIELD:
>
> container$$ = ""
>
> The manual warns that they are slower with math because they convert
> data to strings before storage. But working with text the little I
> have, data transfer appears to be almost instantaneous.
>
> In addition, -bowerbird asked:
>
> >going out of town, so can't read all the messages,
> >but wanted to say that the long-string containers
> >sound great, 'cept they need to hold styled text.
> >
> >can do?
>
> The Reference Manual is a little vague in this area, at least for me.
> On Page 178 it says:
>
> "Where a container is the specified target, there is more than enough
> room to hold the contents of a field. Use the GET FIELD statement if
> you need to retrieve style information along with the text of a
> styled edit field."
>
> I am not sure in the context if the GET FIELD statement works only
> with EDIT FIELDS, or also containers as a way to hold style info.
> Perhaps Staz can shed some light on it.
>
> I am very pleased to report that FB^3 has a new function custom
> written just for -bowerbird:
>
> container$$ = UCASE$$(container$$)
>
> This will upper case every character of text in that container! Think
> of it, -bird, tttttttwwwwwwwoooooooo gigs of UCASE$$... just for you!
> (And no, I am not kidding. Certainly there's a poem in there
> somewhere.)
>
> HTH
>
> Ken
>
> p.s. See also pps. 178, 180, 434, 498 and others.