FoxClub Forums > Visual Foxpro, Foxpro for DOS > Вопрос по вызыванию формы из этой же формы ::

• Войти

Страницы: 1 2

Re: Вопрос по вызыванию формы из этой же формы
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 15.12.17 19:42:55 Taran Выбираю метод, далее опять подсказка по параметрам. Всё! Мне не надо елозить мышкой по экрану, выбирать в окне свойств HEADER чтобы задать Caption. Не надо прокручивать окно свойств до параметра WIDTH. И прочее. Ну да, ну да, метод с 26-ю параметрами (а если бы было можно то и больше было бы)... При том "совершенно логично" - рядом имя поля, заголовок, ширина, цвет и имя шрифта. чоужтам, всё "ясно как день" Taran Все это при наличии колонок доставляет хлопоты. По крайней мере порядок колонок. Почему у меня это никогда не вызывало абсолютно никаких проблем? При том что, к примеру, заголовки колонок вообще могут подтягиваться из метаданных (в простом случае - из Caption в таблице/представлении, в более сложном - из курсорадаптера с источником данных грида). Taran При желании внедрить метод в колонку она просто создается на основе конкретного класса, который также в PRG расписан. При том что для среднестатистического грида 2-3 колонки это ссылки на справочники, и для удобной работы (заполнение с контролем, вызов связанной формы) там нужно от 5 до 10 своих свойств, а лучше ещё и 2-3 метода (т.к. чисто свойствами сложно прописать все нюансы такого поля-типа-комбобокса)... Taran Просто когда это все работает - возвращаться к дизайну Grid нет никакого желания. Ну да, ну да. Делать визуальные вещи через код, без возможности даже примерно увидеть как это выглядит (без запуска на исполнение - что в общем случае довольно затратная операция) - это класс Да здравствует FPD без визуального редактора - @ SAY/GET "наше фсё" Taran Отчасти визуальная настройка Grid`а подобна использованию визардов в фоксе. Но мы же ими не пользуемся как только чуток заматереем. Не знаю как насчёт "визардов", а вот построители aka Builder-ы я использовал... Точнее я их ПИСАЛ, а потом уже разрабы прикладного решения это использовали - в частности для помещения контролов своих классов в тот же грид - и куча настроек там делалась в гриде построителя. Т.е. вместо интерфейса "редактора свойств", где колонка отдельно, хедер отдельно, текстбокс внутри тоже отдельно, плюс свойств куча (включая свои собственные) делаешь себе удобный интерфейс для их заполнения и всё - никаких проблем. Ну и да, курсоры с "динамически генерируемыми именами" - использовал КРАЙНЕ редко. Для гридов/форм/отчётов - короче любых целей отображения, попросту НИКОГДА. И что я делаю не так Если бы в MS считали что PDS это для "плагин какой, имеющий весьма отдаленное отношение к основной программе", то сделали бы изначально лишь класс Session, и тем и ограничили сферу использования приватных сессий. Однако они пошли совершенно по иному пути - введя сначала свойство в ФОРМУ, для создания в оной своей DS, и лишь спустя много лет, в 6.5-й версии, если мне не изменяет память, сделали отдельный объект Session - как раз "для плагинов" и прочего, имеющего весьма далёкое отношение к формам ввода. PDS это прежде всего инструмент для облегчения, структуризации, избавления от огромных куч мусора и неявных связей (по "общим курсорам") разных кусков кода друг с другом (в т.ч. и во время отладки) - и всё это для простых форм. Что проще - отладить форму с чистой, простой DS с 1-2-5-ю курсорами, и строго "своими" SET-ами, или форму работающую в окружении 500 курсоров, и при том что ЕЁ настройки (большинство SET-ов) могут быть абы кем и абы когда переключены (без её ведома и возможности хоть как-то на это повлиять). Я уж не говорю про транзакции (для родных dbf) которые ограничиваются как раз рамками сессии, текущей активной БД (если вдруг в программе используются несколько dbc) и прочими "мелочами". ------------------ WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

15.12.17 19:42:55

Taran
Выбираю метод, далее опять подсказка по параметрам. Всё!
Мне не надо елозить мышкой по экрану, выбирать в окне свойств HEADER чтобы задать Caption.
Не надо прокручивать окно свойств до параметра WIDTH. И прочее.

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

Taran
Все это при наличии колонок доставляет хлопоты. По крайней мере порядок колонок.

Почему у меня это никогда не вызывало абсолютно никаких проблем?
При том что, к примеру, заголовки колонок вообще могут подтягиваться из метаданных (в простом случае - из Caption в таблице/представлении, в более сложном - из курсорадаптера с источником данных грида).

Taran
При желании внедрить метод в колонку она просто создается на основе конкретного класса, который также в PRG расписан.

При том что для среднестатистического грида 2-3 колонки это ссылки на справочники, и для удобной работы (заполнение с контролем, вызов связанной формы) там нужно от 5 до 10 своих свойств, а лучше ещё и 2-3 метода (т.к. чисто свойствами сложно прописать все нюансы такого поля-типа-комбобокса)...

Taran
Просто когда это все работает - возвращаться к дизайну Grid нет никакого желания.

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

Да здравствует FPD без визуального редактора - @ SAY/GET "наше фсё"

Taran
Отчасти визуальная настройка Grid`а подобна использованию визардов в фоксе.
Но мы же ими не пользуемся как только чуток заматереем.

