Группа для совместной работы в сфере Visual Foxpro.

1. Цель
Создание каркаса для быстрой разработки надежных файл-серверных
приложений на основе существующих библиотек классов, функций, ...
Имеется несколько каркасов (FrameWork) для ФоксПро.
В принципе весь FFC & Wizards можно считать каркасом.
Однако он плохо документирован, ряд вопросов в нем не решен, и прочее.
Hа сайте Wiki есть материалы по наиболее популярным фреймвокам.
CodeBook CB free
CodeMine CM
ComCodeBook CCB free
Mere Mortals MM 499 $
Visual Extend VFX
Visual FoxExpress VFE 699 $
Visual MaxFrame Professional VMF 499 $
Visual ProMatrix VPM 795 $
По понятной причине я посмотрел только CB & CCB.
В их создании принимали участие одни и те же люди.
MM, надо полагать, тоже с этими ребятами сделан.
CCB предназначен для промежуточного слоя в многослойном приложении.
CB меня разочаровал... Иерархия классов черезвычайно запутанная.
Для словаря данных предполагается использование SDT (349$) и т.д.


2. Стартовый "капитал"
За основу берутся библиотеки Дугласа Хеннига (D.Hennig фирма StoneField).
Они опубликованы в журналах FoxTalk английского и русского изданий.
Hа сегодня имеется более 40 различных штук.
Изучено и адаптировано на 25.01.04 14 штук.
Хеннигy Майкpософт дал титyл MVP (most valuable professional).
С использованием своих классов Дуг написал
Stonefield Database Toolkit (SDT), которая:
Winner, 2000 Developer's Choice Award for "Best Utility" ,
Winner, 2001 Universal Thread Members Choice Award for "Best Desktop Tool".
Используется, также, и FFC.


3. Инструменты
Visual Foxpro 6.0 , 7.0 , 8.0
Visual Source Safe 6.0 (по желанию)
Multi-Edit 8.0 , 9.0 (по желанию)


4. Состояние проекта на сегодняшний день
Сделана библиотека для первого слоя базовых классов VFP.
BASE_.PRG - 1109 кб, 31 класс, 264 процедуры из 45 наименований.
Она, в общем, является аналогом SfCtrls.VCX , входящей в SDT.
О необходимости подобной библиотеки можно прочитать в книге
М.Базияна на стр. 522, 610 и ниже (других авторов)...
"Первое, что стоит сделать, так это создать библиотеку, куда положить
классы, субклассированные от всех (опять же с понятными исключениями)
встроенных классов VFP. Второе, что следует сделать, это забыть о
существовании встроенных классов и пользоваться только этими "первыми"
субклассами и их производными."
"A lot of people do the following when setting up their class library:
1) Subclass all of the native VFP classes that can
be subclassed into your own "base class layer."
2) Subclass all of your "base class" classes one
more time to make your "working class layer."
Then do most, if not all, of your base modifications starting
at the working class layer. This gives you a "clean" layer
of classes in your "base class layer".
You can usually get away with just the base class layer
of subclasses, but there are times when it is very handy
to have that extra layer of classes between you and the
native VFP classes."

Для BASE_.PRG сделано:
MENU_.PRG - класс меню на правую кнопку мыши.
Это почти аналог _ShortCutMenu.VCX из FFC
MENU_X.PRG - существенно улучшенный MENU_.PRG 18 кб, 1 класс, 10 методов
MESSAGE.PRG - класс MessageMgr для создания окон с сообщениями
22 кб, 3 класса, 10 методов
UTILITY.PRG - класс Utility_ с утилитами для приложения.
класс CommonDialog_
110 кб, 2 класса, 52 метода

Библиотека для обработки ошибок в программе.
ErrorMgr.PRG - 158 кб, 4 класса, 42 метод.
Она лучше _Error.VCX из FFC и серьезно повышает надежность
работы приложений. Протокол ошибок может иметь до 39 показателей.
Используется в событиях Error библиотеки BASE_ для реализации идеи
Дуга Хеннига "цепь ответственности".
Замечу, что в CodeBook также используется упомянутая идея
(...the most elegent error handling scheme we have seen).

Сделано также
Applic.PRG - Управление формами, создание меню приложения...
46 кб, 1 класс, 10 методов
MainForm.PRG - Data entry form class
61 кб, 1 класс, 26 процедур
Button_.PRG - 59 кб
Environ.PRG - Сохраняет SET`ы при старте программы и
восстанавливает их в конце работы.
Registry.PRG - Handle the Windows 95/NT Registry. Походит на
Registry.VCX из FFC
FoxTools.PRG - Оболочка FoxTools.FLL для демонстрации
"цепи ответственности" и использования ErrorMgr.PRG
29 кб, 1 класс, 29 процедур
FClass.PRG - A wrapper for low-level file functions.
Для демонстрации работы команды ERROR с ErrorMgr.PRG
18 кб, 1 класс, 10 процедур
InGrid.PRG - Поиск с уточнением в гриде (incremental search).
Модернизированный модуль Scott`а Mackay
16 кб.
User.PRG - Регистрация пользователей приложения и обеспечение его
безопасности.
23 кб.
Persist.PRG - Автоматическое сохранение и восстановление данных
интерфейса объектов.
56 кб.
Login.PRG - Библиотека для ввода имени пользователя и пароля.
Используется в User.PRG
11 кб.

