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

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

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

ProgreessBar, подвисание проги [D7, XP]

Страницы: 1 2 3 >
timekiller © (2010-03-12 10:39:00)
Уважаемые знатоки! У меня проблема такая:
Есть форма, на ней Progressbar (Gauge, как его назвали)...
Но толк от него пропадает, когда программа попросту занята 15минутным выполнением задачи (разбор гигабайтного XLS, например) - В заголовке появляется некое (Не отвечает), форма перекрашивается в белый цвет и всё приехали.....

Вопрос такой, для тех кто сталкивался: Как оживить Progressbar во время выполнения программы?
Алгоритм растет, что будет когда программа будет выполнятся 2 часа, допустим?....

Leonid Troyanovsky (2010-03-17 18:45:00) [1]

> Игорь Шевченко © (17.03.10 18:38) [41]

Ну, да. То, что осталось от давнишних обсуждений.
Звучало примерно так, ЕМНИП:
"Процедура, содержащая ПМ, явлется нереентерабельной".

Были найдены и лекарства от оного, IMHO.

--
Regards, LVT.

Игорь Шевченко (2010-03-17 18:38:00) [2]
Leonid Troyanovsky © (17.03.10 18:20) [38]
Демо © (17.03.10 18:24) [39]

Там не только D2010, там еще Windows 7 и вообще

Application.ProcessMessages considered harmful

Leonid Troyanovsky (2010-03-17 18:34:00) [3]

> Демо © (17.03.10 18:24) [39]

Хитро квотируешь ;)

А чего там сложного: здесь по 100 г, там соточку - так и долетели.

Уж с обработкой сообщений можно б было справиться, не бином
Ньютона, бо уж PM - в первичном потоке.

--
Regards, LVT.

Демо (2010-03-17 18:24:00) [4]

> Игорь Шевченко © (17.03.10 16:45) [37]

> Там (D2010) не очень интересно, видимо, глюк отладчика.

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

Leonid Troyanovsky (2010-03-17 18:20:00) [5]

> Игорь Шевченко © (17.03.10 16:45) [37]

> Кстати, любопытная дискуссия по поводу ProcessMessages:

Там (D2010) не очень интересно, видимо, глюк отладчика.
Про PM были и более содержательные обсуждения от
которых остались лишь "многие лета".

--
Regards, LVT.

Игорь Шевченко (2010-03-17 16:45:00) [6]
Демо © (13.03.10 17:48) [22]

Кстати, любопытная дискуссия по поводу ProcessMessages:
https://forums.codegear.com/thread.jspa?messageID=218939&tstart=0

Anatoly Podgoretsky (2010-03-14 14:29:00) [7]
> Игорь Шевченко (14.03.2010 14:27:35) [35]

Я тоже иных попыток не наблюдал

Игорь Шевченко (2010-03-14 14:27:00) [8]
Я встречал (и довольно часто) использование многопоточности для запуска длительных процессов с одной целью - чтобы окно программы можно было свернуть.

Игорь Шевченко (2010-03-14 14:25:00) [9]
sniknik © (14.03.10 14:05) [32]

> начинающие часто преувеличивают полезность многозадачных
> операций (именно от пользователя, типа стартовал расчет
> а пока идет делает что-то другое...), и вставляют их куда
> ни попадя, нужны они там или нет неважно

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

Anatoly Podgoretsky (2010-03-14 14:22:00) [10]
> sniknik (14.03.2010 14:05:32) [32]

действительно в пользовательском интерфейсе пользы от многозадачности немного.

sniknik (2010-03-14 14:05:00) [11]
> Пользователь должен пойти спать, согласно [12]
ну а почему нет? если результат нужен только завтра.

вообще, имхо конечно, начинающие часто преувеличивают полезность многозадачных операций (именно от пользователя, типа стартовал расчет а пока идет делает что-то другое...), и вставляют их куда ни попадя, нужны они там или нет неважно. его стартуют ради результата, и если обработка действительно не сутки, а там несколько минут, то его ждут, а не переключаются на другие задачи.
ну вот например, есть такая программка MyRuLib.exe, у нее длительная обработка архивов сделана такой вот "параллельной" операцией (уж не знаю как потоком или с типа ProcessMessages) но смысла в этом чуть, т.к. первое, когда я загружаю архив, я именно этим и занимаюсь, т.е. все одно жду когда загрузится чтобы посмотреть что в нем, чего добавилось, а во вторых если работать в ней параллельно, обращаться к базе, то прога "вылетает" с ошибкой (AV вроде насколько помню), вот. т.е. чтобы архив загрузился нормально нужно ничего не трогать... (ну как раз об этом и предупреждения, трудно отследить).
ну вот, т.е. чаще всего мне и нужно ждать, и обязательно ждать иначе "глюкнет" (хотя, это уже второе дело).
и по моему было бы гораздо лучше если бы, было просто окно "идет загрузка" и блокирование всего остального. а если уж (нестандартный случай) хочется в этом момент что то старое смотреть, то не проблема запустить вторую копию программы (так не глючит, очевидно почему, процесс совсем другой). + если бы там не парились с "многозадачностью" обработка была бы немного короче (а может и намного, делая примерно тоже самое, на другой базе, но с теми же архивами я получал время в 3 раза меньше).

