В FoxPro нет объектного меню. Хотя можно симулировать объектность для меню. И есть готовые утилиты, которые это делают. Но можно написать и самому подобную оболочку.

Однако факт наличия метаданных (DBF-таблицы с описанием пунктов меню) не будет лишним в любом случае, поскольку он позволяет существенно упростить раздачу прав доступа и факт отображения (или доступности) отдельных пунктов.

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

Кроме того, насколько я понимаю, у вас уже есть готовая учетная система со сложившейся идеологией построения интерфейса и обработки. Если ООП противоречит этой идеологии, то вам придется, по сути, писать приложение заново. Заново создавать интерфейс и обработку.

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

Обратите внимание на то, что сказал прошелмимо . Даже простое перечисление показывает как много работы предстоит сделать. Вы действительно способы "потянуть" такой объем работы?

wasClipperЧто касается интерфейса (пользовательского) - никак не зависит от среды прогр., ИМХО.
Большое заблуждение. Выбранная среда программирования диктует вполне определенный пользовательский интерфейс. Вы можете, приложив титанические усилия, изменить интерфейс до не узнаваемости, но это будет требовать от вас постоянных усилий по поддержанию такого приложения.

wasClipperУважаемый, ВладимирМ, в том-то и дело, что у меня времени не хватает. Но копи-пасте в модулях я не буду делать.
...
Уважаемый ПРОШЕЛМИМО, боюсь, что я пока не обладаю достачными знаниями, чтобы оценить ваше решение, мне, правда, пока понятнее плоское (модульное-процедурное) решение.
А вообще у меня задача - оставить на сопрождение что-то более или менее сопроводаемое (т.К. от 1С от они с криками АТУ ЕГО АТУ отказались). Что делать не знаю.
Тогда не мудрите. Пишите как умеете. Естесственно, стараясь, по мере возможностей, изучать новые идеи и приемы программирования

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

Однако проблема в другом. Чтобы написать систему, которая достаточно проста в сопровождении, требуется написать собственный FrameWork (библиотеку классов). На основе которого, впоследствии, это приложение и будет построено. Ну, это как некоторый набор "стандартных" процедур и функций в процедурном программировании. И вот здесь-то и сосредоточено большое количество проблем.

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

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

И то и другое требует достаточно много времени и сил. Просто планирование, теоретически, можно переложить на другого человека. Если таковой имеется.

SvIvaTo Vladimir,
Позвольте с вами не согласиться. Пользовательский интерфейс при вненяемом Постановщике никогда не зависит от прог.среды. Можно аргументы ?

Можно.

Формы - "по умолчанию", они "заточены" на работу In Screen. Можно сделать приложение на базе As Top-Level форм, но это потребует дополнительных усилий

Меню на форме (In Screen) - приложив героические усилия можно симулировать в Foxpro. Однако "по умолчанию" среда этого не позволяет

Grid - это "окно" через которое мы смотрим на таблицу. Управлять данными модифицируя "окно", в принципе, можно, но требует огромных усилий. Т.е. сделать, например, аналог сетки Excel, можно, но сложно.

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

Пример: Task Pane смотрится явно чужеродным объектом. "Не родной" внешний вид и интерфейс.