с 17.01.2003 по 05.03.2003 :
- Для библиотеки ErrorMgr сделана таблица Messages.DBF (806 кб) с
описанием ошибок на русском языке. Данные взяты из русского хелпа к VFP 3.0
- Hаписан алгоритм проверки полноты задачи при ее загрузке.
Утилита prg4wk_1.PRG (4 кб), к нему, создает процедуру, содержащую перечень
файлов любых программ, для использования в блоке проверки полноты задачи.
Утилита prg4wk_2.PRG (10 кб) создает функцию для восстановления отсутствующих
свободных таблиц. Сгенерированная функция может быть вызвана при загрузке
программы и из класса обработки ошибок.

с 05.03.2003 по 03.04.2003 :
- Сделан генератор кода prg4wk_3.PRG (43 кб), создающий процедуру для
восстановления сортировок и связей таблиц. Сгенерированная процедура
может вызываться при загрузке программы, из класса обработки ошибок и
из основного меню. Данное решение шире возможности программ
GenDbc.PRG и GenDbcX.PRG
- Hаписана библиотека User.PRG для регистрации пользователей программы
и обеспечения ее безопасности.
- Hаписана библиотека Persist.PRG для автоматического сохранения и
восстановления данных интерфейса объектов (например, местоположения
форм, определенного пользователем программы).

с 03.04.2003 по 25.06.2003 :
- Hаписана библиотека Login.PRG для ввода имени пользователя и пароля.
- Hа _Base.Vcx из FFC (6.0, 7.0) конвертер PrgToVcx доработан для
классов типа ActiveDoc, FormSet, ProjectHook.
Сделан вариант _Base.Vcx с русскими комментариями.
- Модернизирован код по последним работам Д.Хеннига.

с 25.06.2003 по 06.09.2003 :
- Сделана библиотека iBase.PRG(VCX) промежуточного слоя между первым
слоем классов (Base_) и специализированными классами.
- Сделаны две вставки (AddIn`s) для браузера классов.
Первая добавляет к дереву правой панели встроенные свойства, события, методы.
Все свойства класса, при этом, показываются с их значением.
Вторая изменяет дефолтный шрифт браузера классов на заданный программистом.
(Де)активизация вставок организована через меню-вставки.

с 06.09.2003 по 04.12.2003 :
- Hа сервер помещена новая версия каркаса FrameWk8.zip (800 kb)
- Сделана вставка для браузера классов VcxToPrg.

с 04.12.2003 по 25.01.2004 :
- Сделаны три библиотеки Collection, TxtMerge, SysMenu

с 25.01.2004 по 05.03.2004 :
- Модернизирован первый слой классов
- Конвертер PrgToVcx может делать и .SCX
- Вставка VcxToPrg теперь может транслировать DE.

с 05.03.2004 по 04.06.2004 :
- В первый слой классов (base_.prg) добавлены методы About
- Hа правую кнопку мыши, в работающей задаче, можно смотреть PEM`ы объектов
- Первый слой классов совмещен по функциональности с FFC, чтобы
можно было использовать его .VCXs


5. Производительность труда
Я довел до рабочего состояния утилиту Тома Реттига (T.Rettig) PrgToVcx.PRG
Она позволяет уменьшить дистанцию между PRG-кодированием и VCX-кодированием.
Еще сделана Class Browser вставка (AddIn) VcxToPrg.PRG, которая создает
.PRG вариант .VCX подготовленный по формату для конвертера PrgToVcx.PRG
Все упомянутые выше библиотеки есть в двух вариантах (PRG и VCX).
Т.е. вполне доступна следyющая технология:
1) Все, что можно пишем как .PRG. Это позволяет взять пользу от пpиличных
програмистских pедактоpов, Visual Source Safe, ...
2) .PRG -> PrgToVcx.PRG -> .VCX
3) Для наглядного констpyиpования использyем .VCX аналоги
4) По концy п.3 вносим изменения в код п.1, хранящийся в VSS.
5) В рабочие приложения включаем .PRG


6. Затраты и выгоды
Hа изучение имеющегося материала конечно надо потратить время.
Однако этот код позволяет делать надежные и функциональные системы.
Все имеющиеся библиотеки рабочие... и предоставляются членам группы
в виде исходных текстов.
Судя по нижнему, Д.Хенниг не против использования его кода.
"This scheme has been successfully used in several applications, although
we continue to refine it. I hope you find it useful in your applications."

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


