TRichView.com

I've found, that this one works awfully.
For example, if two different text items are stuck together, and we make selection of the second item from the beginning, then GetSelectionBounds returns absolutely strange results.
It'll return the first item number as an item, from which selection starts, and the non-existent offset in this item (text length of the first item will be less, than the result by one). In this case I've got a lot of troubles for checking, which items are currently selected - I've wrote a lot of non-typical methods, which are using this procedure - and I've got a lot of bugs in them.
And the other one trouble.
For example, we've got the following string in editor:
Bigttring
And for example we need to change the first symbol in "ttring". We're selecting the first T symbol, and press the S-key.
And what we've got? The following one
Bigstring
As you see, the editor won't take style from the second selected item, but from the first one
It's very uncomfortable to make changes in this way
I think, that this trouble in code related to improper work of GetSelectionBounds - it won't determine the right style and will take it from first one, not from current selection.

GetSelectionBounds returns results described in the help file.
In text item "abc" (Length=3), the following offsets are valid:
1: |abc
2: a|bc
3: ab|c
4: abc|

Yes, the same position between items ItemNo and ItemNo+1 can be returned in two forms:
(1) ItemNo, GetOffsAfterItem(ItemNo)
(2) ItemNo+1, GetOffsBeforeItem(ItemNo+1)
They are equivalent, if the (ItemNo+1)th item continues paragraph.
In the most cases, GetSelectionBounds returns (1).

As for taking current text style from the selection, it will be implemented in future.

Sergey Tkachenko wrote:In text item "abc" (Length=3), the following offsets are valid:
1: |abc
2: a|bc
3: ab|c
4: abc|

Well, the fourth situation can be useful, when we're gaining offset in non-selected text.
But it's very uncomfortable, when you need to check special style under selection (for example, hyperlink). I've written another procedure, which normalizes left bound of selection, because when the user gonna select the whole hyperlink - left edge, given by GetSelectionBounds, will be refered to another item and it's not so logically based.
The idea of selection methods is based on one thing - left edge of selection must be connected to inside item (right-oriented) and the right edge also should be inside item oriented (but in this case it should be left-oriented). Of course, I don't speak about arabian right2left style of writing
I didn't examine source codes deeply, but I think, that 'Bigttring' trouble related to this ideology of selection - it's only my guess, but it's could explain the whole situation, when making selection from first symbol of the item.
If the selection contains the first symbol of stuck item, the left bound could be improperly gained - it could be related to another item and to another style - and the current text style gonna change to "wrong" text style - from the first item, not from selected. And when we gonna enter new text, selection will change into text with first item style.