Не знаю как насчёт "визардов", а вот построители aka Builder-ы я использовал... Точнее я их ПИСАЛ, а потом уже разрабы прикладного решения это использовали - в частности для помещения контролов своих классов в тот же грид - и куча настроек там делалась в гриде построителя. Т.е. вместо интерфейса "редактора свойств", где колонка отдельно, хедер отдельно, текстбокс внутри тоже отдельно, плюс свойств куча (включая свои собственные) делаешь себе удобный интерфейс для их заполнения и всё - никаких проблем.

Ну и да, курсоры с "динамически генерируемыми именами" - использовал КРАЙНЕ редко. Для гридов/форм/отчётов - короче любых целей отображения, попросту НИКОГДА.
И что я делаю не так

Если бы в MS считали что PDS это для "плагин какой, имеющий весьма отдаленное отношение к основной программе", то сделали бы изначально лишь класс Session, и тем и ограничили сферу использования приватных сессий. Однако они пошли совершенно по иному пути - введя сначала свойство в ФОРМУ, для создания в оной своей DS, и лишь спустя много лет, в 6.5-й версии, если мне не изменяет память, сделали отдельный объект Session - как раз "для плагинов" и прочего, имеющего весьма далёкое отношение к формам ввода.
PDS это прежде всего инструмент для облегчения, структуризации, избавления от огромных куч мусора и неявных связей (по "общим курсорам") разных кусков кода друг с другом (в т.ч. и во время отладки) - и всё это для простых форм.
Что проще - отладить форму с чистой, простой DS с 1-2-5-ю курсорами, и строго "своими" SET-ами, или форму работающую в окружении 500 курсоров, и при том что ЕЁ настройки (большинство SET-ов) могут быть абы кем и абы когда переключены (без её ведома и возможности хоть как-то на это повлиять). Я уж не говорю про транзакции (для родных dbf) которые ограничиваются как раз рамками сессии, текущей активной БД (если вдруг в программе используются несколько dbc) и прочими "мелочами".

------------------
WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы
Taran Сообщений: 13624 Откуда: Красноярск Дата регистрации: 16.01.2008	Taran 15.12.17 20:34:18 Какой уж раз. Igor Korolyov Ну да, ну да, метод с 26-ю параметрами (а если бы было можно то и больше было бы)... При том "совершенно логично" - рядом имя поля, заголовок, ширина, цвет и имя шрифта. чоужтам, всё "ясно как день" Ну нет, конечно же нет. Не надо до абсурда доводить. Есть штук семь параметров более значимых и в той или иной мере обязательных. Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]". Также доступна конструкция вида with this.NewColumn(...) as Column .FontSize = .... endwith Igor Korolyov Taran Все это при наличии колонок доставляет хлопоты. По крайней мере порядок колонок. Почему у меня это никогда не вызывало абсолютно никаких проблем? Не помню точно, то ли при визуальной смене порядка или чего еще. Но есть определенные трудности. Igor Korolyov Taran При желании внедрить метод в колонку она просто создается на основе конкретного класса, который также в PRG расписан. При том что для среднестатистического грида 2-3 колонки это ссылки на справочники, и для удобной работы (заполнение с контролем, вызов связанной формы) там нужно от 5 до 10 своих свойств, а лучше ещё и 2-3 метода (т.к. чисто свойствами сложно прописать все нюансы такого поля-типа-комбобокса)... Колонка или что там еще типа ссылки на справочник знает, что она служит для связи со справочником. Эта колонка создана на основе определенного класса. И она и ее внутренности сумеют обработать все штатные ситуации. Igor Korolyov Taran Просто когда это все работает - возвращаться к дизайну Grid нет никакого желания. Ну да, ну да. Делать визуальные вещи через код, без возможности даже примерно увидеть как это выглядит (без запуска на исполнение - что в общем случае довольно затратная операция) - это класс Да здравствует FPD без визуального редактора - @ SAY/GET "наше фсё" Зачем мне видеть на экране? Я вижу это в голове. И. Как только начинаешь использовать контейнер в ячейке для отображения нескольких полей в одной колонке, то никакого "как вижу" не получится. Ни с данными, ни с таким же "HEADER" колонки, который также может состоять из нескольких строк и ячеек. (При этом используемый мной класс для заголовка комбинированной колонки может менять ширину ячеек и пр.) Про динамику развития VFP и роль MS - отдельный разговор. И они (MS) не всегда правы и последовательны. И... уровень абстракции или не знаю как по научному. У меня ни одна форма не может ни открыть данные, ни записать. Всё только через вышестоящий объект. форма получает имя курсора или нескольких и пр. исходные данные и занимается только отображением. Т.е. приватную сессию нужно делать до создания формы. Еще больше наверно рассмешу, если сознаюсь что и простейшие объекты у меня не имеют прописанного ControlSource. Все объекты находятся в контейнере, контейнер получает от формы имя курсора и инициализирует входящие контролы. А уж данные где. Без разницы. Решает вышестоящий объект. Таким образом переделка приложения на работу с нативными БД или серьезным сервером или даже с WEB не трогает форму. Где-то на самом верху меняется тип источника данных и подключается соответствующий класс оперирующий с тем или иным хранилищем. Ну не тема, просто не тема. Надоел ты мне, Игорь со своими PDS. ;)

