Article # 180, added by Geoworks, historical record
| first | previous | index | next | last |

GStrings in VMFile based text objects.



I just found a feature of gstrings in VM-based text objects:

If the storage of a text object is a VM file, then all gstrings added
as graphic characters _must_ also be stored in a VM file (not
necessarily the same VM file).  GStrings stored in chunks of an LMem
block are not copied into the text object's VM file.

The reason this does not cause problems every time is because the VM
text object can actually use a graphic stored in a chunk, but the VM
text data structures that keep track of the graphics aren't designed
to keep track of graphics stored in chunks - only graphics stored in
the VM file.  The first chunk-based graphic added will appear to be
added correctly, but any other graphics added will not.  A random (but
likely) outcome is that the text object will not add a second,
different graphic to the text, but use the first graphic again.  This
is the reason that the same image icon is being displayed for
different types of image icons.

I suggest the following course of action:

  - When copying the GStrings from the template block, create the
    duplicate gstring with GST_VMEM instead of GST_CHUNK,
    passing the file handle of the VM file used to store the
    text (the clipboard file, right?).  This will create the GString
    in the same VM file with the text object.

  - Change HLineChunk, ImageMapChunk, etc to be type VMBlockHandle
    instead of ChunkHandle, and store the block handle returned
    from GrCreateGString.

  - in appendImage, set VTG_vmChain to contain a VMChain (high
    word = VM block of gstring, low word = 0), and pass the
    VM file handle of the gstring to MSG_VIS_TEXT_REPLACE_WITH_GRAPHIC:

	graphic.VTG_vmChain = VMCHAIN_MAKE_FROM_VM_BLOCK(myGString);

        @call GlobalTextOptr::MSG_VIS_TEXT_REPLACE_WITH_GRAPHIC
            (graphic, ClipboardGetClipboardFile(), 0,
		textRange.VTR_end,textRange.VTR_start);

  - It is _very_ important that at some point, the copied gstrings
    in the VM file are explicitly freed (with VMFreeVMChain).
    This could happen at the same time that MSG_VIS_TEXT_DELETE_ALL
    is called, or just once whenever the application exits.  This
    is even more important than in the LMem case, because
    the Clipboard VM file is persistent storage, and storage
    leaks will cause the file to grow without bound, using up
    more and more of the file system.

  - Again, there's no need to maintain a reference counter for the
    number of times each graphic is used, as the text object
    copies the graphic to it's own internal storage and
    automatically deletes the internal copy when it is no longer
    needed.

The above changes are not difficult to make, and won't affect
your design of the browser.

With VM-based graphics, there is an optimization that could be
made:

  - Instead of copying the gstrings out of the template resource
    into the clipboard file temporarily, the graphic gstrings could
    be permanently stored in a ROM-based VM file, and directly
    appended from that file.  This would avoid the need to copy
    them into the clipboard file, and also the need to free the
    gstring storage afterward.  However, I don't believe these
    steps add much overhead to the entire process of rendering a
    document, so perhaps it is not worth pursuing.