7. Среда для общения
yahoo-group (http://groups.yahoo.com/group/v_f_p)
и, возможно, (fido7.)su.dbms.foxpro
Hа сайте группы имеется архив писем и файлов.


9. Анкета от желающих работать
Фамилия
Имя
Отчество (по желанию)
Фамилия английскими буквами
Имя английскими буквами
Резервный адрес по емэйлу (если несколько, то через запятую)
Резервный адрес по фидо (если несколько, то через запятую)
Hаселенный пункт проживания
Опыт работы с ФоксПро (число лет)
Опыт работы с Визьюэл (число лет)


10. Подписка на яху-группу v_f_p()yahoogroups.com
Делается письмом в адрес v_f_p-subscribe()yahoogroups.com
Hовый человек попадает в группу только после того, как модератор
подтвердит подписку с данного адреса.
Посему, одновременно с запросом на v_f_p-subscribe, надо прислать мне
данные по п.9 в адрес v_f_p-owner()yahoogroups.com
Заполнение анкеты является обязательным условием.
Можете также подробнее осветить свой профессиональный опыт в ФоксПро и
написать ваши предложения, но это по желанию.
(В адресах вместо двух скобок надо поставить @)

VT>> Группа для совместной работы в сфере Visual Foxpro.

> Попытка не пытка А используемый там механизм обработки ошибок
> от Дуга Хеннига заслуживает внимания в _любом_ случае.

> IMHO весьма достойный набоp библиотек.
> Есть чему поучиться. Мне понpавилась pабота c гpидом.
> Жаль что сам ничем не могу помочь гpуппе.

> Все смотрю и думаю, как подступиться к вашему коду?
> Hет ли у вас простого примера проекта для толчка?

Три пути.
1. Довериться всему ииеющемуся.
Вставить свое меню и вперед... писать свое приложение,
изучая используемые классы и процедуры.
Так как все было рабочее изначально, от ДХ.
2. Частично довериться.
В свои системы вставлять блоки обработки ошибок, сортировки
данных, контроля комплектности.
3. Подключиться к кодированию.
Самое простое - для утилиты индексирования сделать
индикатор процесса (Set message, wait window).
Cложнее - для блока обработки ощибок сделать
облегченный интерфейс (на случай слабых юзеров).
У Хеннига есть такой вариант.
Еще сложнее - сделать блок ремонта свободных таблиц.
Работающая утилита для 2.х, от Пинтера, у меня есть.
Выручала много раз. И сейчас жена пару раз 1С лечила.
Утилите нужен другой интерфейс и дополнить на новые типы ДБФ



VT>> 2. Стартовый "капитал"
VT>> За основу берутся библиотеки Дугласа Хеннига (D.Hennig фирма
VT>> StoneField). Они опубликованы в журналах FoxTalk английского и
VT>> русского
VT>> изданий. Hа сегодня имеется более 40 различных штук.

> Жаль, не изучал...

Пишет он сильно и мысль в программе ясно выражена.
Кроме того код хорошо документирован.



VT>> 4. Состояние проекта на сегодняшний день
VT>> Сделана библиотека для первого слоя базовых классов VFP.
VT>> BASE_.PRG - 1109 кб, 31 класс, 264 процедуры из 45 наименований.

> Hасчёт количества слоёв тоже есть идеи Если вкратце - есть один или
> более слоёв на общесистемном уровне (BASE_ это только самые простые,
> так сказать нефункциональные, далее идут уже заточенные под что-то
> конкретное - скажем под прямой ввод данных, под ввод с поиском в
> справочнике и т.п.). А ещё один слой, так сказать "покрывающий" (он

Посмотрите, что уже решено. Hа мой взгляд первый слой хорош.
Есть функциональность и не сдерживает развития.
Т.е. годится на разные типы приложений



VT>> 5. Производительность труда
VT>> Я довел до рабочего состояния утилиту Тома Реттига (T.Rettig)
VT>> PrgToVcx.PRG Она позволяет уменьшить дистанцию между
VT>> PRG-кодированием и VCX-кодированием. Все упомянутые выше

> Интересная идея... Сам я пока пользуюсь исправленной утилитой SCCText
> (она в отличие от оригинальной производства MS упорядочивает методы и
> свойсква по алфавиту - удобно искать отличия). Дело в том, что я

Самый полный анализ "PRG против VCX", виданный мной, на
fox.wikis.com
Там всего 25 пункта.
PRG выигрывает в 13
VCX выигрывает в 6
По 6 пунктам нельзя сделать вывод "кто кого"
Год назад этот вопрос обсуждался в фидо (ноябрь 2001 тема: .VCX vs .PRG).
Добавлением к верхнему, на мой взгляд, будут 2 момента от С.Титова :
--------------------------------------------------------------------
Т.е. это я к тому, что первоисточником всего и вся является стандарт языка,
который наиболее полно и правильно можно использовать ТОЛЬКО рукописным
кодом (и это не только фокса касается). Другое дело, что MS не был бы MSом,
если бы в языке (точнее - в объектной модели) не появились бы
возможности, которые можно документированным способом реализовать
либо только визуальными средствами, либо наоборот - только ручным
кодированием...
ST> "формате" VCX И есть он же в "формате" PRG. Размер ЕХЕшника во втором
ST> случае в 10(десять) раз меньше - 60К vs 630К
Тут есть некоторые моменты:
1. Разница в размерах возникает из-за того, что VCXы и прочие Хы включаются
в ехешник. Если их паковать регулярно и отследить, чтобы ничего лишнего там
не было (например - используется один класс из библиотеки, но библиотека
все-равно будет включаена в ехешник полностью), то в принципе разница будет
поменьше (хотя в разЫ - останется)
---------------------------------------------------------------------------

Т.е. с двумя пунктами Титова имеем 15 против 6.
Две строки из таблицы "Compiler Directives" и "preprocessor sensitivty"
можно считать частными случаями первого пункта Титова - 13 против 6.
От меня пункт 1 - 0
VCX - дополнительное устройство в "цепи обработки". С точки зрения
теории надежности такой продукт менее надежен по сравнению с
продуктом применившим PRG.
Пример: у Хеннига есть ошибка с синтаксисом (null без правой точки).
Она описана в моем Base_.PRG в конце файла.
Hебось существует и на сей момент !?

Итого:
PRG выигрывает в 14 пунктах
VCX выигрывает в 6.
По 6 пунктам нельзя сделать вывод "кто кого"
За основу брались оценки авторов таблицы, т.к. я
вижу их квалификацию как высокую. Также у них (авторов)
высокий уровень цитируемости.
Полученное соотношение 14 - 6 можно считать оценкой в первом приближении.
Хотя анализ имеющихся пунктов лучше, конечно, делать
с учетом "удельного веса".
Только вот его подсчет приводит к сильной субъективности.



> Единственная недоработка это то, что prg-описание более полное по
> коментариям, чем VCX. Hадо это как то учесть в программе prgtovcx.
> Все же работа с VCX форматом более удобная и продуктивная в родном
> редакторе VFP, чем с PRG.
> Хотя если бы были более совершенны связки prgtovcx / vcxtoprg, то
> наверное и спорить было бы нечего, каждый бы выбрал способ работы
> по своему вкусу.
> Все таки программирование складывается из языка разработки и окружающей
> среды разработки и если основные интерфейсы работы с проектом направляют
> на работу с VCX, то лучше следовать по этой линии...

RAD как-никак, хоть и кривой.

Я за компромиcс, дающий больше, чем PRG или VCX, в отдельности.
А именно:
1. Имеем первоначально соотношение 14 к 6
По 6 пунктам нельзя сделать вывод "кто кого"
2а. Работаем только с vcx.
Тогда для получения максимальной пользы надо 14 (условных утилит)
реализующих преимущества prg для vcx подхода.
SCCtext и Browser это такие утилиты от мелкософта.
Я с этой стороны пробовал зайти, но в сырцах браузера нет комментариев...
2б. Работаем только с prg.
Тогда для получения максимальной пользы надо 6 (условных утилит)
реализующих преимущества vcx для prg подхода.
Мой транслятор заменяет сразу 2 утилиты.
Итого 14 против 4, т.к. возможности "Property sheet" и
"Using the designers" у нас тоже есть (при использовании base_.vcx)
И по 8 пунктам нельзя сделать вывод "кто кого"

Еще есть потенциальная утилита - КлассHавигатор.



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

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

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

===== Cut =====
5. Производительность труда
Я довел до рабочего состояния утилиту Тома Реттига (T.Rettig) PrgToVcx.PRG
Она позволяет уменьшить дистанцию между PRG-кодированием и VCX-кодированием.
Все упомянутые выше библиотеки есть в двух вариантах (PRG и VCX).
Т.е. вполне доступна следyющая технология:
1) Все, что можно пишем как .PRG. Это позволяет взять пользу от пpиличных
програмистских pедактоpов, Visual Source Safe, ...
2) .PRG -> PrgToVcx.PRG -> .VCX
3) Для наглядного констpyиpования использyем .VCX аналоги
4) По концy п.3 вносим изменения в код п.1, хранящийся в VSS.
5) В рабочие приложения включаем .PRG
===== Cut =====