Игорь Шевченко (2010-03-14 12:32:00) [12]

> В момент, когда запускается "любая долгая операция" у пользователя
> должна быть возможность выполнить одно единственное действие
> - "отмена любой долгой операции".

Пользователь должен пойти спать, согласно [12]

Ega23 (2010-03-14 12:14:00) [13]

> Не порть чистоту расы.

Не мешай троллить.... :))))

Ega23 (2010-03-14 12:14:00) [14]

> Программист, вызывающий ProcessMessages, должен закладываться
> на то, что вместо ProcessMessages там может внезапно оказаться
> что угодно, в том числе и "долгая-процедура-два", и даже
> "долгая-процедура-один-еще-раз".

В момент, когда запускается "любая долгая операция" у пользователя должна быть возможность выполнить одно единственное действие - "отмена любой долгой операции".
Если программист такую логику не реализовал - это проблема программиста.
А плодить миллион тредов для каждой операции - ну можно и так, только следить внимательно надо и потокобезопасность везде применять.

Anatoly Podgoretsky (2010-03-14 12:10:00) [15]
> Вася (14.03.2010 11:11:26) [26]

Так это другая ошибка, программист знает что нельзя повторно нажимать кнопку, ни никакого противодействия не оказывает. У тебя какой то странный програмист, может пора его заменить более безопасным?

Anatoly Podgoretsky (2010-03-14 12:09:00) [16]
> Ega23 (14.03.2010 10:26:25) [25]

Не порть чистоту расы.

Вася (2010-03-14 11:11:00) [17]

> sniknik © (14.03.10 10:25) [24]

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

А возьмем другой пример: Человек нажал кнопку "долгая операция", а потом, через три минуты (процесс еще не завершен), нажал кнопку "другая долгая операция". Что получится - вторая операция начнет выполняться, а первая приостановится до окончания второй.
Врядли такая логика приемлема для большинства программ, тем более что с большой долей вероятности что-то прокосячит во время выполнения.

Я собственно к чему.
Программист, вызывающий ProcessMessages, должен закладываться на то, что вместо ProcessMessages там может внезапно оказаться что угодно, в том числе и "долгая-процедура-два", и даже "долгая-процедура-один-еще-раз".
Если бы он (программист) указал, какие именно сообщения надо отпроцессить, то он мог бы контролировать этот код, а так он его не контролирует. Я, собственно, об этом

Ega23 (2010-03-14 10:26:00) [18]

> В результате имеем программу с поистине великолепной логикой.

А можно ещё и объекты за собой не убивать. Чё-там, по завершении работы память всё-равно освободится...
Всё от программиста зависит. Даже Goto использовать можно.

sniknik (2010-03-14 10:25:00) [19]
Вася (14.03.10 10:03) [23]
а вот это уже явный логический глюк сделанный программистом... нельзя внутри блока локирования ресурсы вызывать "прерыватель", смысл локирования тогда? с тем же успехом можно "гнать" на критические секции, если вызвать внутри одной метод с попыткой занять туже секцию. (это вроде даже описано в статьях про дедлоки)
но ни критические секции ни ProcessMessages тут не виноваты, виноват программист написавший такое.
вынеси ProcessMessages за локирование и все будет в порядке.

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

Вася (2010-03-14 10:03:00) [20]
Application.ProcessMessages плох не тем, что якобы заметно перерасходует ресурсы процессора, а тем, что вставка в коде Application.ProcessMessages фактически равно вставке куска кода, выбранного почти случайно.
Что в ряде случаев приводит к интересным результатам. Например, имеем два метода:

procedure TMyObject.Method1;
begin
GlobalResource.Lock;
try
DoMethod1;
Application.ProcessMessages;
finally
GlobalResource.Unlock;
end
end;

procedure TMyObject.Method2;
begin
GlobalResource.Lock;
try
DoMethod2;
finally
GlobalResource.Unlock;
end
end;

В результате, если во время вызова Method1 в очереди есть сообщение, обработчик которого вызывает Method2, то Method2 попытается занять ресурс до того, как Method1 его освободил, и это при наличии одного потока.
В результате имеем программу с поистине великолепной логикой.

Страницы: 1 2 3 >

Наверх

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