Тормозит вывод в StringTable 15000 строк. Ну секунд 5 идет в отдельном потоке. Может это норма? Просто вывод этих же данных в StrList идет мгновенно. Данные выводятся из SQLite одним запросом.

Neo, вопрос можно ?
1. Нахрена тебе в StringTable 15000 строк ?
2. Зачем на них смотреть ?
------------ Дoбавленo в 01.49:
Даже если ты обладаешь феноменальными навыками быстрого чтения, то на просмотр одной страницы уйдет 2-3 секунды.
Страница на экране - это 40 строк. 15000:40=375 страниц х 3 секунды = 1125 секунд или ~19 минут
Если таких способностей нет, то умножь результат на 10 и получишь ~ > 3 часов.
Кому это надо ?
Пожалей свои глаза (и чужие тоже)
Выводить в StringTable нужно столько - сколько помещается на экране.
Для этого существуют волшебные слова LIMIT и OFFSET.
И тоже будет мгновенно.

Tad, ну удобно смотреть на все сразу. Прокрутил себе куда нужно... Но в общем, если выхода нет, то буду делать более конкретную выборку

MST_Virtual

Там есть пара интересных примеров. Кстати, скролл тоже поддерживает.

Да не удобно смотреть на всё сразу. И крутить "куда нужно" тоже не надо.
Не переживай. Ты не один с таким подходом к работе с БД.
Нужно запросом получить сразу "что нужно".
При грамотном запросе - обычно это одна строка.
И StringTable не так уж и часто нужна на экране.
За примером далеко ходить не надо: HiAsm.
Панель "Элементы".
Представь, что сразу открыты все 700.
"Удобно смотреть на все сразу" ??? Или твоё "Прокрутил себе куда нужно" ?
Вряд ли.
Намного удобней:
Нужны Строки ? - На тебе строки.
Нужна Логика ? - На логику.

Tad, [flood]Нужна баба? - На тебе бабу! [/flood]

Примеры отличные. Конечно и идея с разбиванием по вкладкам хорошая, но онлайн подгрузка пока будет удобнее.

Neo, я делаю так и на любом размере БД работает на раз.
code_32397.txt
------------ Дoбавленo в 17.56:
Никак руки не доходят превратить IC в компонент.

Вот я вот тоже подумываю забубенить компонент условия попадания в список диапазонов

Такое ? Правда только на один диапазон.
[flood]Посмотрел первый.
Пара вопросов:
Для того, что бы получить имена колонок - делаешь запрос Select * From ... т.е. перебираешь все (как писал Neo) 15 000 строк.
При этом 15 000 раз ищешь max(id) и 15 000 раз отнимаешь от этого max(id) единичку.
А если миллион записей ?
1. Почему не применить SELECT * FROM .... LIMIT 1; ?
За один раз получишь все удовольствия. Даже на elements 10-кратный выигрыш. Повторюсь - А если миллион записей ?
2. Привязка к max(id) не лучший вариант. А если Neo удалил с 5 по 14999 строку, т.е. в таблице осталось всего 5 строк, а max(id)=15000.
Про что расскажет max(id) ? Получишь сотню пустых страниц. Листай - не хочу.
А если id нет ?
Привязываться нужно к count(). ИМХО.
[/flood]

Tad, есть пример, есть твои уточнения (предыдущие твои уточнения я уже внес в эти примеры), нарисуй на основе этих примеров свои, с включением твоих правок и твоих рекомендаций.
------------ Дoбавленo в 23.48:

Я бы лучше имел три события -- меньше, равно, больше

nesco,
1. как я могу что-то нарисовать, если я не могу понять: Почему, для отображения несчастных( ) 15-и строк, нужно 399 раз обращаться к верхней точке ?

2. компонент делался для себя. Называется Between (в переводе "между") какое нафик "меньше, равно, больше" ?
Скорее "ниже, в диапазоне, выше"

Столько просит система на перерисовку экрана

Воевать с системой не будем.
Хотя у нас всегда виноватый если не Билл, то Кладов.
Твой компонент запрашивает 399 раз. Пусть он и расчитывается с системой.
Ладно.
Тогда наверное как-то так (изменённое отмечено жёлтым)
code_32403.txt
Нет. И так нельзя. Будет листать не до конца.

Представь, что где-то в середине таблицы удалено 150 записей подряд. И будешь ты листать 10 пустых страниц.

Для этого есть вторая схема, которая с буфером, она исключает пустые записи