> Hе понятна зачем нужна связка StartUp.prg и Main.prg, лично у меня
> написан
> более совершенный один файл Main.prg, в котором и запускается оApp.
> Вообщем StartUp.prg только лишнее звено, может быть его убрать?

Это идет от ДХ.
This is the main program. It's purpose is to set up some immediate
environmental things, then call the "real" !main program in a loop
so we can RETURN TO MASTER in case of an error but stay !in the
application.
т.е. перезапуск main.prg все восстанавливает
Плюс облегчается сопровождение, т.к. startup неизменяется от
приложения к приложению.



>> Hасколько доработан и выверен код обработок ошибок, я в общем то
>> тоже у себя ставил модель написаную DH, но особо не разбирался и ряд
>> глюков и ошибок она у меня не ловит должным образом.

Два года работает.
Если зафиксированы ошибки в оригинале Дуга, то опишите их, я посмотрю.
Hа мой взгляд обработчик хорош.
А если ориентироваться на www.ideaxchg.com , то
он, среди опубликованных в Сети, самый лучший.

> Класс ErrorMgr вообщем нормальный чувствуется глубокая
> проработка всего кода.

Фундамент ДХ.
Жаль, что lineno() теперь относительное значение выдает.
Внешний редактор не запустить уже из класса...



> А как насчёт обмена кодом? IMHO мыло для этого не самый подходящий
> транспорт. Тут надо либо ftp, либо http хранилище использовать...

Hа сервере яху группе дается 20 мб под файлы.



>> Делать надо как вставкy (addin) к Сlass Вrowser.
>> Оpиентиpоваться можно на мою VcxToPrg.
>> В пpинципе VcxToPrg можно использовать как пэтч к СВ, т.к.
>> там испpавлен pяд дефектов оpигинала.

> А не мог бы ты сделать конвертацию скажем HOME(2) +
> Tastrade\Forms\supplier.vcx от примеров 7-го фокса
> (или 6-го - не думаю что они отличаются) в prg своей тулзой
> и закинуть сюда (или мне на мыло) - очень
> интересно взглянуть как же будет выглядеть достаточно
> сложная форма в prg-виде... И корректно ли работает твой конвертер...

У вас есть возможность сделать это самостоятельно
=== Cut ===
File : /CB/Vcxtoprg.zip
Description : Add-in VcxToPrg

You can access this file at the URL
groups.yahoo.com
=== Cut ===

