28 respuestas en este tema

[cHackAll]

Es muy común que nuestras aplicaciones aparenten estar “colgadas” cuando realizan alguna operación compleja; dicha operación puede ser realizada por el sistema operativo al haberse llamado a una determinada API, en la espera de la finalización de un “Commit” por un motor de base de datos, por que “cargamos” con una montaña de información a un componente de terceros o por otra razón.

Cuando la causa de dicho problema es un bucle que el propio programador ha escrito, comúnmente opta por llamar a “Application.ProcessMessages” en cada repetición para ir liberando la cola de mensajes, con lo cual WM_PAINT, WM_MOUSEMOVE y otros mensajes, al ser procesados refrescan el estado de la ventana. Conociendo también el inicio y el final de dicho proceso incluimos una barra de progreso en la aplicación y junto a la ya citada llamada solucionamos el problema.

Pero cuando la operación dura un tiempo indeterminable y/o es imposible incluir dicha llamada porque el “bucle” se encuentra en un lugar inaccesible, llega a ser complicado asegurarse que el usuario sepa que la aplicación está “ocupada” y no puede responde adecuadamente.

Las aplicaciones se quedan “colgadas” porque el hilo principal (el encargado de procesar los mensajes) no puede procesar la cola de mensajes porque está “ocupado”. En dicho contexto la solución sería “introducir” el proceso “complicado” en un hilo adicional pero esto puede llegar a ser todo una hazaña. Tampoco es aconsejable procesar los eventos desde otro hilo porque comúnmente hacemos aplicaciones que trabajen en varios hilos.

Para solucionarlo adjunto una unidad que implementa dos funciones, la primera se encarga de crear una nueva ventana de progreso compatible con las últimas versiones de Windows en un hilo nuevo, el cual procesa sus propios mensajes mientras nuestra aplicación se encuentra realizando una determinada operación. La segunda llamada cierra dicha barra de progreso utilizando un evento como método de sincronización con el hilo previamente creado.

Ejemplos;

delphi

uses _Busy;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
BusyBegin('Haciendo "algo"...', Handle);
 
// ReadFile(hCOM, Buffer, SizeOf(Buffer), Count, nil);
// StartService(hService, 0, PPChar(0)^);
// connect(hSocket, name, SizeOf(Addr));
// Busca('xxx*.mp*');
// Hell.CommitTrans;
// etc, etc...
Sleep(6666);
 
BusyEnd;
end;

delphi

program Delphi2010;
 
uses
Forms, _Busy,
Unit1 in 'Unit1.pas' {Form1};
 
begin
Application.Initialize;
BusyBegin('Iniciando...', Application.Handle);
Application.CreateForm(TForm1, Form1);
Application.CreateForm(TForm2, Form2);
Application.CreateForm(TForm3, Form3);
Application.CreateForm(TForm4, Form4);
Application.CreateForm(TForm5, Form5);
Application.CreateForm(TForm6, Form6);
// ...
BusyEnd;
Application.Run;
end.

Enjoy!

Archivos adjuntos

•  _busy.pas   2,18KB   32 descargas

[Caral]

Hola
Gracias amigo, siempre con estos aportes geniales.
Saludos

[egostar]

Hey

El viernes precisamente estabamos enecumeme y yo viendo un asunto con su programa MTF que está elaborando y teniamos este problema al ejecutar una DDL en un script queriendo mostrar "algo" mientras se ejecutaba y terminamos por claudicar :$.

Y vaya que esta es la respuesta a ese penoso asunto :$

Muchas gracias brother.

Salud OS

[Kipow]

Buen aporte, todo con tal de que los usuarios impaciente no nos cierren la aplicacion por no saber que esta trabajando. me parece excelente la opcion.

[eduarcol]

muy bueno, 

[cHackAll]

Gracias a todos, solo me queda comentar que en el pasado publique una version previa de "_Busy" que es más robusta y tiene algunas fallas.

Salud!

[Caral]

Hola

Gracias a todos, solo me queda comentar que en el pasado publique una version previa de "_Busy" que es más robusta y tiene algunas fallas.

Salud!

