Народ, как думаете, нужен ли нам отдельный встроенный в 1С++ или ФормЕкс класс Таймер?

Т.е. я предполагаю его использование вместо Сервис.ОбработкаОжидания или РасширениеФормы.ОбработкаОжидания и собрать их функционал в одном классе.

Данный класс сможет работать с любой формой или модулем или произвольным контекстом.
Я вижу такой интерфейс
Цитата:


Все методы тривиальны, кроме последнего.

Метод Событие_Таймер я планирую использовать для поддержки ООП, т.е. данный метод всегда будет вызываться при событии от таймера.
Т.е. можно создать КОП-наследник таймера, переопределить в нем метод Событие_Таймер(), выполнить свою обработку.
И если стандартный вызов не нужен, то можно не вызывать метод База.Событие_Таймер().

А метод Событие_Таймер во встроенном классе как раз и будет вызывать необходимые обработчики, заданные одной из функций ЗадатьОбработчикXXX

Жду ответов.

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

Чегой-то я не понял. А каково будет время жизни этого объекта? Где надо будет хранить таймер, чтобы он вызывал ОбработчикВМодулеФормы?

Нет, я, в принципе, понимаю, что хранить его можно будет где угодно. Но где реально вы предполагаете его хранить? А помните про проблемы, связанные с разрушением объектов формы?

Опять же, это будет настоящий таймер, или таймер обработки ожидания? Если я заведу его на 10 мсек и запущу обработку на 10 минут, то таймер сработает?

Отвечаю по пунктам:

sedmin писал(а) 26. Сентября 2007 :: 18:57:

1) Время жизни объекта произвольное, как определит пользователь класса, т.е. наиболее гибкое поведение.
По поводу работы с формой то же самое.

В дальнейшем можно сделать один из вариантов или их объединение
        а) таймер, который работает с формой, перестает быть валидным, когда форма закрывается. Т.е. абсолютна та же схема, что и для значения контекста формы (пока форма открыта, его тип 100, как закрыта, тип = 0)
Соответственно пользователю подобного таймера нужно будет проверять его тип значения.
Для других видов таймеров такой проблемы нет.

        б) Также можно добавить указанный таймер как элемент Формы - т.е. добавить спец. контекст к групповому контексту формы и обращаться к нему через Форма.НужныйТаймер.
Как реализовать подобную схему, мне понятно, осталось дело за реализацией.
ЗЫ кстати, подобная привязка к форме мной планируется для добавляемых на форму атрибутов

sedmin писал(а) 26. Сентября 2007 :: 18:57:

См. п.1
А проблемы, связанные с разрушением объектов формы, легко решаются с помощью придуманного нами смарт-пойнтера CSafeContextPtr - примеры использования есть в коде 1С++

sedmin писал(а) 26. Сентября 2007 :: 18:57:

Что значит "настоящий таймер"? тот, который работает независимо от работы, выполняемой приложением, называется Поток, и мы от его использования отказались

А остальные таймеры в однопоточном приложении зависят от того, обрабатывает ли приложение сообщения Винды или оно загружено непрерывной работой.
Так что все ограничения подобных таймеров остаются - т.е. если 1С выполняет какой-то код, то событие таймера сгенерится только после завершения кода.

Для некоторого обхода подобных ограничений я планирую добавить в ФормЕкс некий метод, который заставит 1С обработать очередь сообщений винды. В итоге пользователь сможет вызывать этот метод для обработки каких-то нужных сообщений - например, удобно использовать для отрисовки прогресс-бара во время длительной работы 1С или еще чего

vip писал(а) 02. Октября 2007 :: 09:47:

1. Все, что написано в посте 0, осталось.
Добавилось только
метод УдалитьОбработчик
метод Отладка_ВыполнитьСобытиеТаймера - используется для возможности экстренного посыла события и отработки события в обработчике. Фактически это только для тестирования.
и 2 свойства (только для чтения) - Интервал и Запущен

2. ИМХО просто метод ЗакрытьВсеОкна должен быть в классе "Окна" - теперь метод Сервис::ЗакрытьВсеОкна просто вызывает Окна::ЗакрытьВсеОкна.

