>ручками все-таки надежней -- нарисуй страницу в MS FrontPage и ручками, а потом сравни

оптимизатор - это уже человечий фактор. Я с html чиста поверхностно, но знаю, что есть валидные страницы и еще какие-то. И разница как рах в полноте описания и приближенности к стандартам. Что хорошо в VFP70 - так это то, что счас будет писАться код - не acti wind, а как ACTIVATE WINDOW. И когда работаешь в группе разработчиков, к разным почеркам приходится сгачала прикнуть...
ИМХО вс:е это одно и тоже, как воду в стУпе толочь ;) у _каждой_ задачи есть как минимум 2 способоа решения. Нужно просто грамотно выбрать решение. Чтоб и быстро, нормательно, и по существу.

>ручками все-таки надежней -- нарисуй страницу в MS FrontPage и ручками, а потом сравни

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

из теории вероятности, если слышал, даже специально заносят избыточность, чтоб результ был точным ;) Но это вс:е ерундистика - главное чтобы костыбчик сидел (с)

А меня в DE смущает вот какая вещь:

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

Класс по базе DE можно программно описать. Но как вы потом его присоединяете к форме, которая сама - уже не форма, а класс (DE по умолчанию там нету)? Могу предположить, что через ADD OBJECT при описании, но никогда не пробовал. Просветите, плз, если у кого есть опыт в этом деле...

По моему оптимальный вариант Форма как класс с Рrivate DataSession
Далее в открытие всех необходимых таблиц в данной сессии ручками,
После редактирования запись всех изменений в сессии (с транзакцией).
Кто не согласен?

Честно говоря, задевает, когда в ответах периодически проскальзывает - "не используй ДЕ - глючный". А в чем собственно? ИМХО, такие советы звучат примерно так: "не используй молоток - по пальцу можно долбануть". Можно и долбануть, можно и без гвоздей - дело хозяйское... Молоток то чем плох?ИМХО, для пытошных дел очччень даже
ДЕ - это ОДИН из инструментов, хочешь - используй, не хочешь - никто не заставляет, а советы надо аргументировать, тем более спорные... Вот и захотелось постоять за "униженных и оскорбленных"

Что такое, собственно, DataEnvironment. Это _КЛАСС_, имеющий определенную узкую функциональность - обеспечение открытия/закрытия таблиц с нужными параметрами и установка нужных отношений. Все. Больше ждать от него нечего (хотя и хотелось бы)...
Т.е. все, что он делает - заменяет несколько команд:
open data ...
use ... [alias ...] [order ...] [shared] [noupdate]
cursorsetprop(...)
set relation ....
на один единственный метод OpenTables. И НИЧЕГО БОЛЬШЕ!
Последствия от использования ДЕ - точно такие же, как и от рукописного кода...

Какие _только_ это дает преимущества:
1. Это класс - надеюсь, преимущества объектного программирования объяснять не надо.
2. Множество команд при открытии и закрытии таблиц сводятся к выполнение одного метода. Это может быть оччччень существенно по следующей причине: при возникновении некоего события (в винде или в фоксе или в используемом в проге ActiveXе - неважно) событие ставится в очередь и фокс запускает обработчик этого события _после_завершения_выполнения_строки_кода_, т.е. очередной команды. Это, конечно, управляется c помощью _vfp.autoyield, но надо еще не забыть его использовать Значит, при использовании серии "классических" команд обработчик события может запуститься в ситуации, когда часть таблиц будет еще не открыта (не закрыта, не установлены/сброшены релэйшены), т.е. среда данных будет находиться в каком-то промежуточном состоянии. Здесь, как мне кажется, возможные последствия тоже очевидны... Т.е. использование ДЕ при использовании ActiveXов и при написании СОМсерверов ПОВЫШАЕТ устойчивость проги!
3. Ну и наконец, ДЕ открывает таблицы немного быстрее - за счет того, что это одна команда и не надо интерпретировать несколько...

