sg12Как вы думаете, что изменится, если из его главного модуля перенести процедуры добавления, удаления, редактирования, а также сохранения и восстановления в следующие процедуры объекта oTable
Сместится точка возникновения ошибок. Ошибки будут происходить в этом коде. Сообщения об ошибках будут указывать на этот код и будет непонятно где реально ошибка.

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

В остальном ничего не изменится.

И потом сам предлагаемый шаблон изначально ущербный.
Например oTable.DoEdit('add') не сработает и ошибки не будет.
Если уж городить огород то делать oTable.Add()

sg12Что изменится? Главный модуль "похудеет" и станет менее "страшнее" на пять процедур, и это только начало.
А для работы с этими процедурами напишем объект класса CommandGroup с тремя кнопками, который будем навешивать на формы.
Или два класса - по 3 и 2, кому что по вкусу.
Т.е. избавим наши формы от необходимости чуть не в каждой писать индивидуально эти же процедуры, от которых рябит в глазах.
Я с этого начинал десять лет назад. На сегодня для создания простого справочника мне достаточно написать одну строку в командном окне. Просто вызвать функцию создания форм справочника и передать ей имя таблицы


Она создает и добавляет в текущий проект две формы: для просмотра и редактирования. Добавляет таблицу в DE формы, прописывет необходимые свойства формы и контролов, в форме просмотра прописывает грид (ставит таблицу источник данных, создает там одну колонку "Наименование", прописывает туда первое текстовое поле таблицы). В форме правки вытаскивает на форму все поля.
Дальше остается только орудовать мышкой распределяя контролы по форме и прописывать Caption.

Вот для примера сделал с нуля проект за 10 минут. Два справочника.

На картинке скриншот того что получилось. Теперь о доступном функционале:
Все формы немодальные. Можно открыть несколько записей справочника на правку. Автоизменение размера шрифта в зависимости от разрешения экрана и возможность задать свой размер.
В форме с гридом все необходимое для работы без мыши: поиск по первым буквам, установка фильтра, "горячие" клавиши (Ins добавить, Del удалить и т.д.). В меню по правой кнопке мыши копирование в буфер обмена всего показанного в гриде.
В форме редактирования прописана буферизация на случай отмены изменений.

Еще раз подчеркиваю - не писал вообще ни одной строчки кода внутри форм.
Осталось написать код создания меню, start.prg из десятка строк и прога готова. Как-то так должно быть как мне кажется.

sg12Dima T

В этот раз согласен.
Но даже не зная твоей проги, могу уверенно сказать, что она легко впишется в описываемый перестроенный главный модуль.
И при этом значительно упростится, так как часть ее функционала уже будет сидеть в нем.
Хочешь делать oTable - делай. Мое мнение он нафиг не нужен. Это что-то из серии когда с паскаля пересаживаются на Си и дефайнами прописывают замену сишных { } на паскальный BEGIN END. Только чтобы по привычке пользоваться BEGIN END в коде.
Кстати ты бы хоть просвятил что это за такой главный модуль. Я как-то пропустил где его обсуждали.

sg12К примеру кнопки - пара кнопок Сохранить и Отмена это стандартный объект на основе CommandGroup, пригодный куда угодно. Другую группу кнопок я уже описал.
В фоксе все завязано на формах, поэтому рекомендую начинать с именно с построения своего класса формы. Сама пара кнопок "Сохранить и Отмена" без формы не используется, поэтому можешь конечно сделать их отдельно, но этим только разработку себе усложнишь. Часть кода в одном классе часть в другом, а используются всегда вместе. Да и две пары таких кнопок на одну форму тоже не потребуются.
sg12Твой текстбокс с кнопкой "..." тоже выносится в базовые классы в виде контейнера и его не надо будет писать в каждой проге.
Он так и сделан как отдельный контрол с текстбоксом и кнопкой внутри.
sg12Автоизменение сам бог прописал решить универсально в классе на основе Custom, добавляемым в формы.
Универсально не всегда удобно. Лично я это все прописал в классе формы.
Я предпочитаю укрупненные классы "ФормаПросмотр", "ФормаПравка" и т.д. у меня десяток классов форм на разные случаи.

PaulWistDima TВот для примера сделал с нуля проект за 10 минут. Два справочника.
...
Все формы немодальные. Можно открыть несколько записей справочника на правку.
...

Вот с этого места по подробнее:

- что является базовым классом для пары форм ФормаСправочник-ФормаРедактирование, form или formset ?
Базовый класс "БазоваяФорма". От нее унаследованы ФормаСправочник, ФормаРедактирование и вообще все классы форм. Вобщем все построено на классе БазоваяФорма.
formset никогда не использую. Если честно так и не понял зачем он вообще нужен.

PaulWist- как пара ФормаСправочник-ФормаРедактирование связаны с данными, те 'эта пара разделят одну сессию данных или у каждой своя?
У каждой формы своя.
Form.DataSession = 2 Private Data Session

PaulWist- как две пары ФормаСправочник-ФормаРедактирование и ФормаСправочникГруппа-ФормаРедактированиеГруппа возвращают значения в обратном порядке, поясню: открыли СправочникТовар - открыли СправочникРедактированияТовара через новую запись товара - открыли СправочникГрупп - открыли СправочникГрупп через создание новой группы,... закрыли форму СправочникГрупп (ведь формы не модальные) , вопрос - куда вернёт ФормаРедактированияГрупп новую запись группы?

Как это реализовано?
После вызова дочерней формы ей передается ссылка контрол родительской формы куда вернуть фокус. По закрытию дочерней фокус возвращается на этот контрол родительской если она существует. Если родительской формы не существует - никуда не вернет.
В данном примере две ситуации:
1. ФормаСправочник вызывает ФормаРедактирование. Передается ссылка на форму ФормаСправочник. По закрытии вызывается метод ФормаСправочник куда передается ID записи которая была добавлена/исправлена. ФормаСправочник обновляется и текущая запись ставится на полученный ID, а фокус на грид.
2. Контрол ввода из справочника на ФормаРедактирование вызывает ФормаСправочник. Передается ссылка на Контрол ввода из справочника. По окончании выбора ФормаСправочник вызывает метод контрола передавая ID в параметрах. Дальше контрол сохраняет ID в таблицу, меняет отображаемый текст и устанавливает фокус на себя.

Я думаю уже понятно что длина цепочки ничем не ограничена. Можно открыть хоть сотню ФормаРедактирование одного справочника. ФормаСправочник тоже, но во избежания бардака ФормаСправочник у меня всегда одна для одного справочника.

sg12Закончим первый этап, а то похоже на сворачивание на базар.

Добавим объект oFoxObj.
В нем создадим процедуры DoForm,DoForms,DoToolbar,DoMenu,DoMenuShortcut, при необходимости можно добавить новые..
Простой вопрос: ты планируешь писать хэлп по результату своего творчества?

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

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