to artbear
ЗадатьОбработчик() ты видимо убрал, ругается на отсутствие метода.
А так вроде все работает.

artbear писал(а) 25. Сентября 2007 :: 06:44:

Вот эта возможность пока не реализована, возможно, появится в будущих версиях.

vandalsvq писал(а) 02. Октября 2007 :: 12:35:

1. Я же говорю, что все недостатки Сервис::ЗакрытьВсеОкна остались, планирую исправить в будущем.

2. Написано же "наименование метода в форме", а не вызов
Использовать так
     Таймер.ЗадатьОбработчикВМодулеФормы(Контекст,"Сооб");
т.е. без скобок

1) Этот метод может вызывать совершенно любой метод с количеством параметров 0 для любого контекста, в т.ч. и классы КОП.
Т.е. ему можешь передать объект своего класса и название метода в классе, и по событию таймера управление будет получать твой класс.

2) ИМХО тебя все проблема в том, что объект Таймер является локальным для процедуры, закинь его в переменные модуля формы и будешь получать сообщения
А сейчас по выходе из процедуры Таймер автоматически удаляется

Цитата:

Для этого все и задумывалось, так?
И получилось
А в остальном это та же ОбработкаОжидания из FormEx.

artbear писал(а) 09. Октября 2007 :: 12:49:

Вот как раз у ОбработкиОжидания из FormEx нет такой фичи (бага)
Она работает, даже когда главное окно 1С свернуто. А вот штатная ОбработкаОжидания нет (хотя насчет штатной может я и ошибаюсь).

Цитата:

Да и класс Таймер работает, только что проверил. Так что Артур не прав.
Цитата:

А почему нет? Насколько я понимаю, процедура выполняется в idle-time.
У меня работают одновременно несколько таймеров с интервалом 1мс, выполняюшие роль своеобразных листенером с малым временем отклика. Проблем не заметил. Процессор от работы таймеров не грузится.

Получилось.
Форум не виноват.

У меня то же самое.
И иногда обработка ожидания зависает (в смысле не останавливается в стопе, либо до стопа просто не доходит).

vip писал(а) 09. Октября 2007 :: 16:23:

обычный стресс-тест...

kms писал(а) 09. Октября 2007 :: 16:25:

Я вообще Стоп не могу нажать, не реагирует

kms писал(а) 09. Октября 2007 :: 16:25:

Да, хороший тест

Цитата:

Да, это дает некое подобие многопоточности (если не издеваться над железом, как kms )
Скоро будет год, как я одновременно использую несколько ОбработокОжидания с малым интервалом для очень серьезных задач. Так что не переживай

pavlo писал(а) 17. Марта 2009 :: 06:20:

У romix есть ВК для этого. Что-то вроде 1Csleep называлась.

dnp писал(а) 17. Марта 2009 :: 07:36:


Ага, так почти и сделано, кстати спасибо, есть же классный метод у класса Система.Уснуть() и при не активном окне пашет

artbear писал(а) 17. Марта 2009 :: 09:20:


Ага, делал просто субъективный тест и получилось при базовой нагрузке на проц 30% при работе, если Предупреждение("",5) делать то проц падает до 1-5%, а если уснуть до 0%

Valera писал(а) 01. Августа 2009 :: 22:20:


Переменную таймер объяви, уже выше написано.

Переменная Таймер должна быть глобальной - например, в модуле формы или в ГМ.

classic писал(а) 14. Октября 2009 :: 13:59:

Нет, в этом случае в форму таймер выносить не обязательно.
Главное, чтобы таймер не удалялся сразу же после создания, как в таком коде
Цитата:

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

В обработчике выполнил объект "Запрос" и поле ввода выделилось, затем убрал "Запрос" и вставил запрос на 1с++ - О чудо - выделение поля ввода не произошло...

1c++ 3.2.4.3

если в классе создать таймер (приват переменная) и задать обработчик процедуру класса через

ЗадатьОбработчикВОбъекте(я(), "ПроцедураКласса")

то не отрабатывает деструктор класса.

Это как-то обойти можно?

Если поставить по срабатыванию таймера УдалитьОбработчик(), то вылетает 1с после деструктора.