I think I may have found a bug with textboxes. What surprises me, and makes me question my finding, is that it seems like it should be documented somewhere, as it is not that obscure.

It has to do with selstart in textboxes (see my earlier post). It varies, and it's pretty easy to replicate.

If you enter text in a text box, with multiple lines, and then go to the second line or further down, and double click on a word, you will find that the position of selstart does not equal the starting position of the selected text. Sort of. It does, but only if you don't take into account invisible characters, such as CRLF. In my opinion, that alone is a bug. If in this case, you change the value of seltext, it doesn't work - it changes seltext plus some offset.

This is sort of documented - I do recall seeing somewhere that selstart includes these invisible characaters. That's no excuse for the seltext being "wrong" though. And another reason why I think this is a bug is because if you set the value of the text box, and then double-click on a word, selstart works correctly, and corresponds to the starting point of seltext.

In order to see the "bug", you need to add to the value of the text boxes, and add multiple lines. Then double click on the second line or greater. If you then use debugout on the dblclick method of the text box and have it display seltext, selstart, sellength, and subst(this.value,selstart+1,sellength), you will see that subst does not match seltext. It will correspond if you don't add any text to the initial value of the text box.

Hope this isn't too confusing.