Ищу кoллег
Vladimir Tokarev
* в RU.FOXPRO
* в RU.VISUAL.FOXPRO
Группа для совместной работы в сфере 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
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 и серьезно повышает надежность
работы приложений.
Используется в событиях 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
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."
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
Заполнение анкеты является обязательным условием.
Можете также подробнее осветить свой профессиональный опыт в ФоксПро и
написать ваши предложения, но это по желанию.
(В адресах вместо двух скобок надо поставить @)
Vladimir Tokarev
* в RU.FOXPRO
* в RU.VISUAL.FOXPRO
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", виданный мной, есть в сети на
http://fox.wikis.com/wc.dll?Wiki~PRGvsVCX~VFP
Этот переформатированный материал приложен ниже в таблице.
В оpигинале всего 26 пунктов.
PRG выигрывает в 13
VCX выигрывает в 6
По 7 пунктам нельзя сделать вывод "кто кого".
В т.ч. из-за того, что в одном пункте (N26) незаполнена колонка "Winner".
Около двух лет назад этот вопрос обсуждался в фидо
(Ru.Visual.Foxpro ноябрь 2001 тема: .VCX vs .PRG).
Добавлением к верхнему, на мой взгляд, будут пп 27,28 от Сергея Титова.
Тогда пункт 8(Compiler Directives) становится частным случаем
п. 27(Стандарт языка).
От меня пункты 29(Hадежность "компилятора") и
30(Скорость загрузки класса).
Итого:
PRG выигрывает в 16 пунктах.
VCX выигрывает в 6.
По 7 пунктам нельзя сделать вывод "кто кого"
Полученное соотношение 16 - 6 можно считать оценкой в первом приближении.
Очевидно, что кратчайший путь для максимальной производительности
труда программиста, по созданию и поддержке классов, идет
через некий конвертер "PRG в VCX".
Который из верхних 6-ти пунктов (Viewing code, Property sheet,
Automated processing of the code, Using the designers,
Subclassing ActiveX controls, Intellisense)
все, кроме "Subclassing ActiveX controls", плюсует к 15-ти
преимуществам PRG подхода.
В июле 1995 года Том Реттиг дал нам утилиту PrgToVcx.PRG
в составе пакета TRUE (Tom Rettig`s Utility Extensions).
В 2000 г. утилита была улучшена Dave Lehr.
Мной последняя доведена до рабочего состояния, т.к. надежность программы
была недостаточной (оригинал 50 кб., текущее состояние - 221).
_Таблица данных PRGvsVCX_
1.
Issue: Packaging
PRG: Single file package
VCX: Double file package
Winner: PRG has less files to keep track of
2.
Issue: Format of storage
PRG: Simple text
VCX: DBF/FPT file format
Winner: The PRG has an advantage for exchanging files as it is simple text.
PRG works better with source control software.
Для поиска стpок кода не надо осваивать дополнительные
инстpyменты типа GoFish.
3.
Issue: Compilation
PRG: Compiles to an FXP file and it can be compiled while the PRG
is read-only.
VCX: Compiles within the VCX/VCT files. If the VCX is opened read-only
the library can not be compiled.
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.
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.
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.
5.
Issue: Comparing versions
PRG: Is easily compared with previous versions using any of the many
file compare utilities.
VCX: Can also be compared but it is much more difficult to see the
differences clearly.
Winner: PRG wins this point.
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.
7.
Issue: VFPLastCopyIdiom
PRG: Can use it
VCX: Cannot use it
Winner: PRG wins
8.
Issue: Compiler Directives
PRG: Can be used to include or exclude class components
(Methods/Properties?)
VCX: Cannot effect the class components
Winner: PRG Wins
9.
Issue: Comments
PRG: Easily included
VCX: Easily included
Winner: No clear winner
10.
Issue: Corruption
PRG: Being simple text types of corruption possible is less
VCX: More possible types of corruption
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.
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)
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)
VCX: Cannot be done, all classes in the library must be cleared from
memory before the VCX can be opened
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.
13.
Issue: Choice of editors
PRG: You have a choice
VCX: You do not have a choice
Winner: PRG wins
14.
Issue: Personal Comfort
PRG: Some developers prefer this
VCX: Some developers prefer this
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
Winner: No clear winner
16.
Issue: Source Protection
PRG: Ship only the FXP
VCX: Clear the Methods field with a "REPLACE ALL Methods WITH ''"
Winner: No clear winner, decompilers work on either
17.
Issue: Certain Classes
PRG: Certain VFP base classes can only be subclassed in a PRG
VCX: N/A
Winner: PRG wins for those base classes
18.
Issue: Testing
PRG: A PRG class definition can have the testing code in the same
prg before the class is defined.
VCX: Needs an external testing prg to run a test suite
Winner: PRG wins
19.
Issue: COM Servers
PRG: Most of the recent enhancements for COM servers in VFP 7 are
only possible in a prg.
VCX: N/A
Winner: PRG wins
20.
Issue: Changing parent class
PRG: Simple edit of the DEFINE CLASS line
VCX: Requires opening the VCX as a table and editing the data or
the use of the class browser.
Winner: PRG wins
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.)
VCX: Has one
Winner: VCX wins
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
Winner: VCX advantage
23.
Issue: Using the designers
PRG: Cannot
VCX: Can
Winner: VCX wins
24.
Issue: Subclassing ActiveX controls
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
25.
Issue: Intellisense
PRG: Must create custom stuff for handling things like THIS and
THISFORM etc.
VCX: Natively handles these items
Winner: VCX wins
26.
Issue: preprocessor sensitivty
PRG: doesn't care about mismatched preprocessor directives
VCX: VFP warns when #IF is used without corresponding #ENDIF.
Ignoring this warning causes method corruption.
Fixing requires manual editing in VCX file.
Winner:
27.
Issue: Стандарт языка
PRG: Поддерживает полнее
VCX: Поддерживает слабее
Winner: PRG побеждает
28.
Issue: Размер файла приложения
PRG: Меньше, чем с VCX
VCX: Больше, чем с PRG
Winner: PRG побеждает
29.
Issue: Hадежность "компилятора"
PRG: Больше
VCX: Меньше. Т.к. появляется дополнительное устройство в
"цепи обработки".
Winner: PRG побеждает
30.
Issue: Скорость загрузки класса
PRG: Больше
VCX: Меньше.
Winner: PRG побеждает
> Единственная недоработка это то, что prg-описание более полное по
> коментариям, чем VCX. Hадо это как то учесть в программе prgtovcx.
> Все же работа с VCX форматом более удобная и продуктивная в родном
> редакторе VFP, чем с PRG.
> Хотя если бы были более совершенны связки prgtovcx / vcxtoprg, то
> наверное и спорить было бы нечего, каждый бы выбрал способ работы
> по своему вкусу.
> Все таки программирование складывается из языка разработки и окружающей
> среды разработки и если основные интерфейсы работы с проектом направляют
> на работу с VCX, то лучше следовать по этой линии...
RAD как-никак, хоть и кривой.
Я за компромиcс, дающий больше, чем PRG или VCX, в отдельности.
А именно:
1. Имеем первоначально соотношение 16 к 6
По 7 пунктам нельзя сделать вывод "кто кого"
2а. Работаем только с vcx.
Тогда для получения максимальной пользы надо 16 (условных утилит)
реализующих преимущества prg для vcx подхода.
SCCtext и Browser это такие утилиты от мелкософта.
Я с этой стороны пробовал зайти, но в сырцах браузера нет комментариев...
2б. Работаем только с prg.
Тогда для получения максимальной пользы надо 6 (условных утилит)
реализующих преимущества vcx для prg подхода.
Мой транслятор заменяет сразу 2 утилиты.
Итого 16 против 4, т.к. возможности "Property sheet" и
"Using the designers" у нас тоже есть (при использовании base_.vcx)
Еще есть потенциальная утилита - Класс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а мой взгляд обработчик хорош.
А если ориентироваться на http://www.ideaxchg.com , то
он, среди опубликованных в Сети, самый лучший.
> Класс ErrorMgr вообщем нормальный чувствуется глубокая
> проработка всего кода.
Фундамент ДХ.
Жаль, что lineno() теперь относительное значение выдает.
Внешний редактор не запустить уже из класса...
> А как насчёт обмена кодом? IMHO мыло для этого не самый подходящий
> транспорт. Тут надо либо ftp, либо http хранилище использовать...
Hа сервере яху группе дается 20 мб под файлы.