|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
собственно вопрос: Можно ли закрыть из одной формы другую (зная ее name) без _SCREEN.FORMCOUNT, и как? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 15:00 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
Нельзя. Надо иметь ссылку на закрываемую форму. По name ссылку можно получить только перебором _screen.Forms Может быть открыто несколько форм с одинаковым name ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 15:40 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
Можно. Для этого убиваемую форму вызываем так : DO FORM AnyFormFile NAME KillForm В каком-нить совершенно другом месте приложения (в другой форме или программно) поджигаем фитиль : KillForm.Release Убиваемая форма релизится по ссылке на нее, как обьект KillForm. Усе. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 16:37 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
rewareМожно. Для этого убиваемую форму вызываем так : Если форма модальная, то в некоторых случаях так сработает, и то далеко не во всех. Когда выполняется команда DO FORM AnyFormFile фокс создает переменную AnyFormFile со ссылкой на объект-форму. Область видимости этой переменной PRIVATE со всеми вытекающими последствиями. если дополнительно указать NAME KillForm, то переменная будет называться KillForm остальное как я выше написал. А если так запустить: Код: plaintext 1. 2. 3.
AnyFormFile - немодальная форма. Все три закроются по KillForm.Release() ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 17:23 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
Dima T Когда выполняется команда DO FORM AnyFormFile фокс создает переменную AnyFormFile со ссылкой на объект-форму. Область видимости этой переменной PRIVATE со всеми вытекающими последствиями. если дополнительно указать NAME KillForm, то переменная будет называться KillForm остальное как я выше написал. Ну, это мы лечим. Достаточно в головном модуле обьявить все предполагаемые имена создаваемых обьектов-форм как PUBLIC и они станут доступными из любой точки программы. Код: plaintext
А если так запустить: Код: plaintext 1. 2. 3.
Все три закроются по KillForm.Release() ? Нет, закроется только последняя. Для этого и следует каждый экземпляр формы запускать со своим именем. Код: plaintext 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 18:18 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
пасибы за ответы! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 18:20 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
reware , это не решение, а усугубление проблем. Не надо объявлять глобальным то что глобальным быть не должно. По-нормальному, если две формы связаны, то решается это примерно так: 1. Родительская форма запускает дочернюю и дочерняя должна закрыться при закрытии родительской. в родительской форме делается свойство oChildForm и при запуске дочерней такой код: Код: plaintext 1.
Код: plaintext 1. 2.
2. Родительская форма запускает дочернюю и родительская должна закрыться при закрытии дочерней. В дочерней форме делается свойство oParentForm запускается дочерняя так: Код: plaintext 1.
Код: plaintext 1. 2.
Все остальные способы взаимодействия форм могут быть получены комбинированием этих двух способов. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 21:00 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
Dima T (пароль не помню) reware , это не решение, а усугубление проблем. Не надо объявлять глобальным то что глобальным быть не должно. По-нормальному, если две формы связаны, то решается это примерно так: 1. Родительская форма запускает дочернюю и дочерняя должна закрыться при закрытии родительской. в родительской форме делается свойство oChildForm и при запуске дочерней такой код: Стоп. Во-первых, приведенным вами кодом вы сами все усугубляете, добавление некого нового свойства по-вашему гораздо правильнее, нежели простое обьявление глобальных. Во-вторых, почему упор сделан на "родительская-дочерняя форма" ? Это подразумевает вызов одной из другой. А автор imperous задал вопрос - "Можно ли закрыть из одной формы другую (зная ее name) без _SCREEN.FORMCOUNT, и как?". Не больше и не меньше. Т.е. это могут быть две абсолютно независимые и немодальные формы. О каких родителях и дочерях тут речь ? Не притягивайте их за уши сюда. В частном случае "родительская-дочерняя" заданный вопрос вообще бы не возник - известны в design-time имена родителя и дочери. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 04:32 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
> Стоп. Во-первых, приведенным вами кодом вы сами все усугубляете, > добавление некого нового свойства по-вашему гораздо правильнее, нежели > простое обьявление глобальных. Глобальных переменных должно быть не более двух!!! А в идеале только одна - объект приложения. Т.е. объект некоего класса, в котором реализована логика необходимая всем модулям. В том же объекте хранится имя пользователя, который залогинился в программу и права доступа к формам, данным отчетам и т.п. Есть логика позволяющая задать/получить эти права и имя пользователя и т.п. Остальное - это от лукавого. Во-вторых, почему упор сделан на "родительская-дочерняя форма" ? Это подразумевает вызов одной из другой. Потому что я лично не знаю, почему "левая" форма должна закрывать данную форму, если они логически никак не связаны? (перефразируем известную цитату: "Не я тебя породил - не мне тебя и убивать") В случае, если должна закрыться КОНТКРЕТНАЯ форма, то в момент создания такой формы должна быть сохранена ссылка на эту форму. Ссылка может быть сохранена как свойство той формы которая породила (и соответственно пытается убить). Если может быть несколько подобных дочек, то ссылки могут быть сохранены в свойстве-массиве. Это как ты заметил "частный случай". В общем случае - _Screen.forms и перебор. Глобальных переменных плодить не зачем. После таких вот ляпов "профессиональных" программистов, поддерживать код становится практически невозможно. Т.к. Переменная создалась где-то там, инициализировалась где-то в другом месте, а используется здесь. Вот и попробуй отследить в каком порядке что происходило и где искать концы. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 06:03 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
> Глобальных переменных должно быть не более двух!!! > А в идеале только одна - объект приложения. Это круто. Остается добавить, что в идеале тогда обьект приложения должен содержать одно свойство, один event и один метод - Quit. Внутри обьекта плотно утрамбована логика, с которой разбираться на порядок легче, чем с пятью строками явного кода, написанного грубо говоря "от руки". А все остальное - от лукавого... > Во-вторых, почему упор сделан на "родительская-дочерняя форма" ? > Это подразумевает вызов одной из другой. > Потому что я лично не знаю, почему "левая" форма > должна закрывать данную форму, если они логически никак > не связаны? (перефразируем известную цитату: > "Не я тебя породил - не мне тебя и убивать") Жаль, что вы не знаете. Если внимательнее прочитаете мою предыдущую мессагу, то речь идет как раз не о родителях-детях, а о нескольких независимых немодальных формах. Неужели в ваших проектах существуют только модальные формы с жесткой родительско-дочерней связью ? Хорошо, примитивный пример такого приложения - есть некое главное SYSMENU, из пунктов которого можно в любой момент вызвать нужную ветку кода, открыть нужные алиасы и формы. Со временем на экране оказывается довольно приличное число открытых форм. Они могут не только мешать визуально, но и ограничивать взаимную работу с данными или даже вступать в конфликт. В какие-то моменты возникают неразрешимые противоречия между этими ветками кода (рожденными, заметьте, независимо из главного меню) и должно быть принято решение (юзером или самим приложением) о приоритетности какого-либо из этих параллельных процессов. Вот тут-то и требуется (в крайних случаях) закрыть несколько окон. Такая необходимость может возникнуть в любом месте программы, независимо от того, порождал он закрываемые процессы или нет. Если это кому-то интересно, то это называется "многопоточность". Это касательно только VFP. Если смотреть на два пальца глубже, то и сама Windows именно так обращается с запускаемыми приложениями. Эти приложения (то бишь - независимые процессы) могут обмениваться данными и даже влиять на взаимное поведение (вплоть до закрытия одним приложением другого). Так что, лучше перефразировать "Да, не я тебя породил, но я тебя убью" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 11:06 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
rewareDima T Когда выполняется команда DO FORM AnyFormFile фокс создает переменную AnyFormFile со ссылкой на объект-форму. Область видимости этой переменной PRIVATE со всеми вытекающими последствиями. если дополнительно указать NAME KillForm, то переменная будет называться KillForm остальное как я выше написал. Ну, это мы лечим. Достаточно в головном модуле обьявить все предполагаемые имена создаваемых обьектов-форм как PUBLIC и они станут доступными из любой точки программы. Код: plaintext
А если так запустить: Код: plaintext 1. 2. 3.
Все три закроются по KillForm.Release() ? Нет, закроется только последняя. Для этого и следует каждый экземпляр формы запускать со своим именем. Код: plaintext 1. 2. 3. 4. 5. 6. 7.
А если в приложении надо открыть не три формы, а 10..20... форм? Вы будете создавать столько PUBLIC переменных? А если в приложении надо открыть 2, 3, ... экземпляра одной формы ? Что тогда с именами переменных делать? А если приложение разрабатывают 2, 3..5... разработчиков? Как будете разбираться с именами PUBLIC переменных? Т.ч. лучше обратить внимание на вариант Рината. А ссылки на все свои объекты - формы (я использую не формы и DO FORM, а классы и ... CREATEOBJECT()) можно хранить в массиве (коллекции) в глобальном объекте приложения с "обвязкой" в виде методов, свойств и т.д. для комфортной работы с такой коллекцией. Пока приложение работает - ссылки "живы" и все формы "живы". И никаких PUBLIC переменных! С уважением, Алексей. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 11:48 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
reware> Глобальных переменных должно быть не более двух!!! > А в идеале только одна - объект приложения. Это круто. Остается добавить, что в идеале тогда обьект приложения должен содержать одно свойство, один event и один метод - Quit. Внутри обьекта плотно утрамбована логика, с которой разбираться на порядок легче, чем с пятью строками явного кода, написанного грубо говоря "от руки". А все остальное - от лукавого... В данном случае ринат абсолютно прав. Не имеет смысла смешивать процедурный и объектный подход к программированию. Я здесь его даже поправлю. В идеале приложение должно содержать ноль public-переменных, а та одна переменная, которую Ринат предлагал объявлять как public, корректней будет объявить как private, но в main-модуле. reware Жаль, что вы не знаете. Если внимательнее прочитаете мою предыдущую мессагу, то речь идет как раз не о родителях-детях, а о нескольких независимых немодальных формах. Неужели в ваших проектах существуют только модальные формы с жесткой родительско-дочерней связью ? Хорошо, примитивный пример такого приложения - есть некое главное SYSMENU, из пунктов которого можно в любой момент вызвать нужную ветку кода, открыть нужные алиасы и формы. Со временем на экране оказывается довольно приличное число открытых форм. Они могут не только мешать визуально, но и ограничивать взаимную работу с данными или даже вступать в конфликт. В какие-то моменты возникают неразрешимые противоречия между этими ветками кода (рожденными, заметьте, независимо из главного меню) и должно быть принято решение (юзером или самим приложением) о приоритетности какого-либо из этих параллельных процессов. Вот тут-то и требуется (в крайних случаях) закрыть несколько окон. Такая необходимость может возникнуть в любом месте программы, независимо от того, порождал он закрываемые процессы или нет. Не увидел в вашем примере убедительных доказательств необходимости лезть из одного независимого объекта в другой независимый объект. Более того, в идеале, объект не должен знать о существовании тех объектов, про которые ему ничего не сказали. Опять же не ясен, какой же может быть такой неразрешимый конфликт, который разруливается не на уровне ядра системы, а на уровне некоторого равноправного с остальными объекта? reware Если это кому-то интересно, то это называется "многопоточность". Если кому-то интересно, то фокс живет в одном потоке. А многооконный интерфейс так и называется, "многооконность". reware Это касательно только VFP. Если смотреть на два пальца глубже, то и сама Windows именно так обращается с запускаемыми приложениями. Эти приложения (то бишь - независимые процессы) могут обмениваться данными и даже влиять на взаимное поведение (вплоть до закрытия одним приложением другого). Так что, лучше перефразировать "Да, не я тебя породил, но я тебя убью" :) Операционка не даст закрыть из одного процесса другой. У вас есть 2 пути: 1. Из вашего процесса попросить некий другой чужой процесс закрыться. В таком случае, чужой процесс остается в праве послать вас к черту, или удовлетворить ваш запрос. 2. Можно попросить операционку прибить процесс. В таком случае, ядро системы решает, имеете ли вы на это право. И ядро системы вполне может точно так же послать вас к черту. Зато, если вы имеете на это право, ядро системы прихлопнет чужой процесс не смотря на его сопротивление. И в том и в другом случае, такое поведение объектов отнюдь не похоже на то, что вы описывали выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 12:00 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
извини что влажу в разговор, но в данном случае, мне действительно надо открыть всего лишь максимум 5 форм, и повторных экземпляров не будет. Поэтому ответ reware меня вполне устроил и это как ра то что надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 12:58 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
rewareСо временем на экране оказывается довольно приличное число открытых форм. Они могут не только мешать визуально, но и ограничивать взаимную работу с данными или даже вступать в конфликт. В какие-то моменты возникают неразрешимые противоречия между этими ветками кода Всё ж попробуйте приватные сессии данных в формах и все Ваши вышеописанные проблемы отомрут аки страшный сон :). Вместе с кучей паблик переменных :):) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 22:27 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
> Если смотреть на два пальца глубже, то и сама Windows именно так > обращается с запускаемыми приложениями. Эти приложения (то бишь - > независимые процессы) могут обмениваться данными и даже влиять на взаимное > поведение (вплоть до закрытия одним приложением другого). Одно маленькое уточнение и диспут можно закрывать, пока он не зашел в тупик: А сама винда тоже создает миллионы глобальных переменных - по одной на каждое из возможных приложений, чтобы одно приложение могло убить другое по имени? Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 06:58 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
> извини что влажу в разговор, но в данном случае, мне действительно > надо открыть всего лишь максимум 5 форм, и повторных экземпляров не будет. Это не повод привыкать к заведомо неправильному стилю программирования. Работать будет. Возможно даже правильно (в зависимости от того что надо и как реализуешь). Но вот правильный ли это будет стиль? Легко ли потом будет расширять приложение? На сколько прсто будет это сделать другому программисту, который в последствии будет поддерживать твою программу? Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 07:19 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
Galyamov Rinat Одно маленькое уточнение и диспут можно закрывать, пока он не зашел в тупик: А сама винда тоже создает миллионы глобальных переменных - по одной на каждое из возможных приложений, чтобы одно приложение могло убить другое по имени? Никто не знает, как это сделано в Windows. Прикладной программист выбирает способы, доступные ему, а не с оглядкой на дяденьку из мелкософта. А диспут, дествительно, можно бы и закрыть, поскольку еще никто не отменял и PUBLIC ARRAY или другие глобальные контейнеры. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 11:48 |
|
Можно ли закрыть из одной формы другую без _SCREEN.FORMCOUNT?
|
|||
---|---|---|---|
#18+
rewareеще никто не отменял и PUBLIC ARRAY или другие глобальные контейнеры. Если что-то существует - это не основание этим активно пользоваться. Никто не запрещает прыгать из окна, это наиболее быстрый способ попасть на улицу, но почему-то все едут на лифте или идут по лестнице. Похоже бесполезно пытаться объяснять тебе чем чревато использование глобальных переменных. Выше уже все сказано по этому поводу. Не хочешь учиться на чужих ошибках - будешь учиться на своих, когда твоя прога заглючит в проверенном месте, а причину глюка будешь искать долго и муторно. И даже когда найдешь - поймешь что уход от источника проблемы это переписывание как минимум половины проги. Сам можешь писать как хочешь, но не надо настоятельно советовать другим повторять твои ошибки. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 13:02 |
|
|
start [/forum/topic.php?fid=41&msg=35783780&tid=1586823]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
49ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 324ms |
total: | 469ms |
0 / 0 |