ee163ahe@sdcc13.UUCP (VICTOR ROMANO) (03/05/85)
There is an interesting bug in TESetSelect. If it is called before TEClick is ever called, the selection region is set to the proper value, but the caret appears at the end of the previous line if it was intended to appear at the beginning of a line. Of course this causes strange things to happen when something is inserted (an in TEKey). There is an interesting kludge which I added to solve this problem: (using MegaMax C) if ((*hte)->clickstuff == 0) (*hte)->clickstuff = -1; tesetselect (start, end, hte); I discovered this is because clickstuff always has a value of -1, -255, -256, 255, and 256, but 0 before any text operations have been performed. I arbitrarily chose to assign the value of -1, since this is the most common. Question: can this have any harmful side effects? Also, what does this field mean, anyway? Victor Romano
lsr@apple.UUCP (Larry Rosenstein) (03/09/85)
In article <sdcc13.168> ee163ahe@sdcc13.UUCP (VICTOR ROMANO) writes: > > > > There is an interesting bug in TESetSelect. If it is called before > TEClick is ever called, the selection region is set to the proper > value, but the caret appears at the end of the previous line if > it was intended to appear at the beginning of a line. TextEdit represents its selections by the character positions; if the start and end character positions are the same then you have an insertion point. If the character after the insertion point is at the start of the line, it is ambiguous whether the caret should be displayed at the start of the line or the END of the PREVIOUS line. (Either is plausible in certain situations.) That is where the clikStuff comes in. The INTEGER is really used as 2 booleans; the first could be called TELeftClick and the second TELeftCaret. TEClick uses a utility routine to determine what character the mouse was clicked on. That utility returns a character position, but the mouse could have been to the left or right of the center of the character, and it makes a difference as to where the insertion point goes. So the utility sets TELeftClick to indicate if the click was on the left side of the character. TEClick copies TELeftClick into TELeftCaret. When it comes time to draw the caret we have the ambiguity mentioned above if the insertion point is before a character at the start of a line. The value of TELeftCaret resolves the ambiguity. I wouldn't call this a bug, only a lack of documentation. The same problem can arise even after TEClick was called once, if the last click was on the right side of a character. Also, the fix that was given before forces the caret to be at the start of the line, rather than the end of the previous line, which might not be what you want. The moral of the story is that before you use TESetSelect to set an insertion point, and you suspect that the insertion point will be at the start of a line/end of a line, then you should set the clikStuff field to -1 if you want the caret at the start of the line and 0 if you want it at the end of the previous line. (Unlike what was implied in the original message, there should be no problem with other TE routines if you choose one or the other.) -- Larry Rosenstein UUCP: {nsc, dual, voder, ios}!apple!lsr CSNET: lsr@Apple.CSNET