Hilos en delphi 7

[duranguenze]

Saludos he estado buscando pero no le encuentro al asunto, tengo una aplicación que me va creando formularios, estos formularios los bloqueo por así decirlo para que no me abra mas de 1 a la vez, osea, si tengo un formulario que se llama registro, no me abrirá otro formulario registro, esto lo hago des habilitando el botón que me crea el formulario, cuando termina o el usuario cierra entonces destruyo este formulario, el problema viene cuando saco reportes, uso IB 5.x y no existe por ahora la posibilidad de migrar a otra versión mas reciente, he notado que a pesar de que he optimizado las consultas, todo mi programa se queda congelado, quisiera saber si se puede hacer que un formulario lo meta en un hilo diferente al de mi programa principal, para que al correr la consulta este trabaje como si abriera un ejecutable aparte, esto para permitir al usuario seguir trabajando sin problemas mientras termina su reporte.

[mamcx]

La VCL (asi como la mayoria de los toolkits graficos) no es thread-safe.

Osea, que no se puede garantizar el uso de controles VCL dentro de threads. Ademas, que realmente no es una buena idea

Lo que normalmente se hace es que ejecutas la parte *no visual* en un thread aparte y cuando obtienes los resultados, notificas al thread primario (osea, a la parte grafica) del resultado y procedes tal cual.

Para www.bestsellerapp.com queria ponerle la funcionalidad de detectar una nueva version sin obstruir al usuario o interrumpir las ejecuciones (bestseller tiene una parte que corre en el iPhone y un servidor Web hecho con RemObjects que corre en PC/OSX).

Busca en Google "delphi threads" para que te empapes bien. Es bueno que leas un rato ANTES de hacer nada. Este es de los temas que realmente saca canas...

Asi que necesitaba chequear la version en el servidor web y notificar si habia o no una actualizacion. Te paso lo que tengo hasta ahora pa que te des una idea:

1. Debes crear una clase que administre la ejecucion de la tarea dentro del thread. En mi caso, property Return es el dato que estoy esperando a que ejecute:

Código Delphi [-]
type
  TCheckUpdate = class(TThread)
  private
    FReturn: integer;
  protected
    procedure Execute; override;
  public
    property Return: integer read FReturn write FReturn;
  end;

Y debes implementar el EXECUTE, almacenando (de ser necesario) el resultado del calculo o proceso:

Código Delphi [-]
procedure TCheckUpdate.Execute;
var
  App: TAppConfig;
begin
  inherited;
  App := TAppConfig.Create;
  Return := 0;

  if App.UpdateAvailable then
  begin
    Return := 1;
  end else begin
    Return := 2;
  end;//if
end;

En algun lado, debes crear el thread y ponerlo a correr...
Piensa en el thread como un proceso "background":

Código Delphi [-]
procedure TfrmMain.actCheckUpdateExecute(Sender: TObject);
var
  NewThread: TCheckUpdate;
begin
  NewThread := TCheckUpdate.Create(True);
  NewThread.FreeOnTerminate := True;
  NewThread.OnTerminate := HandleTerminate;

  NewThread.Resume;

3. Un metodo donde recibes los resultados que esperabas:

Código Delphi [-]
procedure TfrmMain.HandleTerminate(Sender: TObject);
begin
  LogMsg('Cheking for new version..');
  if (Sender as TCheckUpdate).Return=1 then
  begin
    btnUpdate.Action := actUpdateServer;
    LogMsg('New version available. Please update the server');
  end else begin
    btnUpdate.Action := actUptoDate;
    LogMsg('Server is up to date!');
  end;//if
end;

[Neftali [Germán.Estévez]]

En el FTP del Club, en la sección de ejemplos, puedes encontrar alguno sobre threads.

Estoy de acuerdo con Mamcx en que el thread debe ser para realizar el trabajo necesario, por lo tanto, toda parte visual, componentes,... debe quedar fuera.

Por lo que se, si quieres realizar consultas dentro del Thread, debes tener en cuenta de no compartir las conexiones que tengas abiertas, es decir, que debes crear una nueva conexión dentro para lanzar la consulta.

[duranguenze]

