![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|
|
#1
|
||||
|
||||
|
¿Has probado lo que propones? Recuerda que el amigo necesita cerrar el formulario luego de terminado el proceso.
// Saludos |
|
#2
|
||||
|
||||
|
Sí... Me parece que no entiendo bien lo que quiere hacer, entonces.
Lo que yo digo es que si va a mostrar el formulario, hacer una serie de cosas pesadas y después cerrarlo. Porqué no hacer un refresh o repait del formulario después de mostrarlo y antes de empezar a hacer las cosas pesadas. Digo, eso es los que yo he hecho siempre. Por eso aclaro, quizá yo esté entendiendo mal el asunto... |
|
#3
|
||||
|
||||
|
Tuve que ausentarme unas horas.
Tras leer lo que se vino diciendo aqui, yo estoy con roman. El form principal es que quien se encarga de hacer el trabajo duro. Hacer que el form modal haga ese trabajo rompe con el esquema para el cual fueron concebidos: pedir una "confirmación" rápida. Saludos, |
|
#4
|
||||
|
||||
|
Ahora yo.
El Close no tiene efecto en el onActivate, porque la forma modal no ha entrado en el ciclo que hace HandleMessage. Pues, como exponen los compañeros del foro, por definición las formas modales no están para comportarse así. De todas maneras y según entiendo, hay dos opciones prácticas para "forzar" esto, que a la larga pueden ser similares, pero Ud. escoge:
__________________
"constructive mind, destructive thoughts" |
|
#5
|
||||
|
||||
|
Cita:
La llamada a Show generará el evento OnShow mientras que el mensaje CM_ACTIVATE generará el evento OnActivate, antes de entrar al ciclo repeat-until, como bien señala nuestro amigo TOPX. Ese ciclo sólo termina cuando el valor de ModalResult es distinto de cero y aunque Close lo que hace es poner ModalResult en mrCancel (<> =0), lo hace antes de la inicialización a cero de la variable justo antes de comenzar el ciclo. Ahora bien, si se insiste en dejar el proceso de descarga en el formulario modal, entonces pueden usar el método del AfterShow. Aquí un ejemplo:
PostMessage coloca un mensaje en la cola de mensajes de la aplicación, que no se procesará sino hasta que -justamente- se entre al ciclo de mensajes y HandleMessage lo tome. Trasladamos entonces, todo el proceso al manejador del mensaje que mandamos, en donde ya se puede usar Close sin ningún problema. // Saludos |
|
#6
|
||||
|
||||
|
Uff bastante información me habeis reportado, creo que voy a necesitar reflexionar un poco para comprender todo lo expuesto y actuar en consecuencia, aunque lo mas facil que veo es la primera opcion, dejar el trabajo duro al formulario princial como dice roman... es lo mas facil aunque me entran ganas de investigar todo lo que me habeis expuesto como el aftershow que no conocia hasta ahora...
Voy a investigar un poco y os cuento, muchas gracias por vuestra ayuda, ya he aprendido otra cosa más hoy ![]()
__________________
Borland Delphi XE2 // Interbase Server |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| TClientDataSet problemas open-close | delphijm | Conexión con bases de datos | 2 | 26-05-2008 03:16:37 |
| Close Querys | Loviedo | Firebird e Interbase | 2 | 30-06-2005 23:39:33 |
| Self Close | Telmito | Varios | 3 | 06-01-2005 17:05:41 |
| Application.Terminate Vs Close | neon | Varios | 2 | 30-07-2004 00:11:55 |
| Refresh contra close-open | AbcXxx | Firebird e Interbase | 3 | 18-06-2003 17:45:20 |
|