Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2010.08.27;
Скачать: [xml.tar.bz2];

Вниз

как отменить выполнение обработчика?   Найти похожие ветки 

 
Delphist2   (2010-04-06 06:14) [0]

Есть кнопка, ее обработчик может выполняться долго. Как добавить возможность отмены выполнения?
Если долго выполняется метод adocommand.execute, то как можно отменить его, не дожидаясь результата запроса?


 
sniknik ©   (2010-04-06 07:50) [1]

> Если долго выполняется метод adocommand.execute, то как можно отменить его
отменить можно только асинхронное выполнение (при синхронном отмену попросту неоткуда сделать). с другой стороны, если сделать асинхронно, то возможно не понадобится отмена... и уж точно отменять нужно будет не "обработчик кнопки которая есть".

> Как добавить возможность отмены выполнения?
сделать еще одну кнопку и вставить отмену в ее обработчик?


 
И. Павел ©   (2010-04-06 07:55) [2]

Может быть просто поставить таймаут?


 
Delphist2   (2010-04-06 09:04) [3]

Асинхронно - это eoAsyncExecute? Ну допустим поставлю, а как отменить?

> сделать асинхронно, то возможно не понадобится отмена...
>  

В каком смысле не понадобится?


 
MsGuns ©   (2010-04-06 09:14) [4]

>Delphist2   (06.04.10 09:04) [3]
>Асинхронно - это eoAsyncExecute? Ну допустим поставлю, а как отменить?

TADOCommand.Cancel

>> сделать асинхронно, то возможно не понадобится отмена...
>В каком смысле не понадобится?

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


 
sniknik ©   (2010-04-06 09:18) [5]

> Ну допустим поставлю, а как отменить?
ну допустим почитаешь справку.

> В каком смысле не понадобится?
а в каком смысле она тебе нужна? причина из-за чего отменяешь. так вот эта причина может исчезнуть при переделке логики (это не просто "поставлю") на асинхронность.


 
Delphist2   (2010-04-06 09:43) [6]


> причина из-за чего отменяешь

Ну там причина это удобство пользователя. Пользователь неправильно ввел параметры, запустил запрос, обнаружил что парамеры не те и не дожидаясь результатов перезапустил с др. параметрами.


 
Delphist2   (2010-04-06 09:53) [7]

А если надо прибить сразу весь обработчик (не обязательно этот а вообще), то это же надо в поток его оформлять, без потоков в таком случае никак?


 
И. Павел ©   (2010-04-06 10:13) [8]

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


 
sniknik ©   (2010-04-06 10:15) [9]

> обнаружил что парамеры не те
а каким образом он это обнаружит запуская командный запрос? не возвращающий результат. по каким признакам?

> то это же надо в поток его оформлять, без потоков в таком случае никак?
в каком ТАКОМ случае? нет случая, не описан, код не приведен. и потом с асинхронностью твой обработчик подозреваю работать не будет... не зря говорил о переделке логики.

а вот с потоками оно плохо уживается, т.к. все усложняется, твои + внутренние, мало кто сможет "разрулить"... (а кто может тот этого делать не будет т.к. понимает, что только хуже сделает, а то, что нужно можно и без этого)


 
MsGuns ©   (2010-04-06 10:42) [10]

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


 
Delphist2   (2010-04-06 10:43) [11]


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

Ну мне нужно прерывание именно по решению пользователя

> а каким образом он это обнаружит запуская командный запрос? не возвращающий результат

Параметры-то в edit. Ввел параметр в edit, нажал кнопку, бац - а в эдите не то! А запрос долго делается.
Нет, запрос как раз возвращает данные. Там делается обычный select. Потом это все рисуется в таблицу. Или асинхронные можно только с невозвращающими рез. запросами?


> в каком ТАКОМ случае? нет случая, не описан, код не приведен.

Это я в общем. Код может быть любой, например, какие-то долгие матем. вычисления.


 
MsGuns ©   (2010-04-06 11:00) [12]

1. Запрос можно проверить на сервере, не выполняя его - читайте справку по АДО
2. Если Вы пишете что-то типа скл-клиента, где предлагаете юзеру полностью ввести запрос,
 то либо предоставьте ему хоть какой-нибудь сервис (например как в QA) либо, если пользователь  опытный. не заморачивайтесь вообще
3. Еще раз по поводу объемных рекодсетов - можно предварительно сделать что-то вроде
 Select count(*) from <Запрос, введенный пользователем>
и если кол-во записей будет очбольшим, предупредить юзера о продолжительности выполнения
4. Прервать выполнение запроса предельно просто - для этого нужно во-первых запускать запрос в асинхронном режиме, во-вторых в обработчике кнопки "Останов" написать Cancel как Вам было указано выше.
5. Судя по описанной Вами задаче, никаких потоков не нужно - они в самом деле только усложнят код и затруднят отладку - см. замечания Sniknik


 
Delphist2   (2010-04-06 11:03) [13]


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

Не, пользователь указывает не соединение, а дату и прочую рабочую информацию, необходимую для запроса. Объем возвращаемых данных невелик, там именно сам поиск по БД, агрегатные функции в запросе. При больших объемах БД время становится ощутимым.


 
MsGuns ©   (2010-04-06 11:06) [14]

Еще по поводу "долгости" в виде "вычислений"

Большинство серверов при выборках не тормозят на "вычислениях" - затруднения у них вызывают 2 вещи -
а) отсутствие "нужных" индексов
б) большие объемы отсылаемых на клиент данных, особенно если клиент "медленный"


 
sniknik ©   (2010-04-06 11:11) [15]

