alex11100форма scx - зло
Как обычно, сморозил глупость и в кусты. А отдуваться должен кто-то другой...

Александр, по всем Вашим пунктам я отвечать не буду. Вы все равно не читаете то что я пишу. Вернее, читаете отдельные слова, а потом обвиняете меня в том, что сами же и придумали. Большая часть написанного здесь Вами - это Ваши же собственные фантазии или полное игнорирование моих ответов.

Для примера, почитайте ту ветку на которую Вы сами же и дали ссылку. Я объяснил в чем там проблема и никакого нарушения последовательности срабатывания событий НЕТ! Вы же просто проигнорировали не устраивающий Вас ответ.

Какой смысл о чем-то спорить с человеком, который просто игнорирует любые аргументы? Вы хоть на один мой аргумент ответили?

Поэтому, я по прежнему утверждаю, Вы просто не понимаете то, о чем (и на чем) пишете! Вы механически используете команды и функции не пытаясь даже как-то понять, а как они функционируют. Поэтому, постоянно налетаете на самые разнообразные "грабли", но обвиняете в этом почему-то не свое непонимание, а "злонамеренность" разработчиков FoxPro.

alex11100за 13 лет в фоксе.
К сожалению, это ни о чем не говорит. Возвраст - это количество прожитых лет, а не объем знаний.

alex11100я вижу преимущества scx и преимущества vcx
я вижу преимущества prg и преимущества ...
Это как раз то, что я от Вас так долго и разными способами добиваюсь. АРГУМЕНТИРУЙТЕ свои выводы. Поскольку Вы НИКОГДА этого не делает, я делаю вывод - Вы НЕ ПОНИМАЕТЕ о чем говорите.

alex11100прг и ду форм уже проели давно, уже все понятно и давно.
Кроме Вас, вероятно. Единственный вывод который можно сделать, что у обоих способов есть достоинства и недостатки. Говорить, что один из них плохой, а другой хороший можно только в рамках конкретной даже не задачи, а идеологии. Но никак "вообще". Практически любую задачу можно решить как через VCX, так и через SCX. За редким исключением в очень специфических случаях.

alex11100Вы думаете я не знаю последовательности взлета формы???
Да. Не знаете!

В этом меня убеждает игнорирование ответа в приведенной Вами же ссылке. Точнее, Вы НЕ ХОТИТЕ в этом разбираться!

alex11100Вам пытаются объяснить преимущества класса,
Вы городите одно и то-же про...
Вы опять приписываете мне свое собственное поведение. Это как раз Вы напрочь игнорируете любое мнение отличное от Вашего.

Я все время пытаюсь ОБЪЯСНИТЬ, а Вы все время пытаетесь НАВЯЗАТЬ.

Кроме того, я все никак не могу понять, из чего Вы сделали вывод, что я против ООП вообще и против классов в частности? Только из того, что я показываю ДРУГОЙ способ решения? И ОБЪЯСНЯЮ, почему в данном кокретном случае этот ДРУГОЙ способ будет проще?

Александр, я уже неоднократно Вам говорил, что Вы просто НЕ ЧИТАЕТЕ даже те посты, ссылки на которые Вы сами же и приводите. Если бы Вы хотя бы попытались ПОНЯТЬ о чем там говорилось имело бы смысл продолжать с Вами диалог.

Проблемы с масштабированием? Я приводил аргумент, что если SCX - это back-end VCX, то проблемы с масштабированием либо нет вообще, либо они сопоставимы по сложности с чистым VCX. Вы, как обычно, это гордо проигнорировали!

Про кусты:

Это значит я к месту и не к месту подписываю специально выделенным шрифтом "ХХХ-зло" никак это не обосновывая? Ну и что можно ответить на высказывание: ХХХ - зло? Только "сам дурак!" поскольку никакого другого ответа Вы просто не понимаете!

И, кстати, Вы по прежнему НИЧЕГО не ответили на мои возражения против тех тезисов, которые лично Вам кажутся аргументами "против" SCX и "за" VCX. НИ РАЗУ! Вы все время скатываетесь к банальной ругани. Поэтому, "про кусты" - это опять про Вас!

И, кстати, с чего началось в данной теме?

alex11100- проблема подъема формы, лежащей в одном апп из другого
Имеет решение. Самие же знаете.

alex11100- проблема с необходимостью блокирования методов на взлете
Смотря каких и в каких ситуациях. В любом случае проблема решаемая. Сами же знаете.

alex11100- проблема с методом Show у мод.форм при наличии на форме активиксов
Это Вы про классы? При использовании DO FROM использовать метод Show() смысла не имеет. Впрочем, проблема ActiveX на модальных формах есть. Но она также решаема. Сами же знаете.

alex11100- избыточный ДЕ при наличии своих дата-классов
А это Вы про что? Базовые классы FoxPro тоже имеют кучу "избыточных" методов и свойств. Возражение не уместно...

alex11100- невозможно пронаследовать
А зачем?

Вообще-то, все предыдущие возражения - детский лепет. Уровня: это сложно решить через SCX, значит его мы использовать не будем никогда и ни при каких условиях. Заметьте, речь не идет о том, что нечто невозможно решить в принципе. Речь идет о том, что чуть сложнее. Чаще всего именно "чуть", причем в очень специфических ситуациях. Можно накидать аналогичных "возражений" по поводу классов, но особого смысла это не имеет.

