Обработка Cancel

← →
Шурик_ (2005-12-02 11:24) [0]

Возник такой вопросик. Есть функция которая может работать достаточно долго. На экране работа отображается в виде окошка с прогресс баром и кнопкой Cancel. Собсно вопрос каким образом обработать нажатие Cancel. Есть два варианта пока:
1. Функция работает в дополнительном (неосновном) потоке и по нажатии грохнуть этот поток. Мне этот вариант както не очень нравится. Пока интуитивно.
2. В функции, который организован через do-while, поставить счетчик и чтобы он через определенное количество итераций делал что-то вроде CheckMessage, и при наличии Cancel прервать выполнение.

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

← →
Плохиш © (2005-12-02 11:55) [1]

2. CheckMessage --> Application.ProcessMessages

← →
Винт (2005-12-02 11:57) [2]

Первый вариант лучше. Что смущает в его использовании?

← →
ANB © (2005-12-02 12:15) [3]

> Первый вариант лучше. Что смущает в его использовании?

Никакого смысла городить отдельный поток (и наступать на грабли синхронизации) нету.

> Шурик_ (02.12.05 11:24)

while (условие) do begin // Или for или любой другой цикл
Полезные действия
Application.ProcessMessages;
if (Нажата Cancel) then begin
break;
end;
end;

Особенности - при этом пользователь сможет нажимать другие кнопки в приложении, следовательно, умудрится запустить эту функцию еще раз. Чтобы этого не было - надо блокировать те кнопки, которые нельзя нажимать, пока этот код работает.

← →
Винт (2005-12-02 12:19) [4]

>ANB © (02.12.05 12:15) [3]

> Никакого смысла городить отдельный поток (и наступать на
> грабли синхронизации) нету.

Для длительных вычислений использование Application.ProcessMessages приведет к значительному замедлению вычислений, что иногда - критично для задачи.
Кроме того, никаких граблей нет. Все делается просто.

← →
ANB © (2005-12-02 12:21) [5]

> Винт (02.12.05 12:19) [4]

В отдельном потоке - не факт, что быстрее.

← →
Винт (2005-12-02 12:22) [6]

> В отдельном потоке - не факт, что быстрее.

Однозначно(при условии использования Application.ProcessMessage, конечно)

← →
Digitman © (2005-12-02 12:31) [7]

> Винт (02.12.05 11:57) [2]

1-й вариант чреват мемликами.

> Шурик_ (02.12.05 11:24)

2-й вариант концептуально правильней и корректней.

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

← →
Винт (2005-12-02 12:35) [8]

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

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

← →
Шурик_ (2005-12-02 13:26) [10]

Почитал, посмотрел принял решение. В принципе одна итерация цикла занимает порядочно времени по сравнению с проверкой сообщения на приход Cancel - события. Так что действительно нечего дурью маяться и сделать как говорил >ANB © (02.12.05 12:15) [3].

Thanks All

> Винт (02.12.05 12:35) [8]

да, разумеется

потому и "чреват" сабжем, но не обязательно приводит к сабжу

Обработка Cancel Найти похожие ветки