Гибрид FormTableControl и FormDataSource

[Андре]

Цитата:

Изначально опубликованно Maxim Gorbunov

Почему бы не написать класс, который бы цеплялся к FormDataSource и FormTableControl (ну, соответственно во всех обработчиках событий вызывать методы класса), а в нем уже управлять заполнением таблицы? При высоких (здесь не спорю) трудозатратах на программирование получаем очевидное преимущество в виде достаточно гибкого (по крайней мере по сравнению с Grid) в настройке контрола для отображения данных. Сразу говорю, что сам такое делать не буду, ибо времени нет Идею отдаю бесплатно (да и не нова она).

ОК. Для начала давай определимся с тем, что мы хотим получить. Как я понимаю, мы хотим получить разновидность FormTableControl, которая обладая всеми свойствами FormTableControl может еще:

1. Отображать содержимое FormDataSource
2. Отображать ResultSet

Нас интересует первый пункт или второй ? Или оба сразу ? Тогда это наверное должны быть две разных задачи.

Рассмотим оба варианта:

1. FormTableControl, отображающий содержимое FormDataSource. Какие мы преимущества получаем по сравнению с использованием стандартного грида ? Возможность очень гибкого обращения с каждой ячейкой. Вот пожалуй и все. Или я что-то не улавливаю ? Хотя, как я понял речь, речь шла именно об этом варианте.

2. FormTableControl, умеющий ResultSet, как результат выполнения Statement. В этом случае мы получаем возможность сделать то, что вообще не реализованно в Аксапте, а именно сделать ЛЮБОЙ запрос на SQL Server (с какими угодно наворотами, не поддерживаемыми Аксаптой) и полученный результат отобразить виде таблицы.

Итак, сначала давай решим, какую из этих задач мы решаем.


Вопрос второй - концептуальный - как все это реализовать. Если бы я программировал на обычном языке программирования, я бы сделал следующее: создал наследника от FormTableControl, добавил бы ему свойство типа FormDataSource и переписал бы методы отвечающие за его отображение и редактирование. Но Аксапта не обычный язык рограммирования, поэтому этот способ здеь не пойдет. Если наследника FormTableControl я создать еще могу:

class dem_Table extends FormTableControl
{
}

то поместить его как компонент на форму практически не возможно. Или кто-то знает такой способ ?

Значит надо делать как-то по другому. Например, это должен быть отдельный класс, имеющий свойства типа FormTableControl и FormDataSource. Во всех обработчиках событий FormTableControl будут вызываться методы этого класса, которые, в свою очередь будут обращаться к FormDataSource. Не совсем изящная конструкция, но более удачного решения я пока не вижу. Может есть еще варианты ?

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Андре
ОК. Для начала давай определимся с тем, что мы хотим получить.
...
Нас интересует первый пункт или второй ? Или оба сразу ? Тогда это наверное должны быть две разных задачи.

Согласен, это две разные задачи. Причем вторая - гораздо более трудоемкая, чем первая. Поэтому предлагаю, решая первую, выявить все подводные камни и затем, в случае успешного решения, думать о реализации второй.

Цитата:

Изначально опубликовано Андре
Какие мы преимущества получаем по сравнению с использованием стандартного грида ? Возможность очень гибкого обращения с каждой ячейкой. Вот пожалуй и все.

Нет, не все. Получая контроль над представлением, мы получим возможность задуматься о решении следующих задач, в разное время встававших и нерешенных:

• Фильтрация по display-методам.
• Адекватное поведение бегунка (scroll bar)
• Реализация того, что в Navision называется фильтр безопасности, а в Axapta 3.0 - контроль доступа на уровне записи
• Копирование в clipboard только видимых столбцов

Цитата:

Изначально опубликовано Андре
Вопрос второй - концептуальный - как все это реализовать.
...
Например, это должен быть отдельный класс, имеющий свойства типа FormTableControl и FormDataSource.
...
Не совсем изящная конструкция, но более удачного решения я пока не вижу. Может есть еще варианты ?

Других вариантов тоже не вижу. Думаю, что не видят их и разработчики Navision. Посмотри хотя бы, как они реализуют wizard'ы. Те же классы, цепляющиеся к обычным формам и толкающие туда, все что нужно. Явное отсутствие изящности и тяжеловесность конструкции компенсируются наличием мастера, автоматизирующего создание нового мастера.