Re: Вопрос по вызыванию формы из этой же формы

Taran

Сообщений: 13624
Откуда: Красноярск
Дата регистрации: 16.01.2008

Taran

15.12.17 20:34:18

Какой уж раз.

Igor Korolyov
Ну да, ну да, метод с 26-ю параметрами (а если бы было можно то и больше было бы)...
При том "совершенно логично" - рядом имя поля, заголовок, ширина, цвет и имя шрифта. чоужтам, всё "ясно как день"

Ну нет, конечно же нет. Не надо до абсурда доводить.
Есть штук семь параметров более значимых и в той или иной мере обязательных.
Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]".
Также доступна конструкция вида


with this.NewColumn(...) as Column
  .FontSize = ....
endwith

Igor Korolyov
Taran
Все это при наличии колонок доставляет хлопоты. По крайней мере порядок колонок.
Почему у меня это никогда не вызывало абсолютно никаких проблем?

Не помню точно, то ли при визуальной смене порядка или чего еще. Но есть определенные трудности.

Igor Korolyov
Taran
При желании внедрить метод в колонку она просто создается на основе конкретного класса, который также в PRG расписан.
При том что для среднестатистического грида 2-3 колонки это ссылки на справочники, и для удобной работы (заполнение с контролем, вызов связанной формы) там нужно от 5 до 10 своих свойств, а лучше ещё и 2-3 метода (т.к. чисто свойствами сложно прописать все нюансы такого поля-типа-комбобокса)...

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

Igor Korolyov
Taran
Просто когда это все работает - возвращаться к дизайну Grid нет никакого желания.
Ну да, ну да. Делать визуальные вещи через код, без возможности даже примерно увидеть как это выглядит (без запуска на исполнение - что в общем случае довольно затратная операция) - это класс Да здравствует FPD без визуального редактора - @ SAY/GET "наше фсё"

Зачем мне видеть на экране? Я вижу это в голове.
И. Как только начинаешь использовать контейнер в ячейке для отображения нескольких полей в одной колонке, то никакого "как вижу" не получится. Ни с данными, ни с таким же "HEADER" колонки, который также может состоять из нескольких строк и ячеек.
(При этом используемый мной класс для заголовка комбинированной колонки может менять ширину ячеек и пр.)

Про динамику развития VFP и роль MS - отдельный разговор. И они (MS) не всегда правы и последовательны.

И... уровень абстракции или не знаю как по научному.
У меня ни одна форма не может ни открыть данные, ни записать. Всё только через вышестоящий объект.
форма получает имя курсора или нескольких и пр. исходные данные и занимается только отображением.
Т.е. приватную сессию нужно делать до создания формы.

Еще больше наверно рассмешу, если сознаюсь что и простейшие объекты у меня не имеют прописанного ControlSource.
Все объекты находятся в контейнере, контейнер получает от формы имя курсора и инициализирует входящие контролы.
А уж данные где. Без разницы. Решает вышестоящий объект.
Таким образом переделка приложения на работу с нативными БД или серьезным сервером или даже с WEB не трогает форму.
Где-то на самом верху меняется тип источника данных и подключается соответствующий класс оперирующий с тем или иным хранилищем.

Ну не тема, просто не тема. Надоел ты мне, Игорь со своими PDS. ;)

