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.