Моя идея ограничивалась внесением в обязательный интерфейс строки метода, предоставляющего информацию о провайдере.
Примерно так, как это сделано для CSQLRow::GetProvider.
Иначе получив строку откуда-то я понятия не имею, что с ней делать - интерфейс неполный.

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

Выкладываю зародыш динамического провайдера. Местами он даже иногда бывает частично работает
Ссылки:
http://uzhast.fatal.ru/vfp.oledb.provider/
http://uzhast.fromru.su/vfp.oledb.provider/

Установка как обычно: скопировать dll (1cpp.dll и CursorGrid.Provider.OleDb.VFP.dll) в BIN. Для проверки использовать обработку "Тест провайдера (динамика).ert". В каталог базы надо положить файл QueryRows.prg (в будущем этот файл будет создаваться сам).

Заполнение полей тестовой обработки:
Опорная таблица
Название таблицы, по которой провайдер ходит методами XBase. Например, "$Справочник.Номенклатура", "1sjourn".

Поле-ключ
Поле, идентифицирующее запись опорной таблицы. Для справочников - ID. Для журнала IDDoc.

Тег индекса
Тег, используемый для упорядочивания опорной таблицы. Названия индекса можно посмотреть в 1cv7.dd.

Текст запроса
Текст запроса Должен иметь вид SELECT ... FROM ОпорнаяТаблица WHERE IDПоле IN (%СписокИД%) ORDER BY ВыражениеУпорядочивания. Можно делать джойны (например, к остаткам товаров/взаиморасчетов) и т.п. При передаче в OLE DB строка %СписокИД% заменяется на полученный методами XBase список ИДшников.

Запрос обязан вернуть столько строк, сколько было ИД в строке "СписокИД". Поэтому всякие INNER JOIN, скорее всего, не желательны - в этом случае нормальная работа провайдера не гарантируется.

ЗначениеУпорядочивания должно упорядочивать строки выборки строго в том виде, в каком строки упорядочиваются при помощи указанного тега индекса.

Таймаут обновления
Таймаут, он и в Африке таймаут. Работает, проверял.

Отладка
При включенном флажке злобно матерится в окно сообщений запросами, которые направляет в OLE DB, а также другой бесполезной информацией.


Всякие быстрые поиски и ключевые поля для ТП не работают. Фильтры (группа справочника, конкретный журнал документов) на опорную таблицу тоже наложить пока нельзя. И запросом вы это отрегулировать не сможете.

Изменения в 1С++
Вытащил наружу метапарсер. Перенес изменения spock'а для параметризованных запросов (но мне они (пока) не понадобились). Сырки 1С++ и провайдера обновлены и лежат рядом с компонентами.

kiruha писал(а) 26. Октября 2007 :: 09:03:

А ты поставил таймаут обновления? Тут ведь какая вещь... Если его не поставить сначала (он равен 0), то, если ставить потом, то он никак на ТП влиять не будет. Т.е. алгоритм такой: ставим таймаут, жмем кнопку "Выполнить".

kiruha писал(а) 26. Октября 2007 :: 09:28:

Включи флажок "Отладка" - сам увидишь, какие запросы выполняются.

kiruha писал(а) 26. Октября 2007 :: 09:28:

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

kiruha писал(а) 26. Октября 2007 :: 09:28:

Вроде бы проблем не должно быть, но не проверял еще.

Заявленных скачков в работе процессора не наблюдаю.

kiruha писал(а) 26. Октября 2007 :: 10:40:

Я не совсем в курсе, как ловить такие события (вернее, совсем не в курсе)

kiruha писал(а) 26. Октября 2007 :: 10:40:

Это связано с передвижением по журналу. Индекс определяет, как будут упорядочены записи. Он используется в QueryRows.prg для XBase-методов.

kiruha писал(а) 26. Октября 2007 :: 10:40:

Ну, вообще-то я не проверял, но, скорее всего, разный.

kiruha писал(а) 26. Октября 2007 :: 10:40:

Правда?! Вот здорово! (Я ведь действительно не проверял )

kiruha писал(а) 26. Октября 2007 :: 10:40:

При обновлении просто повторно выполнится запрос, который передали в провайдер. Так что все должно обновиться. Однако, как-то я наступал на грабли, что в некоторых случаях в OLE DB провайдере для Фокса может происходить своего рода кеширование запроса. Т.е. на совершенно одинаковые запросы может выдаваться совершенно одинаковый ответ, хотя данные поменялись (внешним для Фокса образом - из 1С). Если ты столкнешься с таким поведением, то пиши сюда. Это вроде побеждается. Хотя наличие CLOSE TABLES вроде это должно лечить и так...

kiruha писал(а) 26. Октября 2007 :: 12:09:

Ну, пропатченный провайдер для OLE DB позволяет выбирать данные из заблокированных 1С таблиц. Вот, правда, не проверял, насколько это действительно в случае XBase-методов. Надо будет проверить...

spock писал(а) 26. Октября 2007 :: 18:07:

А вроде же кто-то говорил, что он медленнее? Или это не так? А с XBase у него как?