Re: Вопрос по вызыванию формы из этой же формы
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 16.12.17 13:34:43 Taran Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]". Параметр "строка с перечислением свойств и значений" ещё большее гно чем просто 26 отдельных параметров. Taran* Также доступна конструкция вида with this.NewColumn(...) as Column И чем она лучше (или точнее отличается от) With This.col_name? Разницы абсолютно никакой. Taran Не помню точно, то ли при визуальной смене порядка или чего еще. Но есть определенные трудности. "Трудности" с тем что Column1, если уж так лень переименовывать колонки это совершенно не обязательно Column[1], и тем паче совсем не обязательно первая визуально колонка? Абсолютно надуманные трудности. Для тех случаев когда нужно найти именно "N-ю по текущему визуальному порядку" пишется простейший метод с перечислением всех колонок и проверкой ColumnOrder. Вся соль в том, что программное добавление колонки имеет РОВНО те же самые "проблемы" - только они возникнуть на шаг позже - когда юзер поменяет местами/перетащит твою программно созданную колонку. Taran Колонка или что там еще типа ссылки на справочник знает, что она служит для связи со справочником. Эта колонка создана на основе определенного класса. И она и ее внутренности сумеют обработать все штатные ситуации. ИМЕННО про это я и писал. Ты ВЫНУЖДАЕШЬ себя, или иного разработчика плодить 100500 мало полезных классов. Просто потому что не можешь позволить тривиально в визуальном редакторе задать пару-тройку методов или тех же свойств для того же текстбокса внутри колонки, или хедера - т.к. его у тебя попросту нет во время дизайна. Ключевое отличие vcx/scx от prg как раз и состоит в том, что vcx/scx позволяют "почти классы" описывать для глубоко вложенных объектов. Т.е. в одной по сути сущности будет описан и form и pagetfame с page и вложенный туда grid с column-ами, header-ами, textbox-ами... В prg-стиле придётся это явными отдельными классами описывать, что хоть и гибче (например можно добавить новый метод или статически добавить новое свойство к такому глубоко-запрятанному объекту, или просто колонки разных классов в грид поместить - хотя смысла в этом не очень много, решается другим способом), но и заметно многословнее, дольше в реализации, сложнее в отладке. Taran Зачем мне видеть на экране? Я вижу это в голове. Слабый аргумент. Ещё скажи что на бумажке нарисовал заранее, и потому всё делается "легко и приятно". Taran И. Как только начинаешь использовать контейнер в ячейке для отображения нескольких полей в одной колонке А зачем так делать? В общем случае контейнер или просто сложный/составной объект в ячейке грида работает плохо, и лучше так попросту не делать Т.е. это скорее исключение, чем правило. Taran ни с таким же "HEADER" колонки, который также может состоять из нескольких строк и ячеек. (При этом используемый мной класс для заголовка комбинированной колонки может менять ширину ячеек и пр.) Ну да, есть такая проблема фоксового грида - его заголовки очень бедны. Твой класс, впрочем, по сути "заголовком грида" НЕ является. Точно так же можно было бы сделать замену и самому гриду - динамически набрасывая нужное количество текстбоксов или иных контролов, реализуя свою прокрутку, свой метод для "визуально-одновременного" доступа к разным записям... Только так практически никто и никогда не делает - хотя это и решает 100 проблем грида, но добавляет свои 500 новых Taran И они (MS) не всегда правы и последовательны. Конечно. Только "бороться" с ними вместо того чтобы как-то приспособиться и просто эффективно работать - себе дороже. Пока ты будешь рисовать свой грид, свои страничные блоки, свои текстбоксы (ибо штатный просто ужасен, честно сказать), свою замену курсорам и тем же датасессиям, другой разработчик "примет правила игры" и напишет десяток прикладных программ. В этом и смысл фокса - писать быстро, и по возможности не тратить время на переработку штатного функционала. Если уж хочешь "всё сам" - то тот же C, или нынче C# ГОРАЗДО лучше будут - там "свободы" на порядок больше. Taran Т.е. приватную сессию нужно делать до создания формы. И это не проблема. И поменять порядок вызова (сначала форма, потом уже ИЗ неё - в рамках созданной PDS - класс работы с данными) не проблема. И просто SET DATASESSION для переключения в нужный момент тоже не проблема. Было бы желание разделить данные в курсорах, так же как разделяются методы и свойства объектов - когда никто "чужой" в них влезть не может помимо воли "хозяина". PDS на самом деле "костыль" позволяющий хоть как-то приблизить работу с "родными" для фокса сущностями (курсорами) к ООП - когда разные "объекты" изолированы друг от друга, а не варятся в одной огромной общей куче, с отделением чисто по "джентельментским соглашениям" - я не трогаю такие то свойства и методы, а они не трогают меня. Только такой подход НЕ работает. Даже при одном единственном разработчике, не говоря уж о команде. Обязательно где-то возникнет пересечение. Форма полезет не в свой курсор, или затронет общие настройки не вернув их назад (а она и не сможет это сделать, если, к примеру, вызывает другую форму). ------------------ WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

16.12.17 13:34:43

Taran
Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]".

Параметр "строка с перечислением свойств и значений" ещё большее г*но чем просто 26 отдельных параметров.

Taran
Также доступна конструкция вида
with this.NewColumn(...) as Column

И чем она лучше (или точнее отличается от) With This.col_name? Разницы абсолютно никакой.

Taran
Не помню точно, то ли при визуальной смене порядка или чего еще. Но есть определенные трудности.

"Трудности" с тем что Column1, если уж так лень переименовывать колонки это совершенно не обязательно Column[1], и тем паче совсем не обязательно первая визуально колонка?
Абсолютно надуманные трудности. Для тех случаев когда нужно найти именно "N-ю по текущему визуальному порядку" пишется простейший метод с перечислением всех колонок и проверкой ColumnOrder. Вся соль в том, что программное добавление колонки имеет РОВНО те же самые "проблемы" - только они возникнуть на шаг позже - когда юзер поменяет местами/перетащит твою программно созданную колонку.

Taran
Колонка или что там еще типа ссылки на справочник знает, что она служит для связи со справочником. Эта колонка создана на основе определенного класса. И она и ее внутренности сумеют обработать все штатные ситуации.