[Андре]

Цитата:

Причем вторая - гораздо более трудоемкая, чем первая.

Мне показалось как раз наоборот. Наверное я просто не вижу всех сложностей второго варианта.

Цитата:

Поэтому предлагаю, решая первую, выявить все подводные камни и затем, в случае успешного решения, думать о реализации второй.

ОК.


Тогда решим, что у нас в результате должно получится. За аналог возьмем Аксаптовский грид и попробуем описать, чем он будет от него отличаться а в чем совподать. То есть:

1.
Загрузка данных в таблицу. Честно говоря, мне не совсем понятно, как это будет выглядеть. Как я понимаю, Аксапта использует серверные курсоры, то есть, на сервер посылается запрос но результат возвращается не весь, а небольшими порциями, в зависимости от того, что видит пользователь.
Как это будет реализовано в нашем случае - мы будем моделировать аналогичное поведение или будем затягивать весь набор данных сразу на клиент ?
В первом случае, нам придется перехватывать и обрабатывать все действия пользователя с нашей таблицей - скроллинг, фильтрацию, поиск. Во-втором случае все гораздо проще, но мы создаем неоправданную нагрузку на сеть.

2.
Таблица будет только отображать данные или также позволит редактировать записи ? Добавлять записи ? Тоже есть ряд тонких моментов. Не совсем понятно, как это будет делаться в случае сложных датасоурсов, ну ладно, надеюсь по ходу дела пойму

3. Фильтрация
4. Поиск

Как я понимаю, таблица должна будет поддреживать все эти вещи. Фильтровать и искать будем на клиенте или на сервере ? Это имеет отношение к пункту первому.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Андре
Мне показалось как раз наоборот. Наверное я просто не вижу всех сложностей второго варианта.

Да, может мы просто не поняли друг друга. Сейчас перечитал твой первый пост. Да, если действительно просто отображать ResultSet - задача, наверное, получается проще. Кроме того, полученный результат будет уникальным, такого в AXAPTA действительно нет. Я как-то сразу же решил, что этот ResultSet захочится еще и редактировать потом. Да и применение, кажется, у второй задачи поуже будет.

Цитата:

Изначально опубликовано Андре
Тогда решим, что у нас в результате должно получится.
...
Загрузка данных в таблицу. ... Как я понимаю, Аксапта использует серверные курсоры, то есть, на сервер посылается запрос но результат возвращается не весь, а небольшими порциями, в зависимости от того, что видит пользователь.
Как это будет реализовано в нашем случае - мы будем моделировать аналогичное поведение или будем затягивать весь набор данных сразу на клиент ?

За доступ к данным, кэширование, фильтрацию и прочие вещи по части доступа к БД будет отвечать FormDataSource. Его переделывать, я думаю, не стоит.

Цитата:

Изначально опубликовано Андре
В первом случае, нам придется перехватывать и обрабатывать все действия пользователя с нашей таблицей - скроллинг, фильтрацию, поиск.

Да, придется. ИМХО, сложностей возникнуть не должно, так как фактически должна получится тонкая прослойка между FormTableControl и FormDataSource.

Цитата:

Изначально опубликовано Андре
Таблица будет только отображать данные или также позволит редактировать записи ? Добавлять записи ? Тоже есть ряд тонких моментов. Не совсем понятно, как это будет делаться в случае сложных датасоурсов, ну ладно, надеюсь по ходу дела пойму

Предлагаю начать с одного DataSource, но держать в уме, что в конце концов их будет несколько. По поводу работы со сложными DataSource мне тоже не все ясно пока, а что касается одного - а какие там будут сложности с редактированием и добавлением?

Цитата:

Изначально опубликовано Андре
3. Фильтрация
4. Поиск
...
Фильтровать и искать будем на клиенте или на сервере ?

ОК, задача - сделать интерфейс. Рутину пусть делает подцепленный DataSource. Если честно, я четко не представляю себе политику действий FormDataSource при фильтрации, если есть записи в кэше. Ну да это и не нужно.

[Maxim Gorbunov]

Тут сейчас с InventTable копаюсь. Что-то подумалось, что была бы интересной возможность добавления в TableControl налету (то есть прямо пользователем) колонок из FormDataSource привязанного. А то не очень приятно, когда на Tab'е Обзор ты видишь только те колонки, которые кто-то определил важными.