Ah, entonces el zip debería de poner Versión: _Busy.1.2  (sin fallas)
Esto con el fin de irnos actualizando con las versiones.
Saludos

[Delphius]

Hola,
Es de admirar lo que haces.
Ya me gustaría poder tener la décima parte de tus conocimientos.

No entiendo mucho el código, pero seguramente funciona a las diez mil maravillas ... tendré que probarlo, ver como se comporta y estudiar las API involucradas.

De forma un tanto resumida, y pobre de lo que podría llegar a comprender... lo que tu código hace ¿es valerse de un hilo y ponerse a la escucha de la cola de mensajes y actuar en consecuencia, mientras "actualiza" la pantalla?

Entiendo que "centraliza" todo en un sólo lugar, de ese modo se evita dispersar hilos y ProcessMessages; más el código me confunde más que un poquito .

Saludos,

[cHackAll]

Hola

Gracias a todos, solo me queda comentar que en el pasado publique una version previa de "_Busy" que es más robusta y tiene algunas fallas.

Salud!

Ah, entonces el zip debería de poner Versión: _Busy.1.2  (sin fallas)
Esto con el fin de irnos actualizando con las versiones.
Saludos

Pues la versión antigua es funcional, tiene una barra de progreso dibujada por mi lo que ya no se ve tan bien en Vista & Se7en. También están un buen numero de errores que tan solo ahora puedo notar y corregir :$.

En todo caso queda la diferencia en las fechas de publicacion y la anterior aclaración.

Hola,
Es de admirar lo que haces.
Ya me gustaría poder tener la décima parte de tus conocimientos.

Gracias Delphius, espero te sea util

...lo que tu código hace ¿es valerse de un hilo y ponerse a la escucha de la cola de mensajes y actuar en consecuencia, mientras "actualiza" la pantalla?

Entiendo que "centraliza" todo en un sólo lugar, de ese modo se evita dispersar hilos y ProcessMessages; más el código me confunde más que un poquito .

Saludos,

Técnicamente el hilo que crea BusyBegin crea a su vez una nueva ventana con su propia cola de mensajes, al ser totalmente independiente de nuestra aplicación funcionará aunque la nuestra este "casi" colgada.

Trabajando con APIs (GetMessage y DispatchMessage) no "existe" la necesidad de involucrarse con la VCL (Application.ProcessMessages), lo que nos permite usar la unidad hasta en una aplicación tipo consola.

Asi mismo el SO se encargará de dar todo el efecto visual y de procesar como debe de ser todos los mensajes propios de la clase "msctls_progress32".

Salud!

[Rolphy Reyes]

Excelente, gracias por tu aporte.

Veo que utilizas 100% los mensajes para conseguir tu cometido (por lo menos eso creo).

[Rolphy Reyes]

Saludos.

Encontré este hilo que en cierto modo hace referencia a lo comentado por cHackAll.

[Delphius]

Saludos.

Encontré este hilo que en cierto modo hace referencia a lo comentado por cHackAll.

Hola Rolphy,
Si me disculpas, me tomé el atrevimiento de modificar el link. Tenía una "basurita" al final .

[cHackAll]

Excelente, gracias por tu aporte.

Provecho!

Veo que utilizas 100% los mensajes para conseguir tu cometido (por lo menos eso creo).

Pues es un tema de procesamiento de mensajes.

...Encontré este hilo que en cierto modo hace referencia a lo comentado por cHackAll.

This issue is simple; main project (.dpr) into the main thread calls an Application.Run, this method enters in a loop and calls each time the method Application.HandleMessages doing something like this “if not Application.ProcessMessage then OnIdle”.

Then, if the message queue is empty OnIdle will be called and call ProcessMessage with an empty messages queue is an stupid idea.

Con respecto a algun comentario de dicho enlace, he podido ver algun nivel de verificacion del MainThreadID en la VCL (multi-threading), pero tengo mis reservas.

Salud!

[enecumene]

Hola ChackAll, muy interesante el código, intenté aplicarlo en una de mis aplicaciones y obtengo estos errores:

  [Error] WARNING. Duplicate resource(s):
  [Error]  Type 24 (user-defined), ID 1:
  [Error]    File c:\program files\borland\delphi7\Lib\WindowsXP.RES resource kept; file c:\program files\borland\delphi7\Lib\WindowsXP.res resource discarded.