ИМЕННО про это я и писал. Ты ВЫНУЖДАЕШЬ себя, или иного разработчика плодить 100500 мало полезных классов. Просто потому что не можешь позволить тривиально в визуальном редакторе задать пару-тройку методов или тех же свойств для того же текстбокса внутри колонки, или хедера - т.к. его у тебя попросту нет во время дизайна.
Ключевое отличие vcx/scx от prg как раз и состоит в том, что vcx/scx позволяют "почти классы" описывать для глубоко вложенных объектов. Т.е. в одной по сути сущности будет описан и form и pagetfame с page и вложенный туда grid с column-ами, header-ами, textbox-ами... В prg-стиле придётся это явными отдельными классами описывать, что хоть и гибче (например можно добавить новый метод или статически добавить новое свойство к такому глубоко-запрятанному объекту, или просто колонки разных классов в грид поместить - хотя смысла в этом не очень много, решается другим способом), но и заметно многословнее, дольше в реализации, сложнее в отладке.

Taran
Зачем мне видеть на экране? Я вижу это в голове.

Слабый аргумент. Ещё скажи что на бумажке нарисовал заранее, и потому всё делается "легко и приятно".

Taran
И. Как только начинаешь использовать контейнер в ячейке для отображения нескольких полей в одной колонке

А зачем так делать? В общем случае контейнер или просто сложный/составной объект в ячейке грида работает плохо, и лучше так попросту не делать

Т.е. это скорее исключение, чем правило.

Taran
ни с таким же "HEADER" колонки, который также может состоять из нескольких строк и ячеек.
(При этом используемый мной класс для заголовка комбинированной колонки может менять ширину ячеек и пр.)

Ну да, есть такая проблема фоксового грида - его заголовки очень бедны. Твой класс, впрочем, по сути "заголовком грида" НЕ является.
Точно так же можно было бы сделать замену и самому гриду - динамически набрасывая нужное количество текстбоксов или иных контролов, реализуя свою прокрутку, свой метод для "визуально-одновременного" доступа к разным записям... Только так практически никто и никогда не делает - хотя это и решает 100 проблем грида, но добавляет свои 500 новых

Taran
И они (MS) не всегда правы и последовательны.

Конечно. Только "бороться" с ними вместо того чтобы как-то приспособиться и просто эффективно работать - себе дороже.
Пока ты будешь рисовать свой грид, свои страничные блоки, свои текстбоксы (ибо штатный просто ужасен, честно сказать), свою замену курсорам и тем же датасессиям, другой разработчик "примет правила игры" и напишет десяток прикладных программ. В этом и смысл фокса - писать быстро, и по возможности не тратить время на переработку штатного функционала. Если уж хочешь "всё сам" - то тот же C, или нынче C# ГОРАЗДО лучше будут - там "свободы" на порядок больше.

Taran
Т.е. приватную сессию нужно делать до создания формы.

И это не проблема. И поменять порядок вызова (сначала форма, потом уже ИЗ неё - в рамках созданной PDS - класс работы с данными) не проблема. И просто SET DATASESSION для переключения в нужный момент тоже не проблема.
Было бы желание разделить данные в курсорах, так же как разделяются методы и свойства объектов - когда никто "чужой" в них влезть не может помимо воли "хозяина".
PDS на самом деле "костыль" позволяющий хоть как-то приблизить работу с "родными" для фокса сущностями (курсорами) к ООП - когда разные "объекты" изолированы друг от друга, а не варятся в одной огромной общей куче, с отделением чисто по "джентельментским соглашениям" - я не трогаю такие то свойства и методы, а они не трогают меня. Только такой подход НЕ работает. Даже при одном единственном разработчике, не говоря уж о команде. Обязательно где-то возникнет пересечение. Форма полезет не в свой курсор, или затронет общие настройки не вернув их назад (а она и не сможет это сделать, если, к примеру, вызывает другую форму).

------------------
WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы
of63 Сообщений: 25254 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 16.12.17 16:56:26 Taran> Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]". ИК> Параметр "строка с перечислением свойств и значений" ещё большее гно чем просто 26 отдельных параметров. Дальше можно было и не читать, опять фекальная акцентуация... ...Параметр "строка с перечислением свойств и значений" ещё большее гно... А если ее в XML или JSON изложить - то это тоже г..но?

Re: Вопрос по вызыванию формы из этой же формы

of63

Сообщений: 25254
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

16.12.17 16:56:26

Taran> Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]".
ИК> Параметр "строка с перечислением свойств и значений" ещё большее г*но чем просто 26 отдельных параметров.
Дальше можно было и не читать, опять фекальная акцентуация...

...Параметр "строка с перечислением свойств и значений" ещё большее г*но... А если ее в XML или JSON изложить - то это тоже г..но?

Re: Вопрос по вызыванию формы из этой же формы
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 16.12.17 19:18:46 JSON, да и XML на самом деле это объекты. У первого нет жёсткой структуры (ну такой вот "гибкий" язык js), у второго - вполне себе может быть строгая структура (схема). Это УЖЕ не делает их "произвольной строкой с парами - свойство/значение". Но даже в этом случае - JSON, XML и прочие подобные средства решают конкретную задачу - передать кучу данных (обычно из объектного поддерева) через "границу" которая не пропускает сам объект (например из одного процесса в другой, а то и вообще с одной машины на другую, из программы написанной на одном языке в программу написанную на другом языке). Не будет никто в здравом уме использовать сериализацию и десериализацию для передачи "параметров", если их можно передать непосредственно. В конкретно этом примере колонка как объект доступна напрямую. Писать вместо 10 строк кода With this.col_some .Width=... .Font=... .Caption=... .ControlSource=... ... Нечто типа this.createcolumn("col_some", "Width=...,Font=...,Caption=...,ControlSource=...") Извращение в чистом виде. Заметь, автор подхода так и не делает - он выбрал для себя 5-8 каких-то ключевых свойств и оформил их отдельными параметрами. Ну да, так делают даже во всяких си - "конструктор с параметрами". Только речь то не про это изначально была! А про отказ от средств визуальной разработки (сначала для грида, потом вообще везде - т.к. чего уж останавливаться то на пол-пути). И так тоже делают - на том же си в принципе нет никакой "визуальной" разработки - кодят и кодят прогеры Но зачем делать это в фоксе, где визуальная, а главное "быстрая" разработка по сути единственный жирный плюс? ------------------ WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

16.12.17 19:18:46

JSON, да и XML на самом деле это объекты. У первого нет жёсткой структуры (ну такой вот "гибкий" язык js), у второго - вполне себе может быть строгая структура (схема). Это УЖЕ не делает их "произвольной строкой с парами - свойство/значение".
Но даже в этом случае - JSON, XML и прочие подобные средства решают конкретную задачу - передать кучу данных (обычно из объектного поддерева) через "границу" которая не пропускает сам объект (например из одного процесса в другой, а то и вообще с одной машины на другую, из программы написанной на одном языке в программу написанную на другом языке).
Не будет никто в здравом уме использовать сериализацию и десериализацию для передачи "параметров", если их можно передать непосредственно.
В конкретно этом примере колонка как объект доступна напрямую. Писать вместо 10 строк кода


With this.col_some
.Width=...
.Font=...
.Caption=...
.ControlSource=...
...

Нечто типа


this.createcolumn("col_some", "Width=...,Font=...,Caption=...,ControlSource=...")

Извращение в чистом виде.
Заметь, автор подхода так и не делает - он выбрал для себя 5-8 каких-то ключевых свойств и оформил их отдельными параметрами. Ну да, так делают даже во всяких си - "конструктор с параметрами". Только речь то не про это изначально была! А про отказ от средств визуальной разработки (сначала для грида, потом вообще везде - т.к. чего уж останавливаться то на пол-пути).
И так тоже делают - на том же си в принципе нет никакой "визуальной" разработки - кодят и кодят прогеры

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

------------------
WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы
of63 Сообщений: 25254 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 16.12.17 19:26:15 > Заметь, автор подхода так и не делает - он выбрал для себя 5-8 каких-то ключевых свойств и оформил их отдельными параметрами. не заметил... можно писать любое, типа параметре = значение как и в XML-е, что не хорошего?... > про отказ от средств визуальной разработки это другая тематика ... > Нечто типа this.createcolumn("col_some", "Width=...,Font=...,Caption=...,ControlSource=...") Извращение в чистом виде. Игорь... как писать проги то, кроме как не тем способом, которые ты там в своем уме предполагаешь

Re: Вопрос по вызыванию формы из этой же формы

of63

Сообщений: 25254
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

16.12.17 19:26:15

> Заметь, автор подхода так и не делает - он выбрал для себя 5-8 каких-то ключевых свойств и оформил их отдельными параметрами.
не заметил... можно писать любое, типа
параметре = значение
как и в XML-е, что не хорошего?...

> про отказ от средств визуальной разработки
это другая тематика

...
> Нечто типа
this.createcolumn("col_some", "Width=...,Font=...,Caption=...,ControlSource=...")
Извращение в чистом виде.

Игорь... как писать проги то, кроме как не тем способом, которые ты там в своем уме предполагаешь

Re: Вопрос по вызыванию формы из этой же формы
spinz Сообщений: 5263 Дата регистрации: 21.01.2016	spinz 16.12.17 21:16:16 of63 Игорь... как писать проги то, кроме как не тем способом, которые ты там в своем уме предполагаешь Ну это же риторический вопрос - по другому просто нельзя писать.

Re: Вопрос по вызыванию формы из этой же формы
of63 Сообщений: 25254 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 16.12.17 21:17:22 спс за расшифровку

Re: Вопрос по вызыванию формы из этой же формы
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 17.12.17 14:12:53 of63 не заметил... можно писать любое, типа параметре = значение Taran Типа .NewColumn('Дата', .RecordSource + '.Date', 80) Это потом, на вопрос что делать со свойствами не вошедшими в список параметров, было предложено такое извращение. of63 как и в XML-е, что не хорошего?... Лень объяснять, тем более что это бессмысленно, т.к. твой стиль кодирования я видел. "4R27d:YnL" в качестве параметра управляющего сразу 10-15-ю различными аспектами работы функции/метода (при том что на самом деле это должно было быть как минимум 5 РАЗНЫХ методов) - я это никогда не назову адекватным стилем. of63 Игорь... как писать проги то, кроме как не тем способом, которые ты там в своем уме предполагаешь Так как советует большинство известных/авторитетных/уважаемых в сообществе специалистов. Если твой стиль настолько уникален, что кроме тебя больше никто до такого не додумался, то это либо признак сверхгениальности (но тогда, скорее всего, его таки оценят), либо прямое указание на то что ты что-то делаешь не так... ------------------ WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

17.12.17 14:12:53

of63
не заметил... можно писать любое, типа
параметре = значение

Taran
Типа
.NewColumn('Дата', .RecordSource + '.Date', 80)

Это потом, на вопрос что делать со свойствами не вошедшими в список параметров, было предложено такое извращение.

of63
как и в XML-е, что не хорошего?...

Лень объяснять, тем более что это бессмысленно, т.к. твой стиль кодирования я видел. "4R27d:YnL" в качестве параметра управляющего сразу 10-15-ю различными аспектами работы функции/метода (при том что на самом деле это должно было быть как минимум 5 РАЗНЫХ методов) - я это никогда не назову адекватным стилем.

of63
Игорь... как писать проги то, кроме как не тем способом, которые ты там в своем уме предполагаешь

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

------------------
WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы
spinz Сообщений: 5263 Дата регистрации: 21.01.2016	spinz 17.12.17 14:26:20 Igor Korolyov т.к. твой стиль кодирования я видел. "4R27d:YnL" в качестве параметра управляющего сразу 10-15-ю различными аспектами работы функции/метода (при том что на самом деле это должно было быть как минимум 5 РАЗНЫХ методов) - я это никогда не назову адекватным стилем. Насчет 4R27d:YnL и 15 аспектов - это, надеюсь, была гипербола?

Re: Вопрос по вызыванию формы из этой же формы

spinz

Сообщений: 5263
Дата регистрации: 21.01.2016

spinz

17.12.17 14:26:20

Igor Korolyov
т.к. твой стиль кодирования я видел. "4R27d:YnL" в качестве параметра управляющего сразу 10-15-ю различными аспектами работы функции/метода (при том что на самом деле это должно было быть как минимум 5 РАЗНЫХ методов) - я это никогда не назову адекватным стилем.

Насчет 4R27d:YnL и 15 аспектов - это, надеюсь, была гипербола?

Re: Вопрос по вызыванию формы из этой же формы
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006	Simple777 17.12.17 14:29:40 Это больше похоже на клотоиду, кажись...

Re: Вопрос по вызыванию формы из этой же формы
spinz Сообщений: 5263 Дата регистрации: 21.01.2016	spinz 17.12.17 14:44:19 spinz на самом деле это должно было быть как минимум 5 РАЗНЫХ методов А смысл? Пусть функция на десяток тысяч строк читается не очень, зато нет лишних накладных расходов на вызов других функций. В идеале кроме функции main в программе не должно быть ничего. P.S. Подозреваю, что когда (псевдо)ИИ научится писать программы, они примерно так и будут выглядеть)) ИИ декомпозиция по сути не нужна, он же все равно не ошибается. Исправлено 1 раз(а). Последнее : spinz, 17.12.17 14:47

Re: Вопрос по вызыванию формы из этой же формы

spinz

Сообщений: 5263
Дата регистрации: 21.01.2016

spinz

17.12.17 14:44:19

spinz
на самом деле это должно было быть как минимум 5 РАЗНЫХ методов

А смысл?

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

В идеале кроме функции main в программе не должно быть ничего.

P.S.
Подозреваю, что когда (псевдо)ИИ научится писать программы, они примерно так и будут выглядеть))

ИИ декомпозиция по сути не нужна, он же все равно не ошибается.

Исправлено 1 раз(а). Последнее : spinz, 17.12.17 14:47

Re: Вопрос по вызыванию формы из этой же формы
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 17.12.17 14:57:27 spinz Пусть функция на десяток тысяч строк читается не очень, зато нет лишних накладных расходов на вызов других функций. В идеале кроме функции main в программе не должно быть ничего. При условии бесконечной памяти (и бесконечного терпения у "программиста" - ИИ как раз вполне подойдёт) вообще не нужно ни функций, ни ветвлений, ни циклов. Просто непрерывный поток вычислений И работать будет ну очень быстро Заодно можно будет на порядок упростить сами CPU - увеличить глубину конвейера, убрать хитрые кэши (простой "потоковый" только и нужен - по крайней мере для команд), выкинуть всякие предсказания переходов, да и переключения контекстов тоже... ------------------ WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

17.12.17 14:57:27

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

При условии бесконечной памяти (и бесконечного терпения у "программиста" - ИИ как раз вполне подойдёт) вообще не нужно ни функций, ни ветвлений, ни циклов. Просто непрерывный поток вычислений

И работать будет ну очень быстро

Заодно можно будет на порядок упростить сами CPU - увеличить глубину конвейера, убрать хитрые кэши (простой "потоковый" только и нужен - по крайней мере для команд), выкинуть всякие предсказания переходов, да и переключения контекстов тоже...