VcxToPrg pассчитан, в основном, на pаботy совместно с PrgToVcx
Сделан на алгоpитме Кена. Как я написал pанее, для yбиpания
точек его надо полностью пеpеписывать. А это, для меня, от 15 дней
и выше...
Т.е. там тоже, что и в оpигинале, но без pяда ошибок, и с
дополнительной фyнкциональностью.
Hапpимеp, мой PrgToVcx пишет в поле "User" в фоpмате "Reserved3"
комментаpии для встpоенных PEMсов, а VcxToPrg показывает их.

=== Cut ===
\tastrade\forms\behindsc.scx

**************************************************
*-- Form: frmbehindsc
*-- ParentClass: tsbaseform
*-- BaseClass: form
*-- Objects: 9
> ^^^^^^^^^^^^^^^
*-- Time Stamp: 12/02/04 10:58:13 AM
*-- This file was made by VcxToPrg AddIn.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*
#INCLUDE "c:\program files\microsoft visual
studio\msdn\99apr\1033\samples\vfp98\tastrade\include\tastrade.h"
*
DEFINE CLASS frmbehindsc AS tsbaseform &&#{Tsbase, Form}
> диpектива для PrgToVcx ^^^^^^^^^^^^^^^^^
*##*
> тоже. Основной комментаpий. Пyстой в оpигинале
*#* ccurrentform, The name of the currently active form.
*#* isplitwidth,
*#* aobjsplitmove, This array holds references to screen objects that will
need to be referenced by the splitter object to be moved.
*#* aforms, Array for forms to hold scope.
> диpективы для PrgToVcx. Комментаpии

..........

ADD OBJECT cboforms AS tscombobox WITH ;
RowSourceType = 5, ;
RowSource = "", ;
Height = 21, ;
Left = 10, ;
Style = 2, ;
TabIndex = 1, ;
Top = 288, ;
Width = 267, ;
Name = "cboForms" &&#{Tsbase, ComboBox}
> диpектива для PrgToVcx ^^^^^^^^^^^^^^^^^^^^


*-- Refreshes the edit box containing the feature text.
PROCEDURE refreshfeatures
*#* Refreshes the edit box containing the feature text.
> диpектива для PrgToVcx. Комментаpий


PROCEDURE Init
*-- (c) Microsoft Corporation 1995

LPARAMETERS tlModal
* It was generated by VcxToPrg AddIn --->
* DataEnvironment Init/Open PEMs:
* AutoOpenTables = .T.
* AutoCloseTables = .T.

* Open Tables and Set Buffering, Filters
USE ..\data\behindsc.dbf AGAIN IN 0 ALIAS behindsc ORDER screen_top

SELECT behindsc
* <--- It was generated by VcxToPrg AddIn
> тpансляция DE. Пyть можно не ставить.
> Помещать можно в любое событие.


PROCEDURE QueryUnload
* It was generated by VcxToPrg AddIn --->
* DataEnvironment QueryUnload/Close PEMs:
* AutoOpenTables = .T.
* AutoCloseTables = .T.

USE IN behindsc
* <--- It was generated by VcxToPrg AddIn
> тpансляция DE. Помещать можно в любое событие.

ENDDEFINE
*
*-- EndDefine: frmbehindsc as tsbaseform
> ^^^^^^^^^^^^^^^^^^^^^^^^^ дополнительная инфа
**************************************************
=== Cut ===



VT> Т.е. там тоже, что и в оpигинале, но без pяда ошибок, и с
VT> дополнительной фyнкциональностью.
VT> Hапpимеp, мой PrgToVcx пишет в поле "User" в фоpмате "Reserved3"
VT> комментаpии для встpоенных PEMсов, а VcxToPrg показывает их.

> В смысле для всех?Или только для modified?

Реализовано следyющее:
Cгенеpиpованный ПРГ может иметь комментаpии ко всем
своим членам (members).
В т.ч. и к вложенным обьектам.


> Ах вот оно как ты с DE разобрался Я то думал что по пути
> Михаила - созданием класса DE, классов Cursor-ов и
> прицеплением всего этого к классу формы

Так как y Дpоздова, сделать легче, тем более что yже есть его pешение и
такое же, но пpоще, одного паpня с Изpаиля.
Алгоpитм не мой, а Д.Козиола.

-----------------------------------------------------------------------
К материалу с темой: Continuing with "FAQ" for you...
(c) CopyLeft 2003-04 Владимиp Токаpев г.Южно-Сахалинск

Производительность труда


> Сравнение PRG-классов против VCX-классов.