[Андре]

Цитата:

В первом случае, нам придется перехватывать и обрабатывать все действия пользователя с нашей таблицей - скроллинг, фильтрацию, поиск.

Цитата:

Да, придется. ИМХО, сложностей возникнуть не должно, так как фактически должна получится тонкая прослойка между FormTableControl и FormDataSource.

Смотри. Пользователь открывает форму, на нем расположен наш Table, в нем видно 10 записей. Ну мы и отображаем 10 записей, примерно так:

PHP код:

  table.cell(i, j).data(s); 


Теперь пользователь начинает скролировать Table.

Мы должны:

1. Добавить еще одну строку в Table
2. Прочитать из источника данных еще значений
3. Отобразить их в нашей таблице
4. Если это необходимо перейти к пункту 1.

Во-первых как мы может отловить момент скролированния таблицы. Единственное, чего мне удалось добиться это textChange у StringEdit'а вложенного в Table.
В нем нужно отрабатывать вышеописанный алгоритм ? Или есть более простой способ, которого я не вижу ?


P.S. И еще, я вспомнил про лукапы. Как их будем делать ?

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Андре
Смотри. Пользователь открывает форму, на нем расположен наш Table, в нем видно 10 записей. Ну мы и отображаем 10 записей, примерно так:

А вот и нет. Строчек сразу должно быть столько, сколько записей есть в таблице. О том, как узнать, сколько записей в таблице разговор отдельный. Насколько я помню писать в лоб select count(RecId) from Table нельзя, так как уж очень медленно получается.

Цитата:

Изначально опубликовано Андре
Во-первых как мы может отловить момент скролированния таблицы.

Это проблема, согласен. Надо думать. Ничего умного пока предложить не могу. Надеюсь, ко вторнику родится идея.

Цитата:

Изначально опубликовано Андре
Единственное, чего мне удалось добиться это textChange у StringEdit'а вложенного в Table.

Не очень понятно, как выделить ячейки, которые сейчас отображаются. А если у тебя несколько строчек с одинаковым текстом, textChange будет вызываться или у них есть оптимизация на этот случай?

Цитата:

Изначально опубликовано Андре
P.S. И еще, я вспомнил про лукапы. Как их будем делать ?

Lookup вешается на EditControl. Они, конечно, кривовато работают, но в принципе все можно сделать. Здесь проблемы нет.

[Maxim Gorbunov]

Есть идея. Заполнить cells чем-нибудь таким, что мы будем считать признаком "Не считано". Потом повесится на textChange и по мере поступления таких cell'ов читать их через DataSource. Как? Конечно, красоты мало в таком подходе, но у нас и средств не много...

Кстати, а ты пробовал addControl делать в динамике, а потом ему textChanged переопределять?

[Андре]

Цитата:

Есть идея. Заполнить cells чем-нибудь таким, что мы будем считать признаком "Не считано". Потом повесится на textChange и по мере поступления таких cell'ов читать их через DataSource. Как? Конечно, красоты мало в таком подходе, но у нас и средств не много...

Мда. Звучит не здорово, но буду пробовать. Ели это получится, интересна будет еще производительность такой системы.

Цитата:

Кстати, а ты пробовал addControl делать в динамике, а потом ему textChanged переопределять?

Нет. В выходные попробую.

[Андре]

Ну я и торможу. Только сейчас увидел, что у каждого конторла в Table есть свойства DataSource и DataField, и то лишь когда увидел, что есть метод - addDataField.

Правда добиться корректной работы мне пока не удалось, отображается только активная запись, та на которой курсор - так и положено или я что-то не так делаю ?

Насчет динамического добавления полей есть еще одна тонкость, при добавлении полей необходимо перекрывать метод editControl у Table.

Буду разбираться.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Андре
Ну я и торможу. Только сейчас увидел, что у каждого конторла в Table есть свойства DataSource и DataField, и то лишь когда увидел, что есть метод - addDataField.

Да, я посмотрел. Логика работы ясна: отображается соответствующее поле текущей записи FormDataSource. В принципе этого достаточно, если использовать Control только для редактирования (в activeCellChanged надо будет добавить переход на нужную запись).

Цитата:

