ActiveFiX

Artículo original: ActiveFiX
http://www.foxpert.com/knowlbits_200801_1.htm
Autor: Christof Wollenhaupt
Traducido por: Ana María Bisbé York 

---

Los controles ActiveX no trabajan bien con formas modales de VFP. Bien, esto no es exactamente una gran sorpresa para nadie que lo haya intentado. Si contacta con el creador de un control ActiveX terminará recibiendo una de estas dos respuestas:

"Nuestros controles funcionan en todos los entornos soportados. ¿Qué es Visual FoxPro?" o "Váyase por ahí. Nosotros no escribimos código deficiente" Incluso los controles que funcionan bien con VFP, como los controles del dbi muestran este comportamiento.

¿No podemos hacer que los proveedores solucionen esto? Admitámoslo, no es su error, es un problema de Visual FoxPro. En realidad no es un error, es un problema de diseño. Uno de los problemas que tiene que resolver el FoxTeam con las ventanas modales que simplemente no existe en Windows API. OK, lo vemos; pero esto no significa que es real.

Windows crea una ventana modal inhabilitando la ventana padre. Esto trabaja bien en un único nivel de ventanas modales como es el caso de una ventana de diálogo. Sin embargo, con ventanas (o formularios) que pueden ser modales, puede ser con formas múltiples en un conjunto de formulario que mantenga accesible mientras otras ventanas no, las cosas se tornan más confusas.
Entonces, lo que ocurre con los controles ActiveX es que realmente se agregan dos ventanas al formulario. La más afuera es la ventana del OLE que guarda la ventana que es un control de Visual FoxPro. Dentro de esta ventana anfitriona, el control ActiveX crea su(s) propia(s) ventana(s) que se mantienen bajo el control del control ActiveX. La ventana interior (o ventanas) es lo que conocemos como "control ActiveX".

Cuando usted muestra una ventana modal, Visual FoxPro inhabilita la ventana anfitriona de todos los otros formularios. El control ActiveX de dentro permanece activo; pero no recibe ninguna entrada de usuario, porque la ventana padre está deshabilitada. Como resultado, el control no responde al ratón ni a eventos de teclado, ni recibe el foco. Sin embargo, continúa funcionando. Por ejemplo, se puede actualizar a sí mismo, responder a otros eventos y cosas así.

Una vez que el usuario cierra la ventana modal, Visual FoxPro activa todas las ventanas anfitrionas que fueron desactivadas. Mi apuesta (en realidad lo que yo creo) es que Visual FoxPro guarda el estado anterior cuando inhabilita la ventana OLE y lo restablece cuando la habilita. El control recibe el mensaje y responde las entradas de usuario. Bueno, esto es lo que ocurre justo en el primer nivel de los formularios modales.

Sin embargo, parece que hay solamente una variable para mantener el estado anterior habilitado para cada ventana OLE anfitriona. Entonces cuando se lanza el segundo formulario modal, Visual FoxPro guarda el estado de la ventana inhabilitada y la inhabilita nuevamente. Cuando se cierra el formulario, este estado inhabilitado comienza a ser restaurado. Al final, la ventana anfitriona permanece inhabilitada, incluso cuando todas las formas modales fueron cerradas.

La forma que existe para solucionar esto - desafortunadamente - no es genérica. Cuando se dispara el evento Activate de un formulario usted sabe que el formulario va a responder a las entradas del usuario. En este punto ninguno de los controles ActiveX del formulario actual deberían estar inhabilitados. Puede asegurarse de esto ejecutando el siguiente código para cada control ActiveX que tenga en su formulario.

Declare Long GetParent in Win32API Long
Declare Long EnableWindow in Win32API Long, Long
EnableWindow(GetParent(oleControl.Hwnd), 1)

Donde oleControl es una referencia regular al control ActiveX del formulario ( por ejemplo Thisform.oleControl1). La propiedad HWND no es una propiedad estándar que ofrezca VFP. Es problema del control ActiveX para proveer del controlador de ventana y toma el nombre de la propiedad o el método. Necesita referirse a la documentación del control ActiveX.

---

Nota del editor: Carlos Alloatti nos indica una corrección realizada para este artículo en: ActiveX generic fix.

¡ Gracias Carlos !