Hola de nuevo José Luis,
Como la curiosidad mató al gato, he vuelto a dar una vuelta sobre el redimensionador ATresizer 2.7a... (Aunque en su día ya sirvió para algo de uso y me hizo pensar en utilizar una forma híbrida para mi colección de controles.
Con este redimensionador tuve ocasión de estudiarloy trabajarlo hace algún tiempo, aunque bastante bien orientado, tiene algunas mejoras y pequeños bug, que deberían ser mejorados, aunque tal vez en algún caso pudiera ser que esto obligara a modificar estructuralmente bastante ciertas partes de desarrollo....
Recuerdo que crea una serie de propiedades y objetos en tiempo de ejecución los cuales estan bien orientados, sobre todo para aquellos objetos que no poseen ciertas propiedades y que son necesarias para la redimensión, pero en algunos casos, tal vez crea cierta redundancia de codificación, como es la de preguntar constantemente a los objetos si poseen ciertas características o no. (Tal vez una definición derivada de las clases base VFP y, complementada con los métodos y propiedades necesarios reajustaría esta redundancia).
La forma de uso es rápida, incluso no hay que definir ninguna propiedad en el formulario, sólo poner un trozo de código (alta de procedimiento, e instanciación de clases) y listo, pero se necesita pasar algunos parámetros para su comportamiento y tal vez en tiempo de ejecución sería buena idea que el formulario consiguiera ciertas propiedades para el comportamientos posterior de el y sus objetos. Aunque bien, si se utilizara la forma encapsulada VCX en lugar de las tres ó cuatro clases importantes que existen en formato PRG y lo comentado al principio de este párrafo dejaría esta parte bastante mejorada.
La recursividad es algo que VFP no tiene de forma inherente y hay que ajustarla al milímetro si se decide utilizar. Una recursividad muy profunda puede dar error al devolver cierta información y claro está no hay que olvidarse que no puede pasar por la parte que ha sido padre en llamada de lo contrario te puedes imaginar donde acaba la recursividad... El uso de la forma de ratio calculado en #DEFINE con ciertos controles provoca algún pequeño error.
El trabajo que realiza a la hora de redimensionar biene dado por dos variables principales Ratio-Anchura, Ratio-Altura, esto provoca que su aplicación generalizada para algunos objetos no sea la más adecuada, tal vez el uso de ratios individuales conjuntamente con los ratios generales provoque adecuarse mejor el cambio de magnitudes.
Se podría continuar comentando algunas pequeñas mejoras en el rendimiento, pero para no extenderme mucho en este correo-e, comentar solamente que...
- El método que utiliza es "Soy yo quien te redimensiona tu no te preocupes" sobre "Me redimensiono yo tu lo sabes y mi padre también" o sobre el que particularmente claro está, pienso que es mejor..., "Yo me redimensiono, te lo cuento y complementas a mi padre y a mí" que sería la forma más refinada de evitar cierta redundancia y rapidez de ejecución (caso de formularios extensos, uso más complejo de contenedores, ActiveX en varios niveles del formulario, etc.)
- Ya que el primer acercamiento provoca lentitud; el segundo el aislamiento por independencia ya que cada objeto base debe tener bien definido sus ratios, cálculo de redimensión, propiedades necesarias, etc., éste puede entrar en pequeños errores y obligar que la depuración sea casi constante...
- El tercero, quizás con el inconveniente de crear una clase personalizada que uniera objetos con su cálculo y contenedores bien informados, evite lentitud ya que cada objeto en su forma base calcula su comportamiento al cambiar de magnitud y el formato especial (ActiveX, Recursividad por su contenido, Controles especiales derivados de una clase base común pero con comportamiento visual distinto, etc.) la clase personalizada.
Un saludo compañero...