Изначально опубликовано Андре
Насчет динамического добавления полей есть еще одна тонкость, при добавлении полей необходимо перекрывать метод editControl у Table.

editControl всего лишь в зависимости от индексов ячейки возвращает подходящий control для ее редактирования. Можно обойтись добавлением в editControl соответствующего метода класса и в нем уже разбираться со всем этим делом. Кстати, на счет динамического добавления контролов: надо бы продумать политику их добавления. По одному на каждое выводимое поле?

Основная проблема на данный момент - понять, какие ячейки выводятся, а какие нет. Как это делать, я пока не понял. Задал вопрос на TechNet, может повезет.

Кстати, по поводу наследования. Возникла бредовая идея разобраться с FormBuildTableControl и FormTableControl. Может удастся чего-нить понаследовать.

Вообще, не хотелось бы отказываться от FormTableControl, но все на черный день у нас и FormWindowControl есть.

[Андре]

Итак, что я посмотрел, как обстоит дело с динамическим добавлением контролов в таблицу.

Задача делится на две подзадачи:

а) определение количества и типов столбцов (как я понимаю информация будет браться из FormDataSource)
б) динамическое добавление этих столбцов в FormTableControl

Как я понимаю, пункт а) не представляет большой сложности (хотя я могу и ошибаться), так что насчет пункта б):

Вот я набросал одну формочку - на ней Table и две кнопки. При нажатии на одну из них в таблицу добавляется поле целого типа, при нажатии на другую - в таблицу добавляется поле типа Data. Естественно типов может быть и больше.

Несколько замечаний:

1. В таблице в дизайнере необходимо первоначально создать хотя бы один контрол, иначе даже при добавлении контролов в run-time изменения не видны. Если ты знаешь как это побороть - скажи, я поправлю.
2. Так как невозможно создать массив объектов, приходится создавать эти объекты динамически, а для этого пришлось завести массив, в котором хранятся типы столбцов. Хотя тут можно будет реализовать и более удачную конструкцию типа контейнера или map'а.

Далее насчет динамического перекрытия методов создаваемых контролов. Я там поэкспериментировал маленько: на форме есть метод createMessageHandler, в который мы передаем имя создаваемого метода и текст метода. Собственно сам createMessageHandler создает этот метод, который и будет обрабатывать требуемые события. Метод вызывается при добавлении в таблицу нового столбца, то есть нажатии на клавишу.
Для реализации этого пришлось пойти на следующие допущения:

1. Ввести ситему именования создаваемых контролов (тип+номер столбца, например int2, date3), а следовательно и методов (int2_textChange)

Недостаток этого подхода: при нажатии на клавишу - создается столбец в таблице, создается контрол в таблице, контрол привязывается к столбцу и даже создается обработчик для этого контрола. НО, чтобы этот обработчик заработал, надо открыть и закрыть форму. Именно поэтому, я и не стал писать код, удаляющий динамически созданный обработчик событий.
Посмотри сам: открой в АОТ методы формы и запусти форму, понажимай на клавиши и увидишь, как в АОТ появляются методы. Но они пока не действуют. А теперь закрой форму, и снова запусти ее, НО не удаляя созданные методы. Теперь все работает.

Хотя нет, написал и сам понял. Все нормально. Эти методы в форму у нас будет добавлять класс. Затем, и только затем, эта форма будет запускаться нашим классом, а по окончании ее работы, класс будет уничтожать созданные методы. В этом случае все будт работать.

Но я еще не вижу все картины, поэтоиу не могу сказать, как делать лучше

Что ты думаешь по этому поводу ?

[Андре]

Предыдущее сообщения я написал 23-го. А 24-го с утречка решил взгянуть на картину шире и понял, что не пока понимаю довольно важной вещи, без которой все предыдущие рассуждения могут не иметь смысла:

Каким образом в таблицу будут выбираться поля для отображения из датасоурса(ов) ???

Я вижу следующие варианты:

1. При загрузке формы(перед загрузкой формы) в таблице автоматически создаются контролы и к ним привязываются обработчики событий. Это то, над чем я экспериментировал вчера.

Достоинства: при удачной реализации, минимум работы программиста, использующих этот проект.
Недостатки(?): а каким образом программа автоматически поймет, какие поля вытягивать в таблицу ? Никаким. Значит программист должен как-то указать классу, создающему поля в таблице, какие именно из них он хочет в ней видеть. Каким образом он будет это делать ? У тебя уже есть какие-то идеи, или это пока что совершенно не продуманная область ?

