автортолько грид записать как класс...без формы

используют такие приемы:
1. создают класс-форму + грид
у грида создают методы видоизменения и управляют какими-то
свойствами (т.е. кладут гриду или строку с информацией как взлететь,
или он берет эту информацию у какого -то объекта)
т.е. видоизменение производят во время выполнения
2. создают класс-форму + грид
от нее делают наследника и визуально трогают у грида колонки
и что-то у формы и сохраняют именно класс-форму в библиотеку
и поднимают именно класс-форму сразу с уже переделанным гридом

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

я советую все-же не выдергивать грид, а хранить его на форме вместе с самой формой
в библиотеке.

применение процедур (отказ от визуальных библиотек) усложнит разработку и увеличит трудозатраты.

для информации
пример наследования класс-формы
с видоизменением с помощью создания строки-настройки

можете подсмотреть метод взлета грида и чтения строки-настройки
(возможно будет интересно)

Form Designer
не предусмотрен, не создавался для сохранения отдельных
настроенных на форме объектов, однако имеется возможность
создание собственных билдеров или изменение существующих
(проекты с исходными кодами билдеров имеются в поставке фокспро)
т.е. его поведение разработчиками виз.среды описывалось
строго под поставленный алгоритм и задачи - создать/изменять форму,
готовую для запуска в приложении командой do form.

Form Designer
это наследие младших версий фокспро,
которое разработчикам приходилось так-же дорабатывать
и в старших версиях.
поэтому некоторый стиль разработки (ООП), который появился в старших версиях +
некоторые приемы, которые стали применяться не предусматривает(ют) использование этого инструмента по некоторым причинам.

Основная причина - это то, что форма - это контейнер с заранее предусмотренным
алгоритмом поведения и набором объектов,
что часто бывает неудобным при попытке создания библиотек собственных классов.

авторА нельзя перед CursorFill() сбрасывать RecordSource грида, а затем обратно восстанавливать?

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

у него проблема в видоизменении этого объекта на форме +
он смешал в коде еще и бизнес (выполняет какие-то рассчеты),
что также можно решить методом вынесения бизнеса из класса грида в
отдельные сущности.

авторСмотрите мой пост выше.

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

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

поэтому каких-либо выгод от хранения отдельного класса-грида я не вижу

CursorFill() видимо применяется из-за динамического изменения строки ограничения запроса

если именно в этом проблема, то я подскажу каким образом в JDBC
использовать статичный параметр и использовать курсоррефреш

автор на каждой ячейки понавешаны конечно же расчёты и проверки

авторДа...я так и делал для простых гридов...но как Вы в
.Column1.txt1.valid = ... пропишите функцию какую-нибудь, типа replace col3 with col1+col2 и т.д.

бизнес не нужно писать в методы объектов грида напрямую
вызов бизнес-кода необходимо звать через "обертки",
т.е. создается класс-грид с классами-контролами в колонках с заготовленными
методами проверки существования и выполнения методов каких-то бизнес-сущностей.

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

авторВы случайно не преподователь

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

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

авторкстати и навешивание процедур на столбцы
такие методы я могу продемонстрировать, но

каким образом можно проверить валидность данных:
- либо со стороны клиента (клиентом, кодом фокспро)
- со стороны сервера (контроль целостности данных)

аналогично и посчитать что-то мы можем либо на клиенте, либо на стороне сервера

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

чаще всего в реальных приложениях применяются оба способа в совокупности

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

авторЕсли я эту задачу перепишу на классы

обратите внимание на разработки из поставки фокспро + проект vfpx.

как Вы думаете, почему разработчики выбрали для разработки приемы ООП?
наверное не только для того, чтобы в этом никто не разобрался.


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

авторКстати я уже писал, что методы при отвязки и привязки ControlSorce не работают
обратите внимание на пример, опровергающий данное утверждение