Я тоже проверил - без команды вызывается таблица. Версия 585 первый релиз.
Кстати, проверил на 574 - тоже все работает. Думаю на версиях позже 574 все работает
Интерфейс Vschet
Модераторы: m0p3e, edward_K, Модераторы
-
- Местный житель
- Сообщения: 645
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"
Re: Интерфейс Vschet
Некоммерческое общение в форуме
-
- Местный житель
- Сообщения: 645
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"
Re: Интерфейс Vschet
Maverick-у
Сначало Вы написали о том, команды после putCommand не должны выполняться. ( с чего вобщем то и начался разговор). Потом вдруг написали, что не чистится стек и это ошибка (в принципе я и сам сомневался чистится он или нет).
Но на самом деле стек не должен чиститься при вызове другого окна. Просто события этого окна не должны МОЖЕТ БЫТЬ выполняться в новом окне - это другое дело. Теоретически команды окна должны может быть висеть в стеке до тех пор, пока управление не будет возвращено в текущее окно. И при возврате управления они должны быть выполнены.
Т.е.
cmMyCommand1:
{....
....
putCommand(cmDefault);
runinterface(.....);
...
}
cmDefault :
{
message('Вот я и дождался моего события!');
}
Сейчас событие cmDefault обрабатывается в запускаемом интерфейсе. Событие cmDefault текущего окна не будет выполнено.
По примеру. МОЖЕТ БЫТЬ (в чем я не уверен, что это правильно) событие cmDefault не должно обрабатываться в интерфейсе (чужем), а по окончанию обработки команды cmMyCommand выполнить обработчик cmDefault. МОЖЕТ БЫТЬ.
Хотя не факт, что это надо так делать.
Поэтому с уверенностью говорить, что это БАГ я бы не стал. Если при открытии интерфейса ВСЕ события будут чиститься - это тоже неверно.
С уваженеим, Игорь
Сначало Вы написали о том, команды после putCommand не должны выполняться. ( с чего вобщем то и начался разговор). Потом вдруг написали, что не чистится стек и это ошибка (в принципе я и сам сомневался чистится он или нет).
Но на самом деле стек не должен чиститься при вызове другого окна. Просто события этого окна не должны МОЖЕТ БЫТЬ выполняться в новом окне - это другое дело. Теоретически команды окна должны может быть висеть в стеке до тех пор, пока управление не будет возвращено в текущее окно. И при возврате управления они должны быть выполнены.
Т.е.
cmMyCommand1:
{....
....
putCommand(cmDefault);
runinterface(.....);
...
}
cmDefault :
{
message('Вот я и дождался моего события!');
}
Сейчас событие cmDefault обрабатывается в запускаемом интерфейсе. Событие cmDefault текущего окна не будет выполнено.
По примеру. МОЖЕТ БЫТЬ (в чем я не уверен, что это правильно) событие cmDefault не должно обрабатываться в интерфейсе (чужем), а по окончанию обработки команды cmMyCommand выполнить обработчик cmDefault. МОЖЕТ БЫТЬ.
Хотя не факт, что это надо так делать.
Поэтому с уверенностью говорить, что это БАГ я бы не стал. Если при открытии интерфейса ВСЕ события будут чиститься - это тоже неверно.
С уваженеим, Игорь
Некоммерческое общение в форуме
-
- Абориген
- Сообщения: 943
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: External Developer
- Контактная информация:
Re: Интерфейс Vschet
2 Косякин Игорь
Мей би я не правильно выразился по поводу чистки стека.
Поясняю
По логике вещей под стек для КАЖДОГО окна (интерфейса) должен отводиться СВОЙ кусок памяти, т.е. будем считать - свой стек, отличный от других. И работать это окно должно со своим стеком. Т.е. стек по определению не может быть общим для некоей совокупности окон (интерфейсов), поскольку они - суть разные объекты, пусть и порожденные из одного класса. В описываемой же ситуации получается что при вызове нового интерфейса происходит обращение к тому же стеку что и для вызвавшего интерфейса, а не инициализация нового под вызванный. Не находите что здесь есть конфликт? я, например, нахожу, поэтому и считаю, что это - баг. Хоть и пошедший в конкретном случае во благо.
А теперь к конкретно приведенному Вами примеру (в подтверждение моей версии об использовании чужого стека).
Попробуйте описать такую вещь
в 1-м интерфейсе:
cmDefault : Message ('Это первый интерфейс');
cmMyCommand1:
{....
....
putCommand(cmDefault);
runinterface(2-й интерфейс);
...
}
2-й интерфейс
...
cmDefault :
{
message('Вот я и дождался моего события в интерфейсе 2! ');
}
....
Голову на отсечение даю, что putCommand сработает на 1-м интерфейсе, и только если в 1-м интерфейсе не будет нигде cmDefault - то МОЖЕТ БЫТЬ вызовется cmDefault из второго.
В общем, пока официально не будет доказано обратного, либо не будет внятного разьяснения
по данной ситуации из компетентных источников, я останусь при своем мнении о том, что это - БАГ,ГЛЮК или назовите это как угодно. Процесс, некоректно работающий с памятью, вовремя его не очищающий - есть не что иное, как а) невнимательность б) разгильдяйство в) с жиру бесимся (памяти счас дофига, можно не следить за объемами).
Ксатати насчет некорректой работы с пмятью могу еще один довод привести - помнится в 5.20 я видел функцию принудительной очистки памяти - мей би функцию убрали, а проблема осталась?
Прошу сильно ногами не пинать )))
-------------------------------------
C уважением and best regards your Maverick
Мей би я не правильно выразился по поводу чистки стека.
Поясняю
По логике вещей под стек для КАЖДОГО окна (интерфейса) должен отводиться СВОЙ кусок памяти, т.е. будем считать - свой стек, отличный от других. И работать это окно должно со своим стеком. Т.е. стек по определению не может быть общим для некоей совокупности окон (интерфейсов), поскольку они - суть разные объекты, пусть и порожденные из одного класса. В описываемой же ситуации получается что при вызове нового интерфейса происходит обращение к тому же стеку что и для вызвавшего интерфейса, а не инициализация нового под вызванный. Не находите что здесь есть конфликт? я, например, нахожу, поэтому и считаю, что это - баг. Хоть и пошедший в конкретном случае во благо.
А теперь к конкретно приведенному Вами примеру (в подтверждение моей версии об использовании чужого стека).
Попробуйте описать такую вещь
в 1-м интерфейсе:
cmDefault : Message ('Это первый интерфейс');
cmMyCommand1:
{....
....
putCommand(cmDefault);
runinterface(2-й интерфейс);
...
}
2-й интерфейс
...
cmDefault :
{
message('Вот я и дождался моего события в интерфейсе 2! ');
}
....
Голову на отсечение даю, что putCommand сработает на 1-м интерфейсе, и только если в 1-м интерфейсе не будет нигде cmDefault - то МОЖЕТ БЫТЬ вызовется cmDefault из второго.
В общем, пока официально не будет доказано обратного, либо не будет внятного разьяснения
по данной ситуации из компетентных источников, я останусь при своем мнении о том, что это - БАГ,ГЛЮК или назовите это как угодно. Процесс, некоректно работающий с памятью, вовремя его не очищающий - есть не что иное, как а) невнимательность б) разгильдяйство в) с жиру бесимся (памяти счас дофига, можно не следить за объемами).
Ксатати насчет некорректой работы с пмятью могу еще один довод привести - помнится в 5.20 я видел функцию принудительной очистки памяти - мей би функцию убрали, а проблема осталась?
Прошу сильно ногами не пинать )))
-------------------------------------
C уважением and best regards your Maverick