По способам использования.
"Визуальный" ДЕ.
ИМХО, это шедевр для любителей "мышового" кодирования - все на экране, можно сотворить работающую форму вообще без клавы - знай таскай себе поля на форму да запускай билдеры А ежели еще использовать DBC и для каждого поля таблицы задать заголовки и классы для отображения этого поля... Плюс controlsource'ы можно выбирать из списка...
Правда, для начинающих надо отметить следующее:
1. Пути к свободным таблицам и к базам (пути к таблицам, входящим в базу храняться в базе) жестко задаются при разработке. Значит, при переносе проги к пользователю надо будет их поправить на те, которые будут у пользователя. Сделать это можно изменив перед открытием таблиц свойства курсоров cursorsource (для свободных таблиц) и database (для таблиц, входящих в базу) на реальный путь к таблице/базе (вроде как еще есть способ определить пути через set path, но я им не пользовался, поэтому описывать его не буду). Каким образом и в какой момент можно установить настоящие пути:
- в событии ДЕ.beforeopentables
- в событии LOAD формы (предварительно установив в дизайнере свойство ДЕ.autoopentables в .F. и явно открыв командой ДЕ.opentables после установки правильных путей)
2. ДЕ создается ДО срабатывания самого первого события формы - LOADa (а уничтожается после последнего - UNLOAD). НО ПРИ ЭТОМ ДЕ СОЗДАЕТСЯ УЖЕ В СЕССИИ ФОРМЫ!
3. Псевдонимы таблиц (alias) в ДЕ автоматом будут одинаковыми для одной и той же таблицы в разных формах (или другой вариант - одна и та же форма в приложении может запуститься несколько раз). В случае, если форма использует глобальную сессию данных (по умолчанию), это может привести к конфликту.
Выходы:
- использовать частную сессию данных для формы. При этом (внимание на п.2!) некоторые установки SET будут изменены на некие установки по умолчанию. Их необходимо восстановить вручную там же, где указано в п.1.
- вручную поменять алиасы в дизайнере на уникальные для каждой формы
- в п.1 дополнительно изменить св-во alias каждого курсора на, допустим, значение sys(2015). Правда, при таком способе нельзя определять controlsource'ы в дизайнере - объекты при создании их не найдут - только вручную, допустим в Init формы...
4. Если у вас используется база данных и заданы связи ссылочной целостности, то при добавлении связанных таблиц в ДЕ фоксяра может "услужливо" подсунуть и связь... ВНИМАТЕЛЬНО проверьте - это может быть совсем не то, что вам ЗДЕСЬ требуется!
5. Свойства курсоров (за исключением order и filter) могут быть изменениы только при закрытых курсорах. Т.е. если надо в ДЕ подменить одну таблицу, надо выполнить closetables, при этом закроются _все_ курсоры, поменять cursorsource, выполнить opentables. Некоторые объекты оччччень не любят, когда у них пропадает controlsource...
6. При закрытии формы нельзя вручную закрывать таблицы - это сделает ДЕ. Если закрывая таблицы ДЕ увидит, что какой-то курсор уже закрыт - он ругнется... Но можно заставить ДЕ не закрывать таблицы - ДЕ.autoclosetables = .F.

Теперь о грустном. Как всегда, MS сказав "А", вместо "Б" выдавила из себя жалкое "Ы"...
ПОЧЕМУ дизайнер не отслеживает (не меняет у связанных контролов) изменение алиаса в ДЕ?
ПОЧЕМУ для ДЕ формы нельзя задать родительский класс?
ПОЧЕМУ в классе формы нельзя определить ДЕ?
Что значит следующее
o=crea("form")
o.addobject("de", "dataenvironment") && Object class is invalid for this container
Где ж ему еще быть "валидным" как не в форме?

"Рукотворный" ДЕ.
Вообще по жизни - шедевры делаются руками. Штампуются - серйиные образцы. Так что если нужен шедевр - можно пройтись штампом, а доводить до гениального уровня - всегда и только ручками
В качестве "ручного" инструмента ДЕ вполне заточен. ИМХО.
Из минусов - упомянутый addobject/ add object de as dataenvironment
Обходится так:
define class ff as form
de=.null.
proc load
this.de = createobject("dataenvironment")

Про индексы.
ДЕ использует только структурные индексы. ИМХО, и это правильно.
Порядок сортировки... ну, может и недоработка. А так никто и не мешает вручную там где надо подключать нужные индексы и устанавливать порядок сортировки - как я сказал выше - после opentables нет никакой разницы как были открыты таблицы: через ДЕ или через use...


PS. В процессе написания этого опуса ни один USE не пострадал

2 Sergey Titow

В продолжение темы плюсов и минусов...

Что вы думаете про то, что я описал в этой ветке Aijik 21-02-2002 13:56 ?
Я именно из-за этого в свое время отказался от DE

При попытке добавить его в описании класса с помощью:

ADD OBJECT dataenvironment1 as dataenvironment

получаю Object class is invalid for this container

> Что вы думаете про то, что я описал в этой ветке Aijik 21-02-2002 13:56 ?
> Я именно из-за этого в свое время отказался от DE
> При попытке добавить его в описании класса с помощью:
> ADD OBJECT dataenvironment1 as dataenvironment
> получаю Object class is invalid for this container

