Thread y showmodal
 

Hola a todos, tengo un pequeño problema que no consigo resolver y agradeceria alguna ayuda.

Tengo una tabla con '0' a 'n' registros que se lee en un thread en el que se debe lanzar una modal por cada registro mientras haya, la modal tiene un bitbtn con Close en OnClik.

El problema consiste (supongo) en el cerrado de la modal, ya que cuando se cierra la primera, se para el bucle

Código del Thread:

En create () he probado con self, nil y application, el resultado es el mismo.

Con se para el bucle que quieres decir que se congela la aplicacion y el programa no sigue corriendo.

El showmodal deberia funcionar, el evento onclick te lo puedes ahorrar con la propiedad modalresult del bitbtn.

El codigo no es exactamente lo que has puesto no?, porque

Código Delphi [-]
Form23 := TForm23.Create(self)

deberia ser

Código Delphi [-]
Form23 := TForm.Create(self);

y no creas el bitbtn vinculado al formulario que creas.

Ante todo, gracias por tu respuesta.
El resultado de cambiar Tform23 por Tform, tal como indicas, es el siguinete :

[DCC Error] Principal.pas(491): E2010 Incompatible types: 'TForm23' and 'TForm'

El formulario que tiene el botón (salir), es el Form23, ya que este debe crearse automaticamente cona cada nuevo registro de la tabla.
El Form23 muestra el contenido de algunos campos de la tabla

Se me olvidaba.
Cuando digo que se detiene el bucle, es que sólo se detiene el bucle de lectura de la tabla, la aplicación, que tiene otro thread que alimenta la ADOTable2 sigue funcionando, aunque no se generan las modal.

En una nueva prueba (sin Onclick) y despues de aparecer y cerrar la segunda pantalla, se para el bucle. Cierro la aplicación y me da el siguiente error :

Exception class EOSError with message 'System Error. Code: 1400.
El identificador de la ventana no es válido'.

Perdon pense que lo creabas todo en ese procedimiento y solo habias puesto un ejemplo.

Se me ocurren dos cosas que destruyes el hilo con lo cual acabas el procedimiento o que utilizas la tabla y pase el puntero al ultimo registro con lo cual se acaba el bucle.

He hecho algunas pruebas y a mi me funciona todo bien, tal vez el fallo este en otro parte del codigo pero no me hagas mucho caso lo mas probable es que mis conocimientos de novato no den para mas.

A ver si alguno le expertos compañeros de estos foros te ayuda mejor que yo.

Un Saludo

A esas mismas conclusiones habia llegado yo, pero por mas que miro no veo como resolverlo. Aunque haciendo pruebas he podido ver que cuando cambio de la pantalla base a otra mediante el menú principal, la pantalla modal vuelve a aperecer, la cierro y adios. si vuelvo a la pantalla inicial a traves de menú, se repite la historia y asi hasta el final del bucle.
Es evidente que al cerrarse la modal, no se refresca hasta que hay otro cambio de form.

Hola,

Estaría bien que pongas el código del OnClick de ese BitBtn, pero por lo que entiendo haces simplemente un Close. Prueba a darle un modalresult a ese BitBtn tal que mrOK.

Espero te sirva.;)
Saludos.

En estos momentos el bitbtn, no tiene OnClick.
En Miscellaneous tiene los valores

Default = True
ModeResult = mrOK

Supongo que ya has lo has intentado pero intenta depurar, pon un punto de ruptura en el bucle y ve ejecutando paso a paso a ver que hace donde va la ejecucion una vez parado el bucle.

Yo no sé ni por donde entrar a este tema. No te lo tomes a mal, solo voy a enumerar los posibles fallos/defectos que le veo a la implementación actual:

1 - Crear una ventana por cada registro existente en la tabla es demasiado; si hay 40 registros.... ¿40 ventanas que el usuario tiene que hacer clic?¿para qué? si no se le deja eligir nada al usuario, acto seguido se borra el registro por código delphi.

2 - No veo que se destruya la ventana Form23 por ningún lado, hay varias formas, pero lo más fácil sería en el OnClose de TForm23 añadir :

Código Delphi [-]
action := cafree;
Form23:= nil;

3 - El "Adotable2.Next" sobra, ya que al borrar un registro, automáticamente se muestra el siguiente en los controles DBAware, si además hacemos un .Next, estamos saltando un registro sin borrarlo.

Y todo esto sin entrar en diferentes hilos de ejecución, concurrencia, etc. Por que si el Thread está borrando registros, no quiero saber lo que hará la aplicación principal con otro Adotable que intente editar esos registros ya borrados.

Si quieres informar al usuario que se ha borrado 20 registros, hazlo así:

Código Delphi [-]
const Linea = ' Llave Primaria : %s, Campo1 %s, Campo2 %s'+ #10#13;
Mensaje :string;
begin 
  Mensaje := 'Se han borrado los siguientes registros'+ #10#13;
//  no estoy seguro que Recordcount dé el valor que esperas, al menos en los 
//  foros siempre se ha dicho que devuelve -1. Compruébalo.
if not(ADOtable2.IsEmpty) then 
   begin
   ADOTable2.First;
    while  not ADOtable2.eof  do
      begin
        Mensaje := Mensaje + Format(linea, 
                                            [ adotable2CampoLLave.Value,
                                            adotable2CAmpo1.Value,
                                            adotable2Campo2.Value ]);
        ADOTable2.Delete;
      end;
     ShowMessage(Mensaje);
   end;

En lugar de un ShowMessage, podrías mostrar un Form con un Memo, dentro del memo añade ese "mensaje", será más cómodo para el usuario.