Собственно, единственный камень преткновения, вокруг которого все и крутится - это проблема наследования. От SCX нельзя породить наследников.

Но! Очень большое "но"! Никто даже не пытается обосновать зачем? Когда реально возникает необходимость наследования от конечной формы?

Ну, предположим, сделали форму на базе класса. Она конечная. Когда теоретически может возникнуть необходимость в отлаженном и работающем приложении породить наследника от этой конечной формы? А теперь прикиньте пути решения этой проблемы? При использовании VCX и SCX уровень сложности будет сопоставим. Принципиальной разницы нет.

По моему, самое время вернуться к началу. Т.е. ответить на вопрос, а чем собственно формы отличаются от классов? Не по способу реализации, а по сути.

Что такое "класс"? Вы когда-нибудь делали дубликаты ключей от квартиры? Мастер находит у себя некоторую заготовку максимально близкую по форме к Вашему ключу. А потом происходит "доработака напильником по месту".

На основании одной и той же заготовки можно сделать много разных ключей от разных замков.

Так вот, эта самая "заготовка ключа" и есть "класс", а готовый результат (ключ) - "форма".

В чем принципиальная разница "заготовки" и "ключа"? В том, что в идеологии FoxPro у класса не должно быть явной привязки к данным. Другими словами все свойства вроде TextBox.ControlSource в собственно классе остаются пустыми. Не заполненными.

Как только Вы явно указываете значение ControlSource, т.е. осуществляете привязку к данным, Вы создаете "форму". Как бы и где бы она физически ни хранилась. Хоть в файле VCX, хоть в PRG, хоть в SCX.

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

Ну, представьте себе, что мастер уже начал точить для кого-то ключ из заготовки. Даже если он не закончил этот процесс и прервался на середине, много ли у него шансов встретить клиента, которому подойдет уже частично сделанный ключ? Скорее всего - мало. Либо надо будет закончить ключ для того, для кого начал, либо просто выбросить эту заготовку.

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

Собственно, есть два принципиальных способа это осуществить:

Во-первых, заняться программированием и написать программный код, который осуществлял бы нужную привязку в момент создания из класса собственно формы. Именно по такому пути вынуждены двигаться приверженцы "чистого" VCX или PRG.

Во-вторых, можно воспользоваться специальным "дизайнером", который называется "форма" и который сохраняет результат своей работы в файле SCX.

Другими словами, файл SCX - это просто дизайнер, позволяющий визуальными средствами осуществить привязку объектов в предварительно созданных классах к конкретным данным (таблицам).

В свете всего сказанного, вызывает недоумение попытка выставить как недостаток файлов SCX то, что при определенных условиях необходимо дополнительное программирование. Ведь при использовании "чистого" VCX или PRG количество этого самого программирование изначально больше. Причем намного!


проблема с необходимостью блокирования методов на взлете

Поскольку, в идеологии FoxPro привязка к данным может быть осуществлена только и исключительно в собственно форме, но никак не в классе, то файл SCX рассматривается как объект, выполняющий некоторую "доработку напильником по месту" после того, как будет создан объект, на основе ранее описанного класса.

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

В частности, если Вы создали класс Grid с некоторыми фиксированными размерами (Height, Width), положили экземпляр этого класса на форму в файл SCX и изменили эти размеры, то при загрузке формы произойдет следующее:

-) Сначала будет сформирован объект Grid на основе класса "как есть". С указанныим в собственно классе свойствами высоты и ширины

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

Именно этим объясняется "нарушение" порядка событий при открытии формы. Это не нарушение. Это особенность работы.

Для класса, такого не наблюдается именно в силу того, что класс - это еще не сам объект. Это его "заготовка". Вот как класс описан, такая заготовка и есть. Со всеми указанными размерами.

alex11100 авторотлаженном и работающем приложении
чаще всего приложение приходится поддерживать и дорабатывать

авторКогда теоретически может возникнуть необходимость в отлаженном и работающем приложении породить наследника от этой конечной формы?
это когда Вам ТЗ на стол положили с описанием доработки
Хотим мы мол вот эдак, а тетя Валя хотела-бы, чтобы осталось как было.
Или: с 01.01.2007 вводятся новые форматы ... и т.д.

Александр, Вы вообще-то пробовали читать сообщение ДО КОНЦА прежде чем отвечать? И не надо выдергивать цитаты из контекста.

ВладимирМНу, предположим, сделали форму на базе класса. Она конечная. Когда теоретически может возникнуть необходимость в отлаженном и работающем приложении породить наследника от этой конечной формы? А теперь прикиньте пути решения этой проблемы? При использовании VCX и SCX уровень сложности будет сопоставим. Принципиальной разницы нет.
Вот прежде чем что-то критиковать, попробуйте ПОДУМАТЬ! Докажите, что во всех приведенных Вами случаях использование чистых VCX потребует меньше усилий при модификации приложения, чем использование SCX как конец иерархии VCX.

С моей точки зрения, в обоих случаях, затраты будут примерно одинаковые.