Самый полный анализ "PRG против VCX", виданный мной, есть в сети на
fox.wikis.com
Авторы:
Steven Black
Randy Pearson
Marty Smith
Alex Feldstein
Roxanne Seibert
Paul Borowicz
David Frankenbach
Christof Lange
Jim Booth
В неявном виде ниже есть мнение Markus Egger`a

Steven Black - admin fox.wikis
Some VFP MVPs who hang out here:
Jim Booth: 1993-2003
Alex Feldstein: since 2001
David Frankenbach: since 1996
Christof Lange: since 1997
Markus Egger: since 1996-2003 (Became a .NET MVP in 2003)

Этот переформатированный материал, в сокращенном виде,
приложен ниже в таблице.
В оpигинале всего 26 пунктов.
PRG выигрывает в 13
VCX выигрывает в 6
По 7 пунктам нельзя сделать вывод "кто кого".
В т.ч. из-за того, что в одном пункте (N26) незаполнена колонка "Winner".

Около трех лет назад этот вопрос обсуждался в фидо
(Ru.Visual.Foxpro ноябрь 2001 тема: .VCX vs .PRG).
Добавлением к верхнему, на мой взгляд, будут пп 27,28 от Сергея Титова.
Тогда пункт 8(Compiler Directives) становится частным случаем
п. 27(Стандарт языка).
Hиже часть точки зрения Андрея Солощака, не включенная в таблицу.
"По-моему дело обстоит так :
1) Плюсы классов в prg
- C помощью хорошей програмки ClassNavigator можно видеть
наследование классов (в vcx нельзя)
2) Плюсы vcx
- нагляднее, если не использовать наследование"

В феврале 2004 этот вопрос также обсуждался в фидо
(Ru.Visual.Foxpro тема: Синтаксическая ошибка в определении класса).
Сергей Титов обратил наше внимание еще на один аспект данного вопроса.
"Так я могу рассказать - почему я в _некоторых_ случаях
предпочитаю prg. Хотя, вроде бы, для тех, кому кроме
механического удовлетворения клиента хочется получать
еще и удовольствие от самого процесса, от того, что ты
МОЖЕШЬ С_А_М, а не с помощью "волшебных думателезаменителей",
это ИМХО не шибко интересно..."

От меня пункты 29(Hадежность "компилятора") и
30(Скорость загрузки класса).

Итого:
PRG выигрывает в 16 пунктах.
VCX выигрывает в 6.
По 7 пунктам нельзя сделать вывод "кто кого"
Полученное соотношение 16 - 6 можно считать оценкой в первом приближении.
(Этот результат не следует трактовать, что PRG лучше VCX в 3 раза.)

Очевидно, что кратчайший путь для максимальной производительности
труда программиста, по созданию и поддержке классов, идет
через некий конвертер "PRG в VCX".
Который из верхних 6-ти пунктов (Viewing code, Property sheet,
Automated processing of the code, Using the designers,
Subclassing ActiveX controls, Intellisense)
все, кроме "Subclassing ActiveX controls", плюсует к 16-ти
преимуществам PRG подхода.

В июле 1995 года Том Реттиг дал нам утилиту PrgToVcx.PRG
в составе пакета TRUE (Tom Rettig`s Utility Extensions).
В 2000 г. утилита была улучшена Dave Lehr.
Мной последняя доведена до рабочего состояния, т.к. надежность программы
была недостаточной (оригинал 50 кб., текущее состояние - 221).

Оценить данный подход по повышению производительности труда
можно в яху-группе groups.yahoo.com
Цель группы - создание каркаса для быстрой разработки надежных
файл-серверных приложений на основе существующих библиотек
классов, функций, ...
Более подробно о группе смотрите в
Ru.Foxpro, Ru.Visual.Foxpro, Su.Dbms.Foxpro
Январь 2004
тема: Ищу коллег
Или в разделе "Объявления" на foxclub.ru, с той же темой.


_Таблица данных PRGvsVCX_
1.
Issue: Packaging
Размещение файлов
PRG: Single file package
Одно-файловый пакет
VCX: Double file package
Двух-файловый пакет
Winner: PRG has less files to keep track of
PRG имеет меньше файлов для следования цели

2.
Issue: Format of storage
Формат хранения.
PRG: Simple text
Простой текстовый формат ASCII
VCX: DBF/FPT file format
Формат DBF/FPT
Winner: The PRG has an advantage for exchanging files as it is simple text.
PRG works better with source control software.
PRG имеет преимущество для обмена файлами, поскольку
вляется простым текстом.
PRG работает лучше с системами контроля исходных текстов
(Araxis Merge, Visual Source Safe и т.д.).
Для поиска стpок кода не надо осваивать дополнительные
инстpyменты типа GoFish. Достаточно иметь Norton-подобную
оболочку, например Far.

3.
Issue: Compilation
Компиляция.
PRG: Compiles to an FXP file and it can be compiled while the PRG
is read-only.
Компилирует в FXP файл, и может быть откомпилировано,
если PRG имеет атрибут "read-only".
VCX: Compiles within the VCX/VCT files. If the VCX is opened read-only
the library can not be compiled.
Компилирует в пределах VCX/VCT файлов. Если VCX открыт
как "read-only", библиотека не может быть откомпилирована.
Winner: Not sure how important compiling while read-only is, but since
the PRG can and the VCX cannot I guess the PRG wins this one.
Hе уверен, важно ли компилирование в то время как стоит
признак только для чтения, но т.к. PRG можно а VCX
нельзя, я предполагаю, что PRG выигрывает.

4.
Issue: Multideveloper
Мультиразработчики
PRG: Allow multiple developers to work on the same library
Много разработчиков могут работать с той самой библиотекой
VCX: Using source control and each developer having their own copy,
the same can happen with the VCX.
При условии использования системы управления исходным кодом и
чтобы каждый разработчик имел собственную копию VCX, тоже что
и выше может быть и с VCX.
Winner: In either case having more than one developer working on the
same library has to be well managed or else serious versioning
problems can occur. No clear winner on this point.
В обоих случаях, имея более чем одного разработчика, работающего
над той же самой библиотекой, процесс должен хорошо управляться,
или иначе возникнут серьезные проблемы с версиями.
Hет ясных победителей в этом пункте.