Campo1, CAmpo2, son dos campos que quieres mostrar al usuario para que entienda el mensaje, por ejemplo el número de factura que se ha borrado o el nombre del cliente que se ha borrado (es un ejemplo, claro).


De esta forma, el usuario no tiene que hacer clic en ninguna ventana, pero tiene el resumen de lo que ha pasado.

Espero te sirva, Saludos.

Intentaré explicarme algo mejor

- El primer thread genera esta tabla con determinados registros de otra para no parar el proceso mientras se responde a las pantallas mostradas
- El segundo thread debe mostrar la información al usuario, quien debe confirmar en la modal el enterado y entonces se borra el registro.
- como caso excepcional debiera haber a lo sumo 4 o 5 registros en espera de respuesta, con lo que si las pantallas quedasen anidadas, miel sobre ojuelas.
-Que se intente grabar en la tabla justo en el mismo instante en que se borra?
-Pude ser un riesgo, pero, no se me ocurre otra forma de disparar un aviso automatico, cuando se graba 1 registro en la tabla que no sea, con un thread preguntando permanentemente

Un ejemplo (no real) para entender mejor lo anterior, pdria ser:

Un contador númerico, va grabando su contenido en una tabla, conforme incrementa su valor.
Determinados valores (aleatorios) de esa tabla generan un aviso, que debe ser confirmado por un usuario, pero en tanto el usuario responde el contador no debe parar y seguir incrementando su tabla.

No voy a criticar tu forma de interactuar con el usuario, auque como h a dicho lepe, puede ser un poco incomodo estar haciendo clic, clic, clic.....

Fijate que lo que te sucede es cuando un thread termina repentinamente es porque ha ocurrido una acepción en este y normalmente delphi no te informa sobre las ecepciones en los threads [solo cuando estás en modo debugger].

Exception class EOSError with message 'System Error. Code: 1400.
El identificador de la ventana no es válido'.

esto sucede a como lo ha dicho lepe a que no destruyes la ventana a utilizar.
A mi punto de vista tienes dos alternativas:
Esta es la que te recomiendo:

Código Delphi [-]
procedure TForm2.IdThreadComponent2Run(Sender: TIdThreadComponent);

begin
if ADOtable2.RecordCount > 0 then
   begin
   ADOTable2.First;
   Try
   Form23 := TForm23.Create(self);
    while  not ADOtable2.eof  do
      begin
        Form23.showModal;
        ADOTable2.Delete;
      //  ADOTable2.Next;
      end;
    Finally
    Form23.Free;
    end; 
   end;
end;

Ó:

Código Delphi [-]
procedure TForm2.IdThreadComponent2Run(Sender: TIdThreadComponent);

begin
if ADOtable2.RecordCount > 0 then
   begin
   ADOTable2.First;
    while  not ADOtable2.eof  do
      begin
        Form23 := TForm23.Create(self);
        Form23.showModal;
        ADOTable2.Delete;
      //  ADOTable2.Next;
        Form23.Free; 
      end;
   end;
end;

En algunas empresas, es el modelo de trabajo; como es requerido por los jefes, los usuarios deben dar el clic. Dicho de otra forma: "los jefes quieren tener a una persona que culpar de cualquier fallo :D".

No había caído en ese detalle, gracias por la aclaración.

Saludos

Ante todo quiero darte las gracias por el interes mostrado, al intentar colaborar conmigi.

DRAW,
gracias por tu aportación, debo decirte que de tus dos opciones, la primera con un pequeño retoque parece que funciona, con la peueña salvedad que la modal no se actualiza. Supongo que es porque al quedar fuera del while, loscampos de la modal que por defecto estan basados en la tabla no se reinicializan.
Voy a probar a dar valor a los campos antes de llamar a la modal.

saludos

Y tu crees que nosotros estamos aqui esperando a ver quien entra para solucionarle la vida y de paso para que un vulgar pretencioso quiera venirnos a decir que el si es profesional y no esta de ocioso:confused::confused::confused:, aqui los conocimientos se comparten de la misma forma que se tiene sentido del humor, he leido lo que nuestro amigo Lepe te ha comentado y francamente no veo el porque de tu diparatado comentario, no solo ofendes a Lepe que dista mucho de ser lo que dices, hay que investigar antes de hablar, sino que estas ofendiendo a todo el foro porque efectivamente, Lepe es de los que le dan vida y representa dignamente el foro.

Vaya lo quer tiene uno que leer en esto dias, :mad:

Justo te quejas de lo que yo me quejo:

HAY QUE INVESTIGAR ANTES DE HABLAR

Si así lo hubiese hecho tu amigo, no tendríamos que andar a la greña.

En cualquier caso no he hecho extensivo mi comentario a otros participantes del foro, y si te sientes ofendido, perdona poruq no iba contigo.

Y espero que comprendas que cuando te tiras 12 horas diarias tecleando, estas lo suficientemente cansado como para, andar con segun que interpretaciones
PD. Durante bastantes años he sido representante y defensor de los derechos de los trabajadores, con lo que la bromita me ha picado doblemente.

Vamos por partes, primero que nada no soy gustoso de las interpretaciones, las cosas son como son y nadamas

Para ti Lepe es un ocioso, yo digo no lo es y me baso en la simple y sencilla razon de sus participaciones en el foro, no creo que acabes de leer las 5,409 que tiene hasta este momento, sin decir la calidad de sus respuestas.

Insisto, SI representa al foro y el foro somos todos, incluyendote a ti.

Como ves yo no interpreto nada, tu lo dices con todas las letras.

Yo comprendo eso mismo que dices, yo trabajo igual o mas que tú, incluso bajo las presiones que gustes y mandes, no eres él único

En fin, lo dicho, las cosas son como son.