¿Qué podría ser?, ¿qué hago mal?.

Saludos.

[cHackAll]

He reemplazado el adjunto del primer post anulando dicho recurso, gracias por hacermelo notar.

Salud

[enecumene]

Excelente amigo, ahora sí, me ha encantado, funciona de "Pelos" .

Saludos.

[JandoK]

Hola  Mr. Creador de esta herremienta ... [ léase cHackAll ] 

Tengo un detallito con dicha Unit, para generar la ventanita de 'Busy' ...

Por el principio... Tengo una ventana (Form1) ... en la cual creo dinamicamente en el evento OnShow
varios componentes TCheckBox, en relacion a los valores que tengo almacenados en una Tabla.
Como dichos valores estan divididos por categorias, entonces tengo:

CATEGORIA    VALOR
        1              A
        1              B
        1              C
        2              D
        2              E
        3              F
        3              G
        4              H
        5              I

Mi idea es agragar TODOS los TCheckBox (que vienen a ser todos los datos del campo VALOR) ... de un color
diferente, dependiendo de la CATEGORIA a la que correspondan.  Esta parte YA esta resuelta (creo) .

delphi

procedure TfrmInsertarVarios.PonerCheckboxs(catnum, catnom, tipnum, tipnom : string);
var
  chkbxNombre : string;
begin
  chkbxNombre := 'Estudio' + catnum + tipnum;  // el nombre del componente es 'Estudio' + CATEGORIA + VALOR
  TCheckBox.Create(Self).Name := chkbxNombre;
  
  with TCheckBox(FindComponent(chkbxNombre)) do
  begin
    Font.Style := [fsBold];
    Font.Color := ListaColores[StrToInt(catnum)];  // este es un Array con los colores que va a tomar cada CATEGORIA
    Left := chkbxLeft;
    Top := chkbxTop;
    Visible := True;
    Caption := tipnom;
    Checked := False;
    Width := chkbxCalcularAncho(tipnom); //una funcion para adecuar el ancho del TCheckbox y mostrar todo el valor del Caption
    Parent := frmInsertarVarios.sbEstudios;   //sbEstudios es un componente TScrollBox
  end;
end;

El detalle surge con LOS COLORES de la fuente del TCheckBox, si NO agrego la unidad '_Busy'
los TcheckBox si toman los colores. Pero si agrego el '_Busy', la fuente de los TCheckBox NO
cambia, se queda en negro (color por default) ...

Espero haberme dado a entender...  y haber si me pueden ayudar para ver que esta mal 

Gracias...

Salu2!!!!!!!

[cHackAll]

Hola JandoK, a mi me funciona 8-)

delphi

uses _Busy;
 
procedure TForm1.Button1Click(Sender: TObject);
const ListaColores: array [0..5] of TColor = (clRed, clYellow, clGreen, clBlue, clPurple, clSilver);
var Index: Integer;
begin
 for Index := Low(ListaColores) to High(ListaColores) do
  with TCheckBox.Create(Self) do
   begin
    Font.Style := [fsBold];
    Font.Color := ListaColores[Index];
    Caption := 'Muestra todo el codigo necesario!!!  x' + IntToStr(Index);
    Left := 10;
    Top := Index * 12;
    Visible := True;
    Width := 666;
    Parent := Self;
  end;
end;
 
procedure TForm1.Button2Click(Sender: TObject);
begin
 BusyBegin('Ctrl+C imposible!');
 Button1Click(nil);
 BusyEnd;
end;

[JandoK]

no pues nop ....

asi como TU lo tienes, NO pone los Checkbox del respectivo color... 

solo me toma el estilo  (Bold) ...

en fin... seguire buscando donde esta el detalle.... (por que ahora, aunque no tenga agregada la unidad _Busy ... Sigue SIN TOMARME en cuenta el color  )

gracias...

salu2!!!!!!!

[cHackAll]

no pues nop ....

He reemplazado el adjunto del primer post anulando dicho recurso...

Descarga _Busy.pas nuevamente... es un tema relacionado con los themes del Gí¼indos, NO con _Busy!