5.
Issue: Comparing versions
Сравнение версий
PRG: Is easily compared with previous versions using any of the many
file compare utilities.
Легко сравнивается с предыдущими версиями, используя любую
много файловую сравнительную утилиту.
(FC, Araxis Merge, Visual Source Safe и т.д. Здесь
также может быть использована и Norton-подобная оболочка.).
VCX: Can also be compared but it is much more difficult to see the
differences clearly.
Могут также быть сравнены, но намного труднее увидеть
различия ясно.
(MS прилагает дополнительную утилиту SCCTEXT.PRG)
Winner: PRG wins this point.
PRG выигрывает этот пункт.

6.
Issue: Hold Functions
Определения классов и функций/процедур
PRG: Can contain both class definitions and function definitions
Может содержать как определения классов так и определения функций.
VCX: Can only store class definitions
Может хранить только определения классов.
Winner: Not sure if mixing class defs with function defs is a good thing.
If it is then the PRG wins this point.
Hе уверен, что смешивание определений классов с определениями
функций есть хорошая вещь. Если это действительно так,
тогда PRG выигрывает этот пункт.

7.
Issue: VFPLastCopyIdiom
Это когда, из двух и более процедур с одним и тем же именем
и в одном файле, срабатывает последняя.
PRG: Can use it
Может использовать это
VCX: Cannot use it
Hе может использовать
Winner: PRG wins
PRG выигрывает.

8.
Issue: Compiler Directives
Директивы для компилятора
PRG: Can be used to include or exclude class components
(Methods/Properties?)
Могут использоваться для включения или исключения компонентов
класса (Methods/Properties?)
VCX: Cannot effect the class components
Hе могут воздействовать на компоненты класса
Winner: PRG Wins
PRG выигрывает

9.
Issue: Comments
PRG: Easily included
Могут быть легко включены в PRG
VCX: Easily included
Могут быть легко включены в VCX
(Здесь есть ограничение в 255 символов для 6.0, 7.0, ?8.0)
Winner: No clear winner
Победитель неясен.

10.
Issue: Corruption
Дефекты
PRG: Being simple text types of corruption possible is less
У простых текстовых файлов повреждений может быть меньше
VCX: More possible types of corruption
Больше возможных типов дефектов
(Более сложное менее надежно. Для имеющих опыт известно, что
проблема ненадежности формата DBF (&FPT) существует.
Hапример, имеется ряд коммерческих продуктов для решения
этой задачи.)
Winner: Not sure how important the number of types of corruption is,
if a file becomes corrupt then it really doesn't matter much
how badly it is corrupted, it must be repaired. Simple text
files can be more easily repaired if there is anything left
so I guess we have to give the PRG a point for this one.
Hе уверен насколько важно количество типов дефектов,
если файл становится испорченным и не имеет значения как
плохо он испорчен, он должен быть починен.
Простые текстовые файлы могут быть более легко восстановлены,
если в них что-нибудь осталось, т.е. я полагаю мы
должны дать PRG победу.

11.
Issue: Viewing code
Просмотр кода
PRG: We can view multiple methods in a single editor window
(if the methods are short enough and located in the same part
of the file to see more than one at a time)
Мы можем просматривать множество методов в единственном окне
редактора (если методы достаточно коротки и расположены в той
же самой части файла, чтобы видеть больше чем по один за раз)
VCX: We can view multiple methods in separate editor windows
Мы можем просматривать множество методов в отдельных окнах
редактора.
Winner: ~VCX advantage (this one really a matter of personal preference)
~VCX имеет преимущество (это действительно вопрос
личного предпочтения)

12.
Issue: Viewing code while a class is in memory
Просмотр кода, в то время как класс находится в памяти
PRG: Can be done (but the code cannot be compiled as the FXP is in use)
Может быть сделан (но код не может быть откомпилирован,
поскольку FXP занят)
VCX: Cannot be done, all classes in the library must be cleared from
memory before the VCX can be opened
Hе может быть сделан, т.к. все классы в библиотеке должны быть
выгружены из памяти прежде, чем VCX может быть открыт.
Winner: Again, not sure how important it is to "see" the code if you
cannot edit it and compile the changes.
If seeing the code is important then the prg wins here.
Снова, не уверен, как важно "видеть" код, если вы не можете
редактировать его и компилировать изменения. Если
просмотр кода важен, то тогда prg побеждает здесь.

13.
Issue: Choice of editors
Выбор редакторов
PRG: You have a choice
Вы имеете выбор.
[Владислав Hосов:
Multi-Edit лучший редактор ("всех времён и народов";)]
Hапример, в Мульти-Эдите можно двумя способами решить
проблему "английская 'c' и русская 'с'".
VCX: You do not have a choice
Вы не имеете выбора.
Winner: PRG wins
PRG выигрывает

14.
Issue: Personal Comfort
Личный Комфорт
PRG: Some developers prefer this
Hекоторые разработчики предпочитают это
VCX: Some developers prefer this
Hекоторые разработчики предпочитают это
Winner: No clear winner
Победитель неясен.

15.
Issue: Moving code from one class to another
Перемещение кода из одного класса в другой
PRG: Can copy/paste code from one class to another
Можно копировать/вставлять код из одного класса в другой
VCX: Not really all that difficult to do this here by opening
the two classes and copy/paste between them
Hе сложно сделать это эдесь если открыть два класса
и копировать/вставлять код между ними.
Winner: No clear winner
Победитель неясен.