Entonces para lograr lo que requiero es mas fácil hacer un ejecutable aparte y dejar que corra como loco, he logrado controlar otro ejecutable que se ha abierto gracias al titulo de la ventana, esto solo para maximizarlo o minimizarlo, claro, sabiendo como debe de ser; entonces, lo mas recomendable seria crear otro ejecutable para que corra independientemente en su propio hilo???

He estado leyendo al respecto de los hilos y creo que manejo bastante bien la teoría, lo malo que no he encontrado como hacer para meter el objeto en su propio hilo, al menos en delphi, se los riesgos que conlleva, y he encontrado que algunos navegadores usan hilos para las ventanas.

[[Chris]]

En el caso de los navegadores, no son hilos sino procesos por separados. Yo no te recomendaría que hicieras otro proceso para hacer lo que deseas. Es mejor que sigas y desarrolles la idea con los TThread's

Trabajar con los hilos no es díficil ya cuando aprendes lo básico, practicamente las reglas de seguridad para evitar excepciones vas de viaje.. a cómo decimos x aca. Sincermente lo más complicado es sincronizarlos. Yo por mi parte utilizo los mensajes de Windows para esta causa. Envio desde el Thread un mensaje a la aplicación principal y esta lo maneja cuando pueda hacerlo. Así se obtiene toda la ventaja del uso de hilos, y es la independencia de éstos de la aplicación principal y viceversa.

Saludos

[duranguenze]

el punto es que tendria que meter bastantes procesos en hilos, y se me hacia mas facil pensar que el cargador lo metiera en un hilo las ventanas que se que tardan porque corren reportes en ellas, entonces en conclusion he de decir que tendre que empezar a meter programacion para que los agarre en los hilos, Uff espera un gran trabajo, bueno almenos empezare con lo que vaya saliendo, ahora la pregunta que me hago, como meter los controles de interbase para que no me congelen mi aplicacion. (uso la 5.x y no hay posibilidad de cambiar a otra)

Bueno Chris, como hago eso de los procesos separados, en el firefox he notado que aveces se traba una sola pestaña y las demas andan bien :S

[Neftali [Germán.Estévez]]

Empezado por duranguenze

Entonces para lograr lo que requiero es mas fácil hacer un ejecutable aparte y dejar que corra como loco, he logrado controlar otro ejecutable que se ha abierto gracias al titulo de la ventana, esto solo para maximizarlo o minimizarlo, claro, sabiendo como debe de ser; entonces, lo mas recomendable seria crear otro ejecutable para que corra independientemente en su propio hilo???

No, creo que no. O yo al menos, no intentaba decirte eso.
La opción es hacer un thread aparte en tu programa principal, pero que no "metas el form en el Thread" como decías en tu primer mensaje, sino que crees el formulario en el thread principal y en el nuevo thread realices los trabajos que desees independizar.

[mamcx]

Empezado por duranguenze

el punto es que tendria que meter bastantes procesos en hilos, y se me hacia mas facil pensar ....

Ves?

Te dije (y en mayusculas!) que DEBES leer primero sobre el tema ANTES de implementar una solucion!

En serio!

El manejo multi-hilos es lo mas DIFICIL de la programacion (y por mucho - en comparacion punteros es facilisimo) ya que casi todos los lenguajes usan un modelo abrumadoramente ineficiente que lo hace mas dificil de lo que es!. PERO manejar 2 hilos? Es pan comido.

NO necesitas *muchos* hilos. Con lo que hablas seguro puedes con solo 2 (1 es el hilo principal, o sea la GUI, o sea, que no te preocupes por ello y el otro es el "background" en el cual haces las consultas).

O, si realmente se ejecutan consultas sucesivas (una detras de otra, tambien es facil. Igual sigues usando 1 sola clase de thread y metes los resultados en una lista manejandolo tipo Queue.

Asi que antes de intentes el modelo de ejecutar exes aparte (que es una solucion correcta, pero no en este caso) - y mucho menos como cuentas, asi no se hace - sigue el ejemplo que te di y el que te pasa neftali.

Es muy facil. En en el metodo execute creas la conexion, la consulta, lo ejecutas y guardas los resultados (preferiblemente con un TClientDataSet ya que debes desconectarte antes de retornar al otro thread, y asi no tendrias lios con la sincronizacion, que es la parte dificil de todo).