2. Что-то типа wizard'а, который мы натравливаем на заданную форму. Он спрашивает про интересующие нас поля и генерит контролы в таблице и все необходимые обработчики методов.

Недостаток: сгенерированную, таким образом форму в дальнейшем придется сопровождать "ручками", без участия нашего мастера. То есть, если в дальнейшем, в эту таблицу нужно будет вытащить еще один столбец, то либо программисту придется это делать ручками, либо наш мастер должен быть очень умным.

3. Все контролы в таблице создаются вручную программистом. Им же создаются все необходимые обработчики событий.

Плюс: минимум работы с нашей стороны
Минус: и кто же после этого будет этим пользоваться ?


Ты задумывался над этим ?

[Андре]

Цитата:

Вообще, не хотелось бы отказываться от FormTableControl, но все на черный день у нас и FormWindowControl есть.

На черный день у нас есть ActiveX. Как еще один вариант, можно попробовать написать свой ActiveX контрол на обычном языке программирования и использовать его в Аксапте. Но это совершенно другая задача и боюсь времени на нее понадобится не меньше.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Андре
В таблице в дизайнере необходимо первоначально создать хотя бы один контрол, иначе даже при добавлении контролов в run-time изменения не видны.
...
Далее насчет динамического перекрытия методов создаваемых контролов. Я там поэкспериментировал маленько: на форме есть метод createMessageHandler,
...
НО, чтобы этот обработчик заработал, надо открыть и закрыть форму.
...
Посмотри сам: открой в АОТ методы формы и запусти форму, понажимай на клавиши и увидишь, как в АОТ появляются методы.
...
Что ты думаешь по этому поводу ?

Э-э... А можно форму-то посмотреть?

Цитата:

Изначально опубликовано Андре
Каким образом в таблицу будут выбираться поля для отображения из датасоурса(ов) ???

Если ты про то, каким образом выбирать поля для добавления, то я предлагаю... третий вариант. Во-первых, он наименее для нас трудоемкий. Во-вторых, я не вижу проблем на пути перехода от него к другим двум вариантам. Короче, предлагаю для прототипа использовать явное добавление контролов и колонок. Вообще, для себя я вижу эту проблему так: сначала (возможно, в результате работы мастера, а может еще как) выбирается какой-то определенный набор столбцов и сохраняется в SysLastValue; класс работает уже только с набором столбцов, сохраненным в SysLastValue для данного FormTableControl и данного пользователя.

[Андре]

Цитата:

Э-э... А можно форму-то посмотреть?

Прошу прощения.

Цитата:

Если ты про то, каким образом выбирать поля для добавления, то я предлагаю... третий вариант.

Нет. Вопрос не как выбирать. Вернее не столько как выбирать, а как добавлять. Каким образом столбзы будут ДОБАВЛЯТЬСЯ в таблицу: динамически (прикремленный файл), мастер или пользователь (см. сообщение выше).

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Андре
Нет. Вопрос не как выбирать. Вернее не столько как выбирать, а как добавлять. Каким образом столбзы будут ДОБАВЛЯТЬСЯ в таблицу: динамически (прикремленный файл), мастер или пользователь (см. сообщение выше).

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

[Андре]

Цитата:

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

ОК. Скорее всего все будет нормально. В ближайшее время попробую.

[Андре]

Времени мало, поэтому сделал не много. Здесь я приложил проект - там форма и класс запусай класс.

Несколько пояснений. Вот new() этого класса:

PHP код:

void new(str _formName)
{
   Args arg = new Args();
   FormRun formRun;
   ;

   colCount = 0;
   formName = _formName;

   // Столбцы нужно удалять в том же порядке, в каком они и создавались

   this.addColumn("int");
   this.addColumn("int");
   // ...
   this.createInit(formName);

   arg.name(formName);

   formRun = ClassFactory.FormRunClass(arg);
   formRun.init();
   formRun.Run();
   formRun.wait();

   this.deleteColumn("int");
   this.deleteColumn("int");
   // ...

   this.deleteInit(formName);

} 


Что делает этот метод: в него передается имя формы.