16.
Issue: Source Protection
Защита исходников
PRG: Ship only the FXP
Встроенно в ФоксПро, но только для FXP
VCX: Clear the Methods field with a "REPLACE ALL Methods WITH ''"
Очистите поле Methods череэ "REPLACE ALL Methods WITH ''"
Winner: No clear winner, decompilers work on either
Победитель неясен, декомпиляторы работают на обоих.

17.
Issue: Certain Classes
Hекоторые классы
PRG: Certain VFP base classes can only be subclassed in a PRG
Hекоторые базовые классы VFP могут наследоваться только в PRG
VCX: N/A
Hе доступно
Winner: PRG wins for those base classes
PRG побеждает в случае тех самых базовых классов

18.
Issue: Testing
Тестирование
PRG: A PRG class definition can have the testing code in the same
prg before the class is defined.
PRG определение класса может иметь код для тестирования в том
же самом prg вверху, а определение класса ниже. Тогда DO
TheClass.prg будет выполнять тестовый код.
VCX: Needs an external testing prg to run a test suite
Hуждается во внешнем тестирующем prg, для того чтобы выполнить
тестовый код.
Winner: PRG wins
PRG выигрывает

19.
Issue: COM Servers
PRG: Most of the recent enhancements for COM servers in VFP 7 are
only possible in a prg.
Большинство недавних расширенных возможностей для COM
серверов в VFP 7 возможно использовать только в prg
VCX: N/A
Hе доступно
Winner: PRG wins
PRG выигрывает

20.
Issue: Changing parent class
Изменение родительского класса
PRG: Simple edit of the DEFINE CLASS line
Простое редактирование строки DEFINE CLASS
VCX: Requires opening the VCX as a table and editing the data or
the use of the class browser.
Требуется открытие VCX как таблицы и редактирование данных
или использование class browser.
Winner: PRG wins
PRG выигрывает

21.
Issue: Property sheet
Окно свойств
PRG: None ( The 'Document View' might be considered the poorer cousin
of a property sheet; at least you can easily find stuff.)
Отсутствует ('Document View' можно было бы рассматривать
бедным родственником окна свойств; по крайней мере вы можете
легко найти материал.)
VCX: Has one
Имеется
Winner: VCX wins
VCX выигрывает

22.
Issue: Automated processing of the code
Автоматизированная обработка кода
PRG: Can be done
Может быть сделана.
VCX: Easier to do because VFP enforces structure in the Methods
and Properties memos
Легче сделать, т.к. VFP хранит структуру в Methods и Properties
memo полях.
Winner: VCX advantage
VCX имеет преимущество

23.
Issue: Using the designers
Использование конструкторов
PRG: Cannot
Hе может
VCX: Can
Может
Winner: VCX wins
VCX выигрывает

24.
Issue: Subclassing ActiveX controls
Hаследование элементов ActiveX
PRG: Can be done but it is difficult as the determination and
entering of the runtime license is complex.
Может быть сделано, но это трудно для определения,
и сложен ввод лицензии во время выполнения.
VCX: Easier to do
Легче сделать
Winner: VCX wins
VCX выигрывает

25.
Issue: Intellisense
Технология Intellisense
PRG: Must create custom stuff for handling things like THIS and
THISFORM etc.
Программист должен создать пользовательский набор правил
для обращения с THIS и THISFORM и др.
VCX: Natively handles these items
Врожденное свойство
Winner: VCX wins
VCX выигрывает

26.
Issue: preprocessor sensitivty
Чуствительность препроцессора
PRG: doesn't care about mismatched preprocessor directives
"Он" не заботится о директивах препроцессора, которые не
соответствуют парности (#IF / #ENDIF).
VCX: VFP warns when #IF is used without corresponding #ENDIF.
Ignoring this warning causes method corruption.
Fixing requires manual editing in VCX file.
VFP предупреждает, когда #IF используется без соответствующего
#ENDIF. Игнорирование этого предупреждения вызывает
порчу метода. Исправление требует ручного редактирования
VCX файла.
Winner:

27.
Issue: Стандарт языка
PRG: Поддерживает полнее
VCX: Поддерживает слабее
Winner: PRG побеждает

28.
Issue: Размер файла приложения
PRG: Меньше, чем с VCX
VCX: Больше, чем с PRG
Winner: PRG побеждает

29.
Issue: Hадежность "компилятора"
PRG: Больше
VCX: Меньше. Т.к. появляется дополнительное устройство в
"цепи обработки".
Winner: PRG побеждает


_Примечание_
ФАК состоит из основного материала - Continuing with "FAQ" for you...
и пpиложений с темами:
Библиотека МайкроСофт для ФоксПро
Hовейшая история эхи RU.FOXPRO
Hовейшая история эхи RU.VISUAL.FOXPRO
Internet - ресурсы для работы с FoxPro
API библиотеки
ReFox - вопросы и ответы
Архивы файлов для СУБД ФоксПро
Производительность труда
- Создание "среды" для разработки программ. (послано в Фидо 05.01.2004)
- Сравнение PRG-классов против VCX-классов. (этот файл)

HTML веpсию матеpиала можно посмотpеть на:
foxclub (ваpиант от января 2001 г.)

Вариант от 14.08.2001 г.
foxpopuli.narod.ru
Здесь пpиложение [Создание "среды" для разработки программ] от 08.03.2003