Неправильное выделение при использовании JXTable с MatchingTextHighlighter - PullRequest
Новая
       33

Неправильное выделение при использовании JXTable с MatchingTextHighlighter

1 голос
/ 01 сентября 2011

Основной вопрос:

При изменении ширины TableColumn метод SwingUtilities.layoutCompoundLabel(..) устанавливает для параметра Rectangle textR старое значение (или «значение до»).
Как я могу получить текущее (реальное) значение Rectangle?

Некоторая справочная информация и исправления:

Я использую MatchingTextHighlighter.java изSwingLabs-Demos (пример SearchDemo.java)

Это очень хорошее начало, чтобы пометить только найденные символы в ячейке JXTable.Но у меня некоторые проблемы с положением маркера, если я изменю выравнивание содержимого ячейки с LEFT на: 

table.getColumnExt( 1 ).setCellRenderer( new DefaultTableRenderer( null, SwingConstants.RIGHT ) );

или 

table.getColumnExt( 1 ).setCellRenderer( new DefaultTableRenderer( null, SwingConstants.CENTER ) );

При выделении символов возникают три ошибки:

three bugs in one picture

  1. Ситуация: текст JLabel полностью виден.
    Проблема: Чем шире столбец (изменяется с помощью заголовка столбца), тем больше подсветка будет смещаться вправо (в стороне от совпавших символов).

  2. Ситуация: текст JLabel частично виден (закрашен многоточием ...), но выделенная строка полностью видна.
    Проблема: Положение подсветки неверно от одного пикселя до одногосимвол при изменении ширины столбца.

  3. Ситуация: текст JLabel и выделенная строка частично видны (маркер должен быть на многоточии)
    Проблема: Подсветка на элу lipis неправильная ширина (от пикселя до правильной ширины) при изменении ширины столбца.
    Это единственная ошибка, которая также отображается в выровненном по левому краю столбце (маркер всегда имеет правильную ширину, но прыгает вправоиногда).

Первую ошибку можно исправить, закомментировав textR.x в 2 строки (начиная со строки 327 в MatchingTextHighlighter.java): 

if (start == 0) {
    // start highlight from the start of the field
    highlightx = /* textR.x + */ xOffset;
} else {
    // Calculate the width of the unhighlighted text to get the
    // start of the highlighted region.
    String strToStart = text.substring(0, start);
    highlightx = /* textR.x + */ fm.stringWidth(strToStart) + xOffset;
}

Возникают две меньшие проблемы:
Одна из них заключается в том, что маркер начинает на один пиксель больше слева, если соответствующая область начинается с первого символа Label.Вторым является переход по выделению на один пиксель в выравниваемом по центру столбце, если ширина столбца изменяется с помощью заголовка столбца.
Оба (плюс ошибка RightToLeft) могут быть исправлены этими изменениями (начиная сстрока 397 в MatchingTextHighlighter.java): 

    return textR.x;//respect the icon and start the highlight at the beginning of the text not at 0
} else if (horizAlignment == SwingConstants.RIGHT
        || (horizAlignment == SwingConstants.TRAILING && leftToRight)  //fix for rtol: ! deleted
        || (horizAlignment == SwingConstants.LEADING && !leftToRight))  //fix for rtol: ! added
{
    return viewR.width - textR.width;
} else if (horizAlignment == SwingConstants.CENTER) {
    return Math.round((viewR.width - textR.width) / 2f) - 1;  //round a float to prevent a one-pixel-jumping Highlighter

* Третья ошибка может быть частично исправлена ​​(изменение строки 48 в XMatchingTextHighlighter.java): 

int end = /* myTextR.x + */ fm.stringWidth(text) + offset;

Теперь подсветка всегда начинается с первого пикселя многоточия, fix !: -)
Но ширина меняется при изменении размера столбца, ошибка !: - (

После отладки второй и (оставшейся половины) третьей ошибки в MatchingTextHighlighter.java, я думаю, что вызов служебного метода 

String clippedText = SwingUtilities.layoutCompoundLabel(.....)

устанавливает для параметра textR старое значение. При изменении размера столбца вычисленная ширина текстового прямоугольника кажется «одним событием позади». И из-за этого положение маркеране так.

У кого-нибудь есть идея, чтобы исправить это?

Спасибо, что прочитали все это ...

...