Community
Participate
Working Groups
Build Identifier: org.eclipse.swt_3.6.0.v3650b Our product requires that StyledText displays overlapping ranges. While in general this works (provided the ranges are sorted properly), the smaller range which is displayed on top of large range highlights one extra character on the right. Reproducible: Always Steps to Reproduce: 1. Create StyledText 2. Select long piece of text and create a StyleRange for it. 3. Select smaller range inside the first range and create another StyleRange with different background
Created attachment 187306 [details] Sample code
I typed "012345", select the whole text and chick add, then select just "1" and click add. The "12" changed color. Printing out event.styles we get: StyleRange {0, 6, fontStyle=normal, foreground=Color {255, 255, 255}, background=Color {0, 0, 0}} StyleRange {1, 1, fontStyle=normal, foreground=Color {255, 255, 255}, background=Color {255, 0, 0}, underline=squiggle, underlineColor=Color {128, 128, 0}} That is wrong, the styles can not overlap. They have to be ordered, and style at N - 1 has to end before style N starts (otherwise they are not really ordered - in the case above you can't really say that the second happens after the first). The correct data in the event would be: StyleRange {0, 1, fontStyle=normal, foreground=Color {255, 255, 255}, background=Color {0, 0, 0}} StyleRange {1, 1, fontStyle=normal, foreground=Color {255, 255, 255}, background=Color {255, 0, 0}, underline=squiggle, underlineColor=Color {128, 128, 0}} StyleRange {2, 4, fontStyle=normal, foreground=Color {255, 255, 255}, background=Color {0, 0, 0}}
I still think that this behavior is not correct, provided that the documentation is ambiguous at best (the only place I found says "array of StyleRanges, need to be in order") What order? I am returning them ordered, and in fact they are all displayed. Only some of them are displayed incorrectly. StyledText does not choke on my ranges, therefore I assume that there is nothing wrong with them.
Ok, I understand it about the restriction. Just thought that given that nothing bad really happens apart from the length change, maybe the fix (or the enhancement) for that would be really simple. And then the restriction can be lifted.
I thoguht a bit more about this problem, and indeed StyledText should not handle overlapping styles. What happens when two or more overlapping styles set the same attributes ? For example, two styles overlap, one sets foreground to blue and the other to green. Which one should StyledText use ? Only the application have context information to make the right decision. Closing again.
I think the StyledText indeed should provide some rudimentary handling of overlapped style regions, the way it does today anyway, minus bug where one extra character is highlighted. And to answer your question, it should do it exactly the way it does today too, meaning that each subsequent region paints over previous ones. If an application finds that this basic support is not enough, it can implement its own, but at the very minimum application can manipulate the order of the regions (more "important" is displayed over the "less" important ones). In our particular case, two or more regions with same attributes (length+offset) are not possible.
