Led 3.0 Class Library DocumentationLed 3.0 Class Library DocumentationA MarkerCover is a templated class which keeps track of a collection of markers which "cover" the text. Here the term "cover" is very similar to the mathematical term, meaning that the union of all the elements of the collection contains the set of valid marker positions, and yet none of the MarkerCover elements intersect (contain the same character position).
So - for example - a common use for a MarkerCover would be to keep track of all the style information
associated with a document in a standard implementation of styleruns (as in StandardStyledTextImager).
MarkerCover < MARKER,MARKERINFO,INCREMENTALMARKERINFO > [public]
MarkerOwnerMarkerCover is a template used to simplify implementation of a cover of markers. You define some marker type (MARKER), and be sure it has a GetInfo and SetInfo () methods (which take type MARKERINFO). The 'MARKER' class also must have a no-arg constructor, and one which takes a MARKERINFO. Be sure type MARKERINFO has an operator== method to compare if the info stored in two markers should be considered equal.
Then this template will keep track of a bunch of these markers for you. As you set the 'info' attribute on any range of marker positions, this code will automatically split, and merge adjacent markers, and assign them this MARKERINFO attribute.
This code is ideal for keeping track of something like style runs, where you have a (in this case font) attribute to be applied to all the text.
NB: Although this class is very similar to a Partition - it is different enuf that these to classes share
no common implementation. The reason for this is that there are different performance considerations operative, and
this is not an abstract class; but rather a utility template class to help implement covers.
The thing a Partition and a MarkerCover share is that they both
implement a partition - in the mathematical sense - of the legal/valid marker-positions associated with a TextStore.
| Member Details |
|---|
|
Override this to apply any special constraints on the boundaries of regions in the MarkerCover. For example, for a ParagraphDatabase, this makes sure the boundaries on lookups/changes fall on partition element boundaries. By default, this routine does nothing. |
|
Internal utility routine, used to check for (and safely delete) zero-width cover elements. |
|
Override the standard |
|
Returns the a vector of pairs: MARKERINFO and length (pair The list is returned sorted, and always contains at least one element. See also |
|
Returns the marker objects (of type 'MARKER') which contain the marker-info (of type 'MARKERINFO'). which are found in the range from charAfterPos and up to nTCharsFollowing. If nTCharsFollowing == 0, it is assumed to really be at least one. The marker list is returned sorted, and always contains at least one element. |
|
For the most part, we can call However, what happens if someone makes a change to the text, and after our 'AboutToUpdate' hook happens, but BEFORE our 'DidUpdate' hook - someone tries to query some info about the MarkerCover<>? See SPR#0599 for an example of this problem. Anyhow - we must protect our database so that it remains consistent, even if someone queries information after our 'AboutToUpdate' hook, but before our 'DidUpdate' hook. Thats what this routine, together with a few flags, does. There is one more twist: Just what area (in HandleCallBeforeDidUpdateComplete) to we check if its after our 'AboutToUpdate' hook and before our 'DidUpdate' hook? The answer is - it depends? If we are called from another AboutToUpdate () handler, then the text hasn't changed, so we have no work todo. If we are called from another 'DidUpdate' hook, then we MUST process the NoteCoverRangeDirtied (). But we cannot BLINDLY do this. We need to know if the actual text modification has taken place (so we know which buffer offsets to use). It is for this reason that we have the 'fEarlyDidUpdateCalled' variable. |
|
Internal utility routine, used to react to a region of text having had some of its MARKERINFO changed. This code
will walk the affected region, and make sure all contraints (like no zero-length markers) are observed. It calls the
virtual |
|
Apply the given INCREMENTALMARKERINFO to the range of 'nTCharsFollowing' chars starting at charAfterPos. This could have no effect (if nTCharsFollowing is zero, and the substypes ConstrainSetInfoArgs () doesn't modify the start/end, or if the INCREMENTALMARKERINFO specifies no change). At any rate - the method will assure the given INCREMENTALMARKERINFO is applied to the entire range from 'charAfterPos; to 'charAfterPos + nTCharsFollowing', and any splitting or coalescing of adjacent style runs will be handled automatically. See also |
|
Internal helper routine. You probably should not use/call this directly. Apply the given 'INCREMENTALMARKERINFO' to the 'from' to 'to' range of text. Keep track of some outer scope, passed in variables that help the overall update process. Only update 'allMarkersInRange' - calling aboutToUpdate - if the passed in argument is non-NULL. Only update 'changedAnything' - flag if its pointer is non-NULL. 'allMarkersInRange' can be null if-and-only-if 'changedAnything' is null (pointer). . |
|
DOC LATER. SHOULD TIS TAKE A VECTOR OF INCREMENTALMARKERINFO???? INSTEAD OF MARKERINFO |
|
|
Return to Led Page
Return to Led ClassLib Documentation Index
Return to Led Reference Manual Index