Вот здесь:

PHP код:

   this.addColumn("int"); 


в таблицу на форме добавляются столбцы переданного типа.

P.S. 1. Реализованно только для int, но это легко расширяется.
1а. Класс ищет именно таблицу с именем Table и именно в корне design. В будущем расширяемо.
2. В addColumn происходит перекрытие textChange() для добавляемого столбца.
3. Как я понимаю именно это ты имел в виду здесь :

Цитата:

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

Затем форма запускается. После закрытия формы все, что в ней насоздавали подчищаем.

За всем этим делом лучше всего наблюдать так: открыть в отдельном окне форму, развернуть ветвь ее методов и контролов в Table и запустить класс. При этом форма откроется, а в АОТ'е будет видно, что в таблице создались контролы, а в форме соответствующие обработчики событий. После закрытия формы, в АОТ'е видно, что все созданное удалилось. Поиграйся(поскролируй) Table и ты увидишь, что для каждого столбца работает свой обработчик событий.

Итог: мы напускаем класс на форму с Table, класс генерит в этом табле кучу всего, запускает форму, после ее закрытия все подчищяет за собой.

Вроде как работает, но это пугает меня - самомодифицирующийся код никогда не отличался надежностью, легкостью сопровождения и отладки

В общем посмотри проект и скажи что думаешь.

[Андре]

Отложим (на время) динамическое формирование таблицы и подумаем о том, как у нас эта самая таблица будет заполняться данными. Как мы решили, данные будут грузиться не сразу все, а по мере необходимости.
Максимально упростим пример. Вот форма, на ней таблица, в ней один столбец, в который должно выводиться itemId из invatTable, которое являетмся dataSource в этой форме.

В executeQuery() мы определяем количество записей в таблице(забудем пока про производительность и оптимальность и попробуем просто понять принцип работы) и добавляем первые 20 записей в таблицу:

PHP код:

public void executeQuery()
{
    int i, t;
    ;
    super();

    qr = this.queryRun();

    recCount = SysQuery::countTotal(qr);
    Table.rows(recCount);

    t = min(20, recCount);

    qr = this.queryRun();
    it = qr.get(tableNum(InventTable));
    itemId = it.ItemId;

    Table.cell(1,1).data(itemId);
    displayCount = 1;


    for (i=2; i<=t; i++)
    {
        qr.next();
        it = qr.get(tableNum(InventTable));
        itemId = it.ItemId;
        Table.cell(1,i).data(itemId);
        displayCount++;
    }
} 


Перекрываем textChange() у контрола, который привязан к таблице:

PHP код:

public void textChange()
{
    super();

    if (displayCount < recCount)
    {
        qr.next();
        it = qr.get(tableNum(InventTable));
        itemId = it.ItemId;
        displayCount++;
        Table.cell(1, displayCount).data(itemId);
//        info("добавлена еще одна запись");
        print itemId;
  //      pause;
    }
} 


То есть при вызове этого метода из таблицы считывается следующая запись и добавляется в таблицу, тем самым эмулируя поведение серверных курсоров ADO.
Когда будешь пробовать попробуй сначала так, а затем раскомментировав сторки. Результаты чуть-чуть разные, но выводы примерно такие:

Если мы хотим, чтобы textChange() вызывался со 100% гарантией пользователь должен щелкнуть мышкой на одну из ячеек таблицы и клавишами "стрелка вниз", PageDown перемещаться по таблице. Так вроде все работает. Если же пользователь начинает скролировать таблицу, то часто получается ситуация, когда пользователь начинает видеть пустые незаполненные строки.. в общем сам увидишь.

Кроме того, textChange() будет вызываться даже тогда, когда пользователь начнет перемещаться по таблице вверх - вроде бы не надо, но в таблицу все равно будут добавляться новые записи.

Можно сделать следующее(только что пришло в голову) - выбросить из таблицы скролбар(раз им все равно пользоваться нельзя), а в замен попробовать подсунуть пользователю что нибудь другое(в простейшем случае пару кнопок). Положение курсора в таблице тображать например с помощью progressBar'а. В общем все дело опять уходит в дебри и превращается в неудобную конструкцию.

Буду дальше экспериментировать, но и ты скажи свое мнение, а то может я вообще не в том направлении двигаюсь и фигней занимаюсь ?