Не могу ничего сказать - самого это добивает Может это из-за упора MS на визуальные средства - у форм (не у классов форм, а у SCXов) ДЕ присутствует по умолчанию - может, чтобы где-то кто-то как-то не конфликтовал? С другой стороны, у ДЕ _вообще_ нет св-ва parent - т.е. для него _вообще_ не предусмотрено контейнера... Странно как-то это...
А с третьей стороны, createobject работает... Правда это получается независимый объект, но пока неудобств мне это не доставляло...

по сути в определения класса формы ДЕ не нужен. Чиста по определению. Т.к. создается _виртульность_, а не объект. И в этой виртуальности таблицы не нужны. К этому нужно просто отнестись как есть

Мое отношение к DE: вещь хорошая, но неполноценная. Хорошо, что можно мышкой раз-два и готово! Все остальное плохо((. Сам я мыкаюсь с DE уже лет 5, с тех самых пор, как перешел на VFP-3. И то, потому только, что наработаны уже десятки форм с DE и все переделывать облом. Я уже на эту тему высказался, выложив в решениях библиотеку классов, но заявка на дискуссию как-то осталась незамеченной. Поэтому повторюсь коротенько.
Про плюсы говорить особо нечего - кроме дизайнерских удобств ИМХО ничего (хотя и это, конечно, много).
Про минусы скажу то, что меня больше всего достает:
1.Нельзя создать класс-форму с привязанным к ней DE
2.Нельзя построить иерархию наследующих друг друга классов DE
3.Нельзя использовать вложенные друг в друга DE
4.Нельзя создавать пользовательский класс, производный от Cursor, и использовать его при создании DE.
5.Нельзя использовать DE в недиалоговых процедурах
6.Непонятно (мне, по-крайней мере), как использовать DE, если таблицы на SQL-сервере
Точнее так - пп.2-5 может быть и можно сделать в prg-модулях через define class, но при этом теряется все преимущества "мышиного" программирования. Кроме того, я сильно сомневаюсь, что Fox без проблем съест такое издевательство над его ОЧЕНЬ специальными классами DE и Cursor. В свете этого высказывание Сергея "Это класс - надеюсь, преимущества объектного программирования объяснять не надо" несколько тускнеет, поскольку от ООП здесь пока только название.
Поэтому вопрос "Использовать DE или нет?" я для себя формулирую так "Что использовать вместо DE?"
Использовать процедуры типа MyOpenFiles не хочется, т.к. прикипел к преимуществам ООП и возвращаться назад не хочется. Остается создать свои классы, аналогичные DE и Cursor, что я и сделал - см..
<A href="http://www.nsvisual.com/fox2/sol/index.php?act=view&id=216">сюда</A>
При наличии такой библиотеки программирование работы с таблицами могло бы выглядеть так:
1.Для каждой постоянной и временой таблицы и для всех представлений (локальных и удаленных), используемых в приложении, создаем класс, производный от Cursor. На этом же уровне определяем способ привязки к используемым в данном запуске программы базам.
2.Постоянно связанные между собой таблицы (например, бухгалтерский документ и список проводок к нему) объединяем в классы, производные от DataSet (аналог DE), с прописыванием сортировок, фильтров, связей и т.п.)
3.Для форм и недиалоговых процедур создаем объекты класса DataSet со нужным набором объектов Cursor и ранее определенных DataSet, определяя (переопределяя) в них сортировки, фильтры, связи, буферизацию и т.п.
Теперь вся мощь ООП у нас в руках: oDataSet.Open и все открылось, oDataSet.Update - все сохранили, oDataSet.Close - все закрыли. Если нужно определить какие-то специфические действия над таблицей при обработке стандартных событий, пожалуйста - можно на уровне класса-курсора, можно на уровне класса-набора данных, можно непосредственно в форме. При этом, все подробности и свойства таблиц приложения сосредоточены в одной библиотеке и могут быть использованы всюду в программе - и формах, и в prg-модулях.
В заключение еще раз предлагаю "всем кагалом накинуться на опухоль" и общими усилиями сделать приличную общедоступную библиотеку для этих целей.
Всем удачи!
ЗЫ.2 Hel!Riser
> по сути в определения класса формы ДЕ не нужен. Чиста по определению. Т.к. создается
>_виртульность_, а не объект. И в этой виртуальности таблицы не нужны. К этому нужно просто
> отнестись как есть
Не очень понятно, почему таблицы в "виртуальности" не нужны? Чем они хуже, всех других объектов формы? К тому же, замечу, что описание формы - это тоже описание класса, а никак не объект. Объект создается только когда мы делаем do form.