> При больших объемах БД время становится ощутимым.
а что ты знаешь про индексы например...

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


 
MsGuns ©   (2010-04-06 11:17) [16]

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


 
Игорь Шевченко ©   (2010-04-06 12:10) [17]


> Есть кнопка, ее обработчик может выполняться долго. Как
> добавить возможность отмены выполнения?


Снять процесс через TaskManager


 
12 ©   (2010-04-06 13:11) [18]

предусмотреть ее в обработчике


 
sniknik ©   (2010-04-06 13:57) [19]

> предусмотреть ее в обработчике
ха. так он же не считает, что сам виноват в тормозах (код обработчика), думает, что это от adocommand.execute зависит (и опять таки код запроса в нем/структура базы, т.е. то что он делает, это все идеально и в тормозах не участвует. судя по отсутствию кода, и разговорам "в общем")


 
Delphist2   (2010-04-07 03:04) [20]

Вот еще хотел спросить: при асинхронном выполнении следующий за adocommand.execute оператор начнет выполняться еще до завершения execute или нет? Если да, то тогда код
a:=adocommand1.execute;
a.MoveFirst;
while not(a.eof) do...

может выполняться неправильно и вся работа с возвращеным рекордсетом должна происходить в событии adocommand.OnExecuteComplete?


> так он же не считает, что сам виноват в тормозах

Причина тормозов была в большом количестве null значений в поле поиска, они попали туда из-за сбоя базы (базе уже приходилось делать "сжать и восстановить"). Из самой проги занести null не получится, а из акцесса там некому, т. к. знаем только word и excel.


 
Германн ©   (2010-04-07 03:11) [21]


> Delphist2   (07.04.10 03:04) [20]
>
> Вот еще хотел спросить: при асинхронном выполнении следующий
> за ХХХ оператор начнет выполняться еще до
> завершения или нет?

Имхо до. В этом и суть асинхронных процедур/методов. Они не ждут своего выполнения.


 
MsGuns ©   (2010-04-07 08:57) [22]

>Delphist2   (07.04.10 03:04) [20]

Application.ProcessMessages в цикле ожидания завершения запроса


 
sniknik ©   (2010-04-07 09:38) [23]

> может выполняться неправильно
не может, а точно будет. о чем с самого начала и говорю, нужно менять логику.

>> так он же не считает, что сам виноват в тормозах
> Причина тормозов была в большом количестве null значений в поле поиска
ну вот, а я о чем? уверенность есть, поводов/знаний предмета не видно.
во первых непонятно почему это null должен мешать (если только от "кривого" алгоритма), запросам например оно же не мешает, а при индексах так значения даже не рассматриваются в "поисках" (where).
"алгоритм" это вот тут while not(a.eof) do...? тут "поиск" делается? и с "сырым" рекордсетом? тоже из-за глупой уверенности, что сам с ним быстрее будешь работать, чем борланд в обертке? ну ну.

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

> они попали туда из-за сбоя базы
тоже нужно умудриться... у меня(клиентов с моими программами) с 2000го (/2001го) года ни одного сбоя базы access2000 не было (вот на 97 были, но с ней дальше тестов дело не пошло), хотя счет клиентам идет на тысячи (минимум 20 максимум 50. смотря как считать, да и не знаю точно т.к. реализацией не занимаюсь). а тут одна программа, одна база (ну пусть десяток), и раз - виноват сбой, а не ты... ну конечно. в лотерею давно играл? купи билетик, с твоим счастьем выиграешь 100%.


 
Delphist2   (2010-04-07 10:01) [24]

Цикл ожидания завершения запроса - как он строится, можно пример?


 
brother ©   (2010-04-07 10:14) [25]

...
TimeOut: integer;
...

TimeOut:= 0;
repeat
 Inc(TimeOut);
 Application.ProcessMessages
until нормальный_выход or (TimeOut>={10000 например});


 
brother ©   (2010-04-07 10:16) [26]

или так:

...
TimeOut: integer;
...

TimeOut:= 0;
repeat
Inc(TimeOut);
Application.ProcessMessages;
Sleep(1);
until нормальный_выход or (TimeOut>={10000 например});


 
sniknik ©   (2010-04-07 10:22) [27]

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


 
Delphist2   (2010-04-08 02:24) [28]


> "алгоритм" это вот тут while not(a.eof) do...? тут "поиск"
> делается?

Здесь делается занесение данных в не DB-компонент. Поиск на тот момент уже проведен.

Конвертнул базу в 2003 формат. Индексы у полей таблиц проставил где надо. Обязательность проставил на всякий случай. Дефолтоые значения... Так там и так вроде стоит пустая строка по умолчанию. Или ее надо явно задавать?



Страницы: 1 вся ветка

Форум: "Начинающим";
Текущий архив: 2010.08.27;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.53 MB
Время: 0.054 c
15-1272659402
Юрий
2010-05-01 00:30
2010.08.27
С днем рождения ! 1 мая 2010 суббота


15-1268761702
AntonioBanderas
2010-03-16 20:48
2010.08.27
База комплектующих для АРМ


15-1264596540
dars73
2010-01-27 15:49
2010.08.27
SQL Возможно ли?


15-1271991405
вт
2010-04-23 06:56
2010.08.27
Исходник, пример подобный Криптоконтейнер


15-1266678959
GDI+
2010-02-20 18:15
2010.08.27
Интересно, когда андроиду можно будет просто сказать.





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский