Hi All!

2 Aleksey
Передавать ThisForm - это жёстко себя привязывать к формам - предпочитаю
(если уж это действительно надо) передать ссылку на Thisform в свойстве
ParameterObject-а, а заодно возможно и ссылку на контрол откуда идёт вызов
подчинённой формы. Подчёркиваю - ЕСЛИ ЭТО НУЖНО - обычно у меня вызываемая
форма не знает ничего о вызывающем её коде, и тем более не делает
предположений насчёт того что будет передана форма, или ссылка на контрол...
Хотя принципиальной разницы в том что форма или контрол сами служат в
качестве ParameterObject (а не отдельный объект) нету.
Как уже замечено это позволяет вызывать форму из prg (там то по любому
придётся создать объект - прочём IMHO Custom для этого лучше подходит чем
Form - а в свежих версиях фокса там в вовсе Empty есть). Также проще
работать с "несохраняемым" ParameterObject - т.е. отработала вторая форма,
мы получили что хотели и объект уничтожился - а так все данные останутся в
свойствах Form... Кстати удалить свойство штатным образом можно стало только
начиная с VFP8. Насчёт добавления методов не понял - зачем это надо, и чем
тут Form выигрывает по сравнению с Custom (ну точнее классы от них
производняе конечно) - если метод есть, его можно вызвать, если же его нету,
то ни о каком "добавлении метода" речи не идёт.
Кстати для уточнения - scx форма - это особого рода подкласс (правда с рядом
ограничений по сравнению с vcx, и с "довеском" в виде "встроенного" DE
Object - который кстати ведёт себя не совсем вменяемо - например его метод
OpenTables зачем-то вызывается до Init - и вообще есть масса нюансов с DE
который в scx форме живёт) - так что некорректно говороить о том, что эта
форма есть нечто "базовое".
Кстати использование goApp в качестве "точки вызова" формы Login по сути
мало отличается от main.prg методы goApp можно рассматривать как
общедоступные процедуры, а его свойства как Public переменные (со всеми
вытекающими из этого нюансами использования).

2 --Eugene--
Неважно где будет "создаваться" значение свойств - т.е. у тебя по закрытию
формы (кнопка, "крестик" и т.п.) нужно лишь установить какие-то свойства
формы и всё. И т.к. у тебя в форме в Init была строка This.Show(1) - то
управление вернётся в Init (это трюк конечно, но он вполне работает) - и
можно будет присвоить значения параметрам переданным по ссылке. Я не
призываю так делать, но это вполне возможно.
Насчёт VarType+Isnull - да, это избыточно, но если заменить это нa
Type+Isnull - то будет в самый раз! Дело в том, что Vartype
(oSomeObject.oSomeProperty) - может вызвать ошибку - если собственно объекта
oSomeObject не существует - тогда как TYPE() ошибки поглощает, что весьма
удобно - НО Type имеет проблему - он возвращает "реальный" тип - т.е. если у
тебя была где-то ссылка на объект, скажем форму, а потом ОБЪЕКТ уничтожили
(ссылка при этом зануляется автоматом) - то ТИП остаётся "O" - несмотря на
то, что "значение" там будет .NULL. Обходят это второй проверкой через
Isnull, или "усложнив" проверку в Type скажем так:
Type("oSomeObject.oSomeProperty.Name") = "C" - ну или проверив иное
гарантированно имеющееся у соответствующего объекта свойство (если оно есть,
значит и объект жив).

2 Владимир&Aleksey
Я считаю что как раз ТАК делать и не стоит - что текое форма - это элемент
UI - сегодня это одна форма, завтра другая, послезавтра третья - а вот
логика авторизации - это отдельная вещь - причём она также может меняться
много раз - НЕЗАВИСИМО от изменения формы ввода (сегодня в DBF храним логин
и пароль - завтра на SQL сервере, или просто способ хэширования пароля
поменяли, или ещё что) - и я бы ни в коем случае не советовал "совмещать"
эти 2 вещи. Форма ввода должна... ввести данные и вернуть их в точку
вызова - т.е. быть не более "навороченной" (не в плане UI конечно - там
можно хоть радугу и фанфары сделать? или чтоб она подпрыгивала и
пританцовывала при наборе) чем Inputbox() - а уже в точке вызова и должен
проходить анализ - при этом конечно это должен быть метод класса goApp, или
отдельный объект... А саму форму можно оставить висеть на время проверки,
выведя туда прогрессбар или анимацию или ещё чего - но всё-же разделить 2
задачи (UI и собственно авторизацию) стоит.

Posted via ActualForum NNTP Server 1.3