------------------
WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 17.12.17 15:28:07 spinz Насчет 4R27d:YnL и 15 аспектов - это, надеюсь, была гипербола? Да, но не очень далёкая от имеющегося положения дел... forum.foxclub.ru forum.foxclub.ru ------------------ WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы
of63 Сообщений: 25254 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 18.12.17 08:37:21 4R27d:YnL - точно не моё Мое вот, совсем другой слог: Часть текста скрыта Закрыть Исправлено 1 раз(а). Последнее : of63, 18.12.17 09:18

Re: Вопрос по вызыванию формы из этой же формы
Taran Сообщений: 13624 Откуда: Красноярск Дата регистрации: 16.01.2008	Taran 20.12.17 00:51:28 Igor Korolyov Taran Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]". Параметр "строка с перечислением свойств и значений" ещё большее г*но чем просто 26 отдельных Косячок, сударь. Не было в моем примере строки с перечислением свойств.

Re: Вопрос по вызыванию формы из этой же формы

Taran

Сообщений: 13624
Откуда: Красноярск
Дата регистрации: 16.01.2008

Taran

20.12.17 00:51:28

Igor Korolyov
Taran
Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]".
Параметр "строка с перечислением свойств и значений" ещё большее г*но чем просто 26 отдельных

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

Re: Вопрос по вызыванию формы из этой же формы
of63 Сообщений: 25254 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 20.12.17 01:07:15 Олег, вобще-то через запятую, у тебя перечисление, имя=значение...

Re: Вопрос по вызыванию формы из этой же формы
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 20.12.17 12:24:54 Taran Igor Korolyov Taran Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]". Параметр "строка с перечислением свойств и значений" ещё большее г*но чем просто 26 отдельных Косячок, сударь. Не было в моем примере строки с перечислением свойств. Ну да, были отдельные параметры со строками "свойство=значение", не одна строка... Как по мне, так разницы практически никакой, ну кроме того что возникнет ещё и вопрос с "26-ю параметрами" При том что вариант с With тоже был приведен, но он ну абсолютно не отличается от работы с "визуально" добавленными колонками. И тут имеет значение исключительно вопрос о том нужно или нет отказываться от визуального форм/класс дизайнера (полностью, или частично - что тоже отдельный вопрос). Я не отказывался. Более того, мастерил инструменты (builder) для более удобного нежели Property Window управления свойствами элементов в гриде... Единственное где я отказался от визуального задания свойств, так это в классах CursorAdapter. Изначально из-за ограничений 8-ки на размер строкового свойства (в дизайнере больше 255 символов в свойство было не прописать, тогда как программно - .SelectCmd = ... хоть 50 Кб запихивай), потом ещё и вопрос форматирования встал - одно дело красиво отформатированное или просто выровненное внутри TEXT ... ENDTEXT многострочное тело запроса (которое можно скопировать в те же утилиты работы с сервером, или из них и взять), или даже те же UpdatableNameList, и совсем другое "просто строка в свойстве". Хотя и тут, конечно, можно было бы извернуться через builder - не штатный, так допиленный под себя, или вообще альтернативный поискать... Но тут нарисовали ещё и генератор этих самых CAD-ов из старинных RemoteView - а генерировать всегда проще текст, нежели vcx класс. Так оно и осталось, без визуальщины ------------------ WBR, Igor

Re: Вопрос по вызыванию формы из этой же формы

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

20.12.17 12:24:54

Taran
Igor Korolyov
Taran
Остальные могут задаваться типа "FS=8", "DFS=[iif(..., 8,10)]".
Параметр "строка с перечислением свойств и значений" ещё большее г*но чем просто 26 отдельных
Косячок, сударь.
Не было в моем примере строки с перечислением свойств.

Ну да, были отдельные параметры со строками "свойство=значение", не одна строка... Как по мне, так разницы практически никакой, ну кроме того что возникнет ещё и вопрос с "26-ю параметрами"

При том что вариант с With тоже был приведен, но он ну абсолютно не отличается от работы с "визуально" добавленными колонками. И тут имеет значение исключительно вопрос о том нужно или нет отказываться от визуального форм/класс дизайнера (полностью, или частично - что тоже отдельный вопрос). Я не отказывался. Более того, мастерил инструменты (builder) для более удобного нежели Property Window управления свойствами элементов в гриде...
Единственное где я отказался от визуального задания свойств, так это в классах CursorAdapter. Изначально из-за ограничений 8-ки на размер строкового свойства (в дизайнере больше 255 символов в свойство было не прописать, тогда как программно - .SelectCmd = ... хоть 50 Кб запихивай), потом ещё и вопрос форматирования встал - одно дело красиво отформатированное или просто выровненное внутри TEXT ... ENDTEXT многострочное тело запроса (которое можно скопировать в те же утилиты работы с сервером, или из них и взять), или даже те же UpdatableNameList, и совсем другое "просто строка в свойстве".
Хотя и тут, конечно, можно было бы извернуться через builder - не штатный, так допиленный под себя, или вообще альтернативный поискать... Но тут нарисовали ещё и генератор этих самых CAD-ов из старинных RemoteView - а генерировать всегда проще текст, нежели vcx класс. Так оно и осталось, без визуальщины

------------------
WBR, Igor

Страницы: 1 2

:: Список Форумов•Список тем•Поиск•Войти

Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 21 (Гостей: 21)