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

Вниз

Как вывести сообщение об ожидании выполнения операции?   Найти похожие ветки 

 
well ©   (2012-05-23 11:20) [0]

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

Пытался сделать с помощью Label перед запуском операции, но надпись не появляется до завершения процесса; То же самое если я устанавливаю Visible метки в True и.т.п. Даже если я между сообщением и операцией ставлю цикл(для задержки), надпись всё равно не появляется.

Как организовать правильно сообщение о необходимости ожидания конца операции?


 
Медвежонок Пятачок ©   (2012-05-23 11:27) [1]

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


 
Давайте будем жрать!   (2012-05-23 11:27) [2]

После изменения лейбла вызывай Label1.Update. Более универсальный вариант — вызывать application.ProcessMessages, но в данном случае это излишне.


 
Юрий Зотов ©   (2012-05-23 11:33) [3]


> well ©   (23.05.12 11:20)

Самый лучший вариант - вынести длительную обработку в отдельный поток.


 
oldman ©   (2012-05-23 12:34) [4]

FormN.ShowModal

На форме сообщение "Ждите"
На FormN.OnShow твой длительный процесс.
После окончания процесса FormN.Close.


 
Loginov Dmitry ©   (2012-05-23 12:49) [5]

Неплохой вариант: [3] + [4]


 
well ©   (2012-05-23 14:09) [6]

Спасибо!
Буду пробовать.


 
Ega23 ©   (2012-05-23 16:06) [7]


> Пытался сделать с помощью Label перед запуском операции,
>  но надпись не появляется до завершения процесса;


Screen.Cursor := crHourGlass;
try
 Label1.Caption := "Bla-bla-bla 1";
 Application.ProcessMessages;
 for i := 0 to 100000000 do ....;
finally
 Label1.Caption := "Bla-bla-bla 2";
 Screen.Cursor := crDefault;  
end;


 
Dennis I. Komarov ©   (2012-05-23 19:28) [8]


> Ega23 ©   (23.05.12 16:06) [7]

Не, не согласен. Окно должно обрабатывать сообщения даже при долговременных операциях. В поток ее...

TAction(Self).Enable:=false;
TAnyThread.Create...
+ добавить логику на запрет создания второго потока, если надо;
+ возвращать данные о процессе выполнения процедуры в ГУЙ;
+ логику досрочного прекращения операции и разбанивания экшина;


 
Ega23 ©   (2012-05-23 22:10) [9]


> Не, не согласен. Окно должно обрабатывать сообщения даже
> при долговременных операциях. В поток ее...


Вот совершенно необязательно. А сообщения обрабатывать - передавай Callback для прогресса, в нём и ставь тот самый ProcessMessages


 
Dennis I. Komarov ©   (2012-05-23 23:26) [10]


> Ega23 ©   (23.05.12 22:10) [9]

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


 
Ega23 ©   (2012-05-24 00:20) [11]


> но желательно... (если оно надо)


Если надо - то безусловно. Зависит от логики. Если следующее действие может быть выполнено только по завершении текущего - то не надо. Если может быть выполнено в любой момент - то надо.


 
Германн ©   (2012-05-24 00:36) [12]


> Ega23 ©   (24.05.12 00:20) [11]

Даже если не надо, то во-первых зачем Application.ProcessMessages? Наследники TControl имеют методы немедленной перерисовки Repaint & Refresh. А во-вторых это всё-таки очень некрасиво в многозадачной среде.


 
TStas   (2012-05-24 00:47) [13]

Если длительные процесс - это цикл, то запихать с некоторой периодичностью Application.ProcessMessages. Как пишет Юрий Зотов - это оптимальный вариант, но потоки противны в отладке. Я отлаживал поток так: вначале отлаживал его в основном потоке, при этом, конечно, всё висело и сообщения не обрабатывались, а потом, когда косяки были убраны, пихал код в код поток. Самое неприятное в потоках, что они не могут прямо обращаться к процедурам, изменяющим внешний вид, а только через Syncronize, который сильно тормозит сам поток.
>Германн А если во время работы пользователь пронёс мышью окно какого-то другого приложения над работающим окном? Сообщение об этом окно приложения не сможет получить и будет испоганено. ИМХО именно за этим Application.ProcessMessages


 
Германн ©   (2012-05-24 00:52) [14]


> Германн А если во время работы пользователь пронёс мышью
> окно какого-то другого приложения над работающим окном?
> Сообщение об этом окно приложения не сможет получить и будет
> испоганено. ИМХО именно за этим Application.ProcessMessages

Посмотри внимательно код в Ega23 ©   (23.05.12 16:06) [7]
А потом ещё раз мою вторую фразу. :)


 
Ega23 ©   (2012-05-24 02:50) [15]


> Даже если не надо, то во-первых зачем Application.ProcessMessages?
>  Наследники TControl имеют методы немедленной перерисовки
> Repaint & Refresh.


Иметь-то они имеют. Вот только перерисовываться будут только они.


unit Unit20;

interface

uses
 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
 Dialogs, StdCtrls;

type
 TForm20 = class(TForm)
   Label1: TLabel;
   Button1: TButton;
   procedure Button1Click(Sender: TObject);
 private
   { Private declarations }
 public
   { Public declarations }
 end;

var
 Form20: TForm20;

implementation

{$R *.dfm}

procedure TForm20.Button1Click(Sender: TObject);
var
 i: Integer;
begin
 for i := 1 to 10 do
 begin
   Label1.Caption := IntToStr(i);
   Label1.Refresh;
//    Application.ProcessMessages;
   Sleep(500);
 end;
end;

end.


Попробуй развернуть окно c Refresh и с PM.


> А во-вторых это всё-таки очень некрасиво в многозадачной среде.


Красивость - мнение субъективное.


 
Германн ©   (2012-05-24 03:36) [16]


> Ega23 ©   (24.05.12 02:50) [15]
>
>

Олежка. Вот только "передёргивать" не надо! Я знаю всю колоду! :)
Ты что предложил в "Ega23 ©   (2.05.12 16:06) [7]"?


 
Давайте будем жрать!   (2012-05-24 07:52) [17]


> Вот только перерисовываться будут только они.
Автор именно это и спрашивал. :-)


 
Dennis I. Komarov ©   (2012-05-24 20:11) [18]


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

не их ума дело, а на синхронизе свет клином не сошелся...


 
Dennis I. Komarov ©   (2012-05-24 20:15) [19]


> Если надо - то безусловно. Зависит от логики. Если следующее
> действие может быть выполнено только по завершении текущего
> - то не надо. Если может быть выполнено в любой момент -
>  то надо.

Конечно зависит, но согласись что с т.з. ГУЯ оно намного приятнее, а запретить следующее действие можно и другой логикой, если надо.



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

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

Наверх





Память: 0.5 MB
Время: 0.072 c
2-1343048239
DevilDevil
2012-07-23 16:57
2013.03.22
Очередь потоков


15-1333057317
Германн
2012-03-30 01:41
2013.03.22
Взаимодействие 64-х битного приложения с 32-х битной библиотекой


15-1342693823
.dmitry
2012-07-19 14:30
2013.03.22
Произошел сбой программе инициализации библиотеки динамической ко


2-1335038569
novichek
2012-04-22 00:02
2013.03.22
TZipFile


2-1337876849
Тарас
2012-05-24 20:27
2013.03.22
Веб Браузер





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский