Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Обработка Cancel

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

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

Digitman (2005-12-02 13:38:00) [1]

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

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

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

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

Thanks All

Anatoly Podgoretsky (2005-12-02 12:57:00) [3]
Если окно модальное, то никаких проблем в Application.ProcessMessages не возникнет, он для того и предназначен, чтобы обрабатывать события.
Если не модальный, то сразу возникает вопрос, а что же делать с сообщения, что плевать на них что ли.
И озабоченым по поводу скорости, на современныъ компьютерах можно делать до нескольких миллионов вызовов в секунду, время работы функции менее одной микросекунды. Видимо кто то путает скорость данной функции с обработкой собщений.

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

Винт (2005-12-02 12:35:00) [4]

> Digitman © (02.12.05 12:31) [7]
>
> 1-й вариант чреват мемликами.

Ну все ведь от реализации зависит-)

Digitman (2005-12-02 12:31:00) [5]

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

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

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

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

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

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

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

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

ANB (2005-12-02 12:21:00) [7]

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

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

Винт (2005-12-02 12:19:00) [8]
>ANB © (02.12.05 12:15) [3]

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

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

ANB (2005-12-02 12:15:00) [9]

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

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

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

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

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

Винт (2005-12-02 11:57:00) [10]
Первый вариант лучше. Что смущает в его использовании?

Плохиш (2005-12-02 11:55:00) [11]
2. CheckMessage --> Application.ProcessMessages

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »