Highlighter has no need for X_CORRECTION, Y_CORRECTION

[GoogleCodeExporter]

X_CORRECTION, Y_CORRECTION serve as "magic" offsets to make the
highlighting areas line up properly with the text that they are
highlighting.  In fact, they are unnecessary, and stem from the fact that
the bitmap is placed behind the TextField without making any effort to line
the two up properly.  Not only does this result in confusing code and
algorithms that even the implementor doesn't know quite why they work the
way they do, it also means that if the TextField is moved around in its
container, the highlighting will break.

The proper way to handle this is to align the origin of the Bitmap with the
origin of the TextField (within the coordinate space of the TextField's
parent) by setting bitmap.x = textField.x and bitmap.y = textField.y after
the Bitmap is added to the TextField's parent.  Better still would be to
use a ChangeWatcher to bind the Bitmap's x and y values to the
corresponding values of the TextField, so that the Bitmap will remain
aligned even if the TextField moves while the program is running.

Once this is done, StringBoundaries.X_CORRECTION and Y_CORRECTION can be
eliminated.  And, incidentally, the proper value for X_CORRECTION is 2, not 1.

Original issue reported on code.google.com by tbai...@gmail.com on 22 Jul 2008 at 1:46

[GoogleCodeExporter]

Further clarification: for everything to work properly, it is not sufficient to
assume that the vertical scroll offset it equal to the y value of the first 
character
shown (accounting for the blank lines appropriately, of course), because this
character is not located at the origin of the coordinate system.  The proper 
formula
is: (y value of  the first visible line) - (y value of the first line), 
accounting
for blanks in each case.

Original comment by tbai...@gmail.com on 22 Jul 2008 at 3:03

[GoogleCodeExporter]

Original comment by dmcc...@gmail.com on 8 Jan 2009 at 5:40

• Added labels: FlexLib-Highlighter