SoloCodigo

En este tutorial, se enseña como crear controles de usuario en VB6, desde 0. Crearemos un botón totalmente personalizado, partiendo de las características siguientes:
1 - Que admita una imagen ajustada siempre al tamaño del control.
2 - Que pueda llevar opcionalmente un icono.
3 - Que pueda llevar opcionalmente un texto y que este pueda ser alineado.
Otras características se irán definiendo a lo largo del tutorial, en la docena (aprox.) de mensajes que acabará teniendo el tutorial.

El tutorial se va presentando en partes de modo que cada parte es un mensaje y el único motivo de ser de cada parte es el tiempo libre que disponga mientras lo desarrollo. Aun así, a modo de índice, se expone lo que se discute en cada una de las partes.



Parte 1: Preparación del proyecto y creación de los archivos.

Parte 2: Se diserta acerca de la intencionalidad del control y se informa bastante acerca de las propiedades, creamos nuestra primera propiedad y se explica la persistencia de las propiedades más allá de la sesión.

Parte 3: Proporcionamos más propiedades (ColorTexto, Texto, Alineaciontexto, Fuente e Icono) y ahondamos en más detalles sobre las mismas. Inicialización de las propiedades. También señalamos cuando existe la importancia o no de provocar errores, o de 'salir adelante' cuando el error es perfectamente derivable.

Parte 4: Se añaden 4 propiedades más, necesarias para poder empezar a dibujar, Activo, Imagen , Icono y IconoTamaño además se detalla como inicializar el control con una imagen cargada que luego es pasada a una variable interna.

Parte 5: Se realiza la primera parte del dibujado, se explica los 2 métodos para dibujar y mantener actualizado los gráficos, se recalca la importancia de ordenar en capas, se explica el evento resize y se diserta acerca de cómo superar los escollos de errores que a veces resultan casi imperceptibles exponiendo un ejemplo, finalmente se acomete una optimización y se explica los 'porteros' como control de repetición de código por llamadas que a su vez llaman  a quien los ha invocado (recursividad involuntaria).

Parte 6: Se ahonda en la importancia del evento resize para mostrar como se controla el tamaño del control y se termina de pintar el control, haciendo el Relieve y dando una solución gráfica al estado deshabilitado del control.

Parte 7: Aprovechando un pequeño bug, se explica el orden e importancia de la cascada de eventos de inicialización, se señalan optimizaciones para el repintado y también se aborda un par de optimizaciones funcionales para la propiedad imagen. Se indica como aportar y guardar la info (documentación) de las propiedades, métodos y eventos disponibles para el cliente .

Parte 8: Se empieza a explicar lo fundamental de los eventos, partes de que se compone. Dónde se debe ubicar un evento y porqué. Control sobre bucles infinitos a causa de los eventos. Control sobre desbordamiento de pila a causa de los eventos. Cómo se logra una propiedad de X escrituras-lecturas. Eventos síncronos y asíncronos, como generarlos. Prioridad en los eventos.

Parte 9: Se realizan los eventos de teclado y ratón, que al no tener apenas código adicional, no precisa muchos comentarios.

Parte 10: Se explican cuestiones referentes al foco, y se aborda una solución gráfica para reflejarlo, la ganancia y pérdida de foco, se sugieren 2 rutinas parecidas entre sí y se invita a realizar otras de curso similar...

Empezamos la siguiente parte. Hoy se describe acerca de la intencionalidad del control y parte acerca de las propiedades, así como algunas características de las propiedades que son arropadas por el usercontrol.

Cuando vamos a crear un control, previamente es conveniente hacer una descripción sobre un papel (papel, fichero de texto, eso al gusto de cada uno) de que funcionalidad es la que esperamos que tenga, evidentemente siempre en medio del proyecto podremos hacer añadidos y de hecho los haremos a propósito para ver como afecta los añadidos a última hora. Sin embargo cuanto mejor tengamos explicitado  lo que queremos que haga en mejores condiciones estaremos para proveer lo que precisa...

Es habitual que la razón por la que queramos construir un control es que determinado existente no tenga tal o cual característica/s por lo que nuestro modelo podría ser una copia en cierto modo similar a otro ya existente pero con algunos cambios.... por ejemplo, a mi nunca me gustó que los botones de microsoft no tuvieran una propiedad 'forecolor', por narices siempre es negro (se puede cambiar empleando APIs, pero no hay una propiedad), si queremos cambiar el color del fondo debemos cambiar la propiedad estilo a 'graphical', sólo entonces toma el color que hayamos designado a la propiedad backcolor, ese comportamiento también nos parece 'idiota', otra cuestión es que por ejemplo admite una imagen, pero se pega al tamaño real, también debe estar establecido estilo a graphical (Command1.style=1: Command1.picture= loadpicture(ruta...)) . Para colmo incluso creando una imagen justo a la medida del botón, si es oscurapor abajo nos 'tapa' el texto del botón... en fin como puede sentirse, hay razones que ya justifican nuestro botón y ya de entrada tenemos unas descripciones de lo que tiene que ser...

Vamos pués a proceder a dar una somera descripción de lo que pretendemos crear... El control debe poder cambiar el color del fondo, el color del texto, alinear el texto horizontalmente, admitir una imagen ajustada en todo momento al fondo, tener capacidad para un icono alineado siempre a la izquierda y poseer un borde perimetral que de momento no definimos como se comportará (podría ser fijo o que se hunda al pulsar y se eleve al soltar), debe tener algunas propiedades típicas, activo (enabled), font, etc...

Es una descripción pequeña, pero para empezar a contruirlo nos vale, luego a medida que vayamos diseñando y probando terminaremos de definir tal vez nuevas propiedades o cambios de funcionalidad... esto debe entenderse como algo lógico y razonable, tampoco es estrictamente necesario tener una descripción exhaustiva del mismo, siendo como es para nosotros... A medida que uno se familiariza creando controles bastantes ideas de la descripción están ya en la cabeza y no necesitamos tener que plasmarlas por escrito, en cambio si conviene dejar escrito esas funcionalidades específicas que pretendíamos para el control ya que si no, cabe la posibilidad de que tras algún tiempo sin retomar el proyecto se nos haya olvidado por completo la misma, la funcionalidad que lo haría diferente de otros modelos previos que ya hayamos realizado, por ejemplo puede que este nuevo botón se deba a que queramos unir varios botones en línea y columna formando una tabla y por ello queramos redefinir la forma en que se dibuja el relieve de los mismos... o podríamos querer en un nuevo botón que tenga una pequeña animación cuando se pasa el ratón por encima, o simplemente añadir un sonido cuando se oprime y suelta elbotón... estas 2 últimas funcionalidades las utilñizaremos como un añadido de última hora cuando se dé al control por terminado...

El mejor sitio para dejar escrito la funcionalidad (las ideas de como debe operar) es usar un archivo de texto en la misma carpeta que el control, así siempre estará disponible.

Por tanto empezaremos definiendo propiedades bastante conocidas: Backcolor, forecolor, enabled, Text... pero a mi particularmente me gusta usar el español que es mi idioma, por tanto todas las propiedades y demás se reflejarán en lo posible en español... hay una razón más o menos poderosa para dejarlo en inglés, que ya para el final se indicará si no me olvido, y si me olvido me lo recordais (me refiero al final de la elaboración del control).

Las propiedades pueden usarse tanto en clases como en formularios y por supuesto en los controles que es donde más lo vemos. Las propiedades son un trío de funciones realmente pero que el entorno de VB lo enmascara como si fueran algo distinto de funciones, de hecho podríamos olvidar las propiedades y tratarlas como funciones pero nos perderíamos ciertas funcionalidades del entorno, como mostrar los valores de las propiedades del control en la 'Ventana de propiedades'.

Las propiedades como digo son un trío, una devuelve un valor y las otras 2 entregan un valor. de estas 2 una se utiliza cuando se usa un tipo de datos genérico y la otra cuando se usa como tipo de datos un objeto.
A continuación iremos poniendo código y explicando...
Acabamos de definir la propiedad ColorTapiz (colorFondo, BackColor) para el control, analicemos cada parte...
GET: es como una función, devuelve un valor, se usaría así en el formulario: dim X as long: x= CtlBoton1.Colortapiz : msgbox x
Public: porque queremos que esta propiedad sea legible, si quisiéramos que no se pudiera leer pondríamos private y sería una propiedad sin derecho a lectura.
LET: es la asignación de la propiedad, puede verse que es como una función tiene un parámetro que es por donde se recibe el valor, a dicho parámetro le hemos lamado, ct (abreviatura de Colortapiz, yo suelo usar esta convención), este parámetro no es visible desde fuera, luego no importa el nombre que se le dé. Let también se declaró public, si lo hubiéramos declarado private la propiedad estaría privada de escritura, es decir sólo podría invocarse para ser leída pero nunca podría escribirse.
Más adelante se mostrará que es posible dar más de un parámetro a las propiedades, sin embargo debe quedar claro que 1º no es obligatorio el par de procedimientos de la propiedad, puede usarse sólo el get y no aparecer el let, o al revés. 2º si aparecen ambos deben ser congruentes en el tipo de datos y en la cantidad de parámetros, veremos que siempre LET tiene un parámetro más que GET, 3º en las propiedades del control (en el formulario) sólo aparece una propiedad si aparecen ambos métodos y también ambos son públicos, si uno de los 2 es privado no aparece en las propiedades del control. (conviene que luego se pruebe a cambiarlos a private uno de ellos y se verá como deja de aparecer).

La propiedad almacena un color que a fin de cuentas es un tipo de datos long, porqué lo hemos declarado del tipo OLE_COLOR ?, porque cuando se declara de esa manera el entorno de VB nos despliega una 'página de propiedades'  para elegir visualmente el color, si utilizamos un tipo de datos long, desde el entorno sólo podríamos introducir valores numéricos desde el teclado. Los controles pueden poseer páginas de propiedades que es casi un pequeño mundo lo mismo que los controles pero que una vez conocidos los controles son más sencillos de conocer, el uso de páginas de propiedades para los controles facilita al programador poder cambiar cómodamente algunas propiedades incluso a varios controles a la vez, la contrapartida es que diseñar una página de propiedades nos lleva más tiempo y hace al control más pesado (el control una vez compilado pesa más)... si al final hay ganas podríamos crear una sencilla página de propiedades.

 Véase que usando una propiedad en vez de 2 funciones, ambos métodos se llaman iguales, usando funciones por necesidad cada uno debería tener un nombre distinto)... Ahora ponemos un ejemplo de como se asigna la propiedad del control en el formulario.... Dim x as long : x= 1234567: CtlBoton1.ColorTapiz = x .Aquí escritura y antes dimos un ejemplo de lectura de la propiedad. Antes de seguir, podemos probar ya esta nueva propiedad, para ello debemos ir al formulario y pulsar en el control, en las propiedades del control veremos que aparece la propiedad ColorTapiz y podemos ver como tiene el color que le asignamos (el tipo Ole_color hace que el entorno nos muestre el color visualmente en vez de un número y podemos cambiar el color y ver como el cambio se refleja en el control...por ejemplo cambíalo a azul... IMPORTANTE: si el control en el formulario aparece 'rayado diagonalmente', tal como se dijo ayer es porque está en modo diseño, para poder probarlo en el formulario es preciso ponerlo en modo ejecución, y para ponerlo en modo ejecución tenemos que cerrar la ventana del control (no la de código si no la de la interfaz del control)... esto no lo voy a repetir más veces, debe quedar claro YA.

Sólo nos queda describir el código introducido en los métodos de la propiedad ColorTapiz... para el get le decimos que colortapiz es igual a un valor que el propio control ya mantiene una variable... (Cada contenedor provee determinada funcionalidad, disponible para los objetos insertados en él y los contenedores del entorno de VB proveen propiedades como Backcolor,y algunas otras que se irán describiendo, al objeto Usercontrol, nuestra instancia. Por tanto la línea 'ColorTapiz = UserControl.BackColor' le está diciendo que  entregue la propiedad almacenada en la variable Backcolor que provee ya el control.
En cuanto al código de la asignación LET, lo primero que hacemos es verificar si el color recibido es el mismo, y sólo si es distinto se lo asignamos a la propiedad backcolor del usercontrol. La razón de esto es doble por un lado más adelante tenemos que añadir funcionalidad al final del código de este método, dicho código queremos que sólo se ejecute si realmente el color asignado cambió si no estaremos ejecutando cosas para que quede todo como estaba antes. La otra razón es que ahora el valor del color se guarda en la propiedad backcolor del control (en el que hemos delegado), pero si (cambiamos el color del tapiz a azul como se sugirió más arriba al probar y cerramos el entorno y volvemos a abrirlo, volverá a ser rojo, es decir el cambio no se ha mantenido, justo para eso está la siguiente línea: PropertyChanged "ColorTapiz", esta línea le  dice al entorno que esta propiedad ha cambiado, sin embargo esta línea no trabaja sola sino que trabaja en conjunto con 2 métodos del control, uno se encarga de guardar a fichero el cambio registrado (cuando le demos al botón de guardar cambios en el proyecto), y la otra funcionalidad se encargará de volver a leer el valor cambiado cuando arranquemos el proyecto, o se ponga en modo de ejecución el proyecto.

La última línea de código del método LET es una línea comentada, más adelante tenemos que introducir código ya que el cambio del color del fondo, implica que nos borrará el resto del contenido gráfico del control, por lo que se añadirá una línea que salte a una función que vuelva a dibujar todo lo que teníamos y que se ha borrado. Como ese método aún no lo tenemos, dejamos una línea comentándolo.

Justo ahora describiremos estos métodos que ayudan a almacenar de forma permanente las propiedades y que permiten luego al ejecutarlo volver a leer ese valor guardado y lo dejamos por hoy, mañana iremos más rápido con las siguientes propiedades una vez que hemos comprendido de forma general acerca de las propiedades, faltan detallesque se irán presentando según surjan los casos.

Para probar que el color no permanece, vayamos al modo ejecución y cambiemos el color del fondo... y acto segudio pulsemos la tecla F5, veremos que aparecerá el formulario pero con el color que le asignamos en la propiedad backcolor de la ventana de propiedades de la interfaz del control.

Ahora añadamos este código al control (abajo del todo):
Estos métodos pueden localizarse en la ventana de código del control sobre la lista de procedimientos del control (usarcontrol), por tanto elparámetro éste de propbag, lo provee el entorno de VB, este es un objeto interno de VB cuya funcionalidad procede de una interfaz cuyo objetivo es precisamente la de almacenar y recuperar valores de propiedades que se han asignado durante el diseño (impronta), es algo así como si compras un vehículo, cuando se fabrica es metal y debe ser pintado para evitar que se oxide, aunque a los vehículos se los elige el color y se piden se nosenvía cuando la fábrica dispone de una demanda suficiente de ese color para cambiar los tambores de pinturas en el proceso en cadena, por ejemplo para pintar 200 vehículos seguidios de ese color. sin embargo aquí en VB es como si todos salieran con una capa antióxido gris (que en el entorno se llama  Ambient.Backcolor y que es el contenedor quien decide ese color, de hecho es el color del contenedor, es como si la fábrica fuera azul por defecto todos los vehículos salieran azules), luego para asignar el color que actualmente hay guardado el objeto Propbag (Bolsa de propiedades) le dice asigna a la variable (Usercontrol.Backcolor) leyendo en las propiedades guardadas ( .Readproperties) el valor de la propiedad ColorTapiz  que se guardó bajo ese mismo nombre en el fichero, y si no se encuentra en el fichero un valor guardado tomamos el valor almacenado en usercontrol.backcolor actualmente.

Es decir el método readproperties se compone de 3 partes la asignación (usercontrol.Backcolor =), la invocación  del método del objeto pararecuperar el valor (propbag.Readproperties), pero que como usamos with, nos ahorramos escribir en cada línea el nombre del objeto), y los parámetros que necesita esta invocación, que al caso son 2, el nombre de la propiedad guardada y un valor que se asigna por defecto si tal propiedad no se encuentra: UserControl.BackColor = .ReadProperty ("ColorTapiz", Ambient.BackColor) igualmente en vez de poner por defecto el color del contenedor podríamos poner un color específico, por ejemplo: .ReadProperty( "ColorTapiz", vbBlue) o incluso un valor numérico: .ReadProperty ("ColorTapiz", 234567)

El método readproperties ocurre 1 única vez (realmente es un evento que se dispara para el usercontrol) y es cuando el control entra en modo de ejecución, una vez leídas las propiedades ya no se vuelve a invocar dicho método.

Writeproperties, es el método que usa el control para que se guarden las propiedades y ocurre también una sola vez, justo antes de que el control sea descargado de memoria. Esto sólo sucede mientras la 'aplicación cliente' está en diseño, es decir el control está en modo de ejecución, ya que en modo diseño lo que se guarda es el valor de la propiedad que nosostros le dimos en la ventana de propiedades del control, pero ese no es accesible a nosotros. Es decir nosotros hemos diseñado que cada vez que un cliente utilice el control éste aparecerá cuando se cargue por primera vez la instancia el color rojo, sin embargo el cliente querrá y podrá cambiar  que cuando su aplicación se ejecute el control aparecerá con el color que él eligió, es ese valor el que nosotros guardamos en writeproperties, los cambios que el cliente introduce cuando está diseñando la aplicación.

Este método consta de un parámetro más que el método readproperties del objeto propertybag: guarda a fichero (writeporperties) una propiedad con el nombre "ColorTapiz", cuyo valor actual está en la variable: Usercontrol.Backcolor (la variable que actalmente contiene su valor) y si el valor no se encuentra o no es válido entonces asigna éste por defecto (Ambient.Backcolor, el del contenedor donde se halleel control). Igualmente que para readproperties podría asignar un valor directo, como vbBlue ó 56789. Conviene en cualquier caso que en ambos sitios el color asignado por defecto sea el mismo en ambos casos

Bien ahora que ya hemos descrito como se logra que las propiedades permanezcan entre sesiones, podemos volver al formulario cambiar el color a uno que no hayamos usado (por ejemplo un violeta) y guardar el proyecto para que ocurra un evento writeproperties y efectivamente se guarden, luego pulsamos la tecla F5, con lo que ahora se crea el control (recordemos el evento initialize que probamos al principio de esta parte) y luego se invoca el evento readproperties, que asigna las propiedades que hemos guardado. en el evento initialize el color será rojo, pero ahora tras el readproperties será el que le dimos la última vez (violeta)...
Y finalmente por hoy ya que hemos guardado el color violeta para esta instancia veamos como al añadir una nueva instancia del control al formulario el color del fondo de éste es el rojo. Ahora debería quedar claro que valores son los que se guardan en writeproperties y se leen con readproperties Y también debería quedar claro el significado del método propertychanged.
También podemos probar a cambiar la propiedad del control por código, no sólo desde la ventana de propiedades de los objetos del formulario. Por ejemplo añade un botón microsoft y escribe código, para que cuando se pulse cambie nuestro control de color o nos diga el color actual.

Después hacer todas las pruebas que queramos, conviene dejar sólo una instancia del control (del que estamos diseñando) en el formulario para no liarnos cuando mañana continuemos...

Mañana ahondaremos en las propiedades y crearemos bastantes más ahora que se ha explicado como crearlas. También mañana explicaremos como se soportan propiedades que ni siquiera existen, backcolor lo posee el usercontrol y enabled, por lo que en estos caso podemos delegar en elas aunque como hemos visto podemos cambiarle el nombre por el camino...

Comenzamos una nueva parte, en esta parte nos centraremos en completar todas las propiedades y detalles que nos faltan para poder procesar el grafismo que requiere el control.

Nos ponernos manos a la obra, crearemos una propiedad, la que permite que nuestro control esté enabled o disabled, como hablamos en castellano esta propiedad se llamará Activo. Queremos que cuando el control esté deshabilitado cambie de aspecto, para que el  usuario final perciba con claridad que el control está deshabilitado y no le queden dudas sobre si 'no funciona'. Sabemos que cuando un control está deshabilitado, lo que en realidad sucede es que el control no envía eventos al cliente, sin embargo es responsabilidad nuestra posibilitar esa impresión de deshabilitado, dado que esto se enmarca también dentro del proceso gráfico es necesario que dispongamos también de esta propiedad y de la forma que queramos señalar que el control está deshabilitado. Más adelante comentamos algunas cosas que podemos hacer, para reflejar esta situación, ahora vamos al código de esta propiedad y luego lo comentamos.

Como se ve, esta propiedad hemos delegado en el usercontrol, nosotros no tenemos que preocuparnos de activar o desactivar eventos, el asunto se lo pasamos al usercontrol y él se encarga de hacerlo, no nos importan los detalles. el código es fácil de entender, si el valor introducido es distinto del actual entonces guardamos el nuevo valor y graficaremos del modo conveniente, para eso al igual como otras propiedades que afectan al grafismo, hemos añadido la dichosa línea comentada a la espera de que sea remplazada por el código conveniente.
Personalmente me gusta poner siempre esta propiedad la primera dentro de las propiedades y la última en los métodos de persistencia... los ponemos ahora.
Aquí podemos ver que el valor por defecto no lo hemos delegado en ambient, sino que preferimos que sea activo por defecto.
La inicialización de esta propiedad no es preciso definirla, por defecto cuando una instancia se crea su estado siempre es activo.

Recordemos que siempre que un contenedor este desactivado, per sé todos los controles contenidos también lo están, podríamos invocar un evento desde ambient de modo que cuando la propiedad enabled del contenedor cambie de estado nos informe, sin embargo no lo haremos. El estado del control no debe ir a la par que el estado del contenedor, es el propio contenedor quien debe concienciar el usuario final que está deshabilitado y que por tanto todos sus controles son inaccesibles... de hecho  el contenedor cuando está deshabilitado deja de pasar eventos al control tal como si nosotros mismos lo hubieramos deshabilitado, por lo que alcliente no le llega ningún evento.

Ayer, que se me hizo tarde también dejé sin implementar la propiedad picture que como convinimos, nuestro control tendría la posibilidad de tener 1 imagen como fondo y siempre ajustada al tamaño del control, aún en este caso nos falta decidir el comportamiento de la imagen... proponemos 2 casos (podrían ser más)...
A - La imagen está como fondo, pero cuando pulsamos (down) cambiamos a otra imagen  y cuando soltamos el botón vuelve a cambiar a la inicial.
B - La imagen permanece como fondo inalterable, la percepción de pulsación (hundir y soltar) lo reflejaremos de otra manera.

Nos vamos a decantar por la opción B, Con la opción A necesitaríamos duplicar la propiedad y darle un nombre que diferenciara claramente ambas imágenes.
Puesto que hemos elegido la opción A, pondremos el código para dicha propiedad y de paso la usaremos de mod que aprendamos algo más acerca de las propiedades... después comentamos el código de la propiedad.
Primero hemos declarado una propiedad para contener la imagen. No delegamos en la propiedad picture del control, porque al hacerlo implicaría que el control la vuelca al control, ya se dijo en otro apartado más arriba que a veces no nos interesa como sucede una funcionalidad y que en dicho caso nosotros la debemos socorrer como nos interese. Picture no funciona bien, porque automáticamente pega la imagen sobre el control pero en unas determinadas condiciones, para empezar a tamaño real, y para terminar centrada posicionada en la cordenada 0,0 del control, ni una cosa ni la otra nos interesa, la funcionalidad que deseamos es que la imagen ocupe siempre la totalidad del control, tenga éste el tamaño que tenga. Por esto la imagen la guardamos en nuestra propiedad.
 
Como se ve en le código de la propiedad, al serr un objeto necesitamos el 'formato' SET, también puede verse que no comprobamos si se mete una imagen o está vacío, a efectos prácticos podría no bastar con verificar si el valor recibido tiene o no una imagen sino que además deberíamos verificar si en estos momentos tenemos o no una imagen ya en el control y teniendo 2 variables tendríamos 4 posibilidades de decisión... por ejemplo una posible situación sería que ahora mismo no hubiera imagen y que tampoco se recibiera imagen en cuyo casono sería necesario hacer nada porque nada cambió, en los otros 3 casos deberíamos actualizar, facilitamos la tarea si nos evitamos esas comprobaciones, después de todo a la hora de dibujar suele hacerse esta pregunta de si existe la imagen, luego sería tonto preguntarlo 2 veces... cada uno debe valorar en su situación si el código a ejecutar es más demorado que la verificación teniendo en cuenta las posibilidades que puedan darse de una verificación falida o exitosa.

Finalmente tras lapersistencia que a estas alturas no debería requerir comentarios, vemos que para la inicialización tenemos 2 líneas y un código de entrada 'algo extraño'. Bien, hemos decidido que por defecto el control siempre provea ya de 'fábrica' una imagen, si o si, luego el cliente puede optar por sustituirla o eliminarla. Ahora bien donde alojamos esa imagen ?... por un lado podríamos dejarla en los recursos y en el evento rescatarla, desde luego es una opción, no onstante yo he optado por cargarla ahora mismo durante el diseño en la propiedad picture (esto es teneís que ir a la ventana de la interfaz del contro, localizar la propiedad picture y cargar ahí una imagen que será la que se utilice) , os muestro una imagen de como aparece en mi caso:
Es una imagen tipo gif, conviene que sea algo que no tenga dibujos que al ajustarla al tamaño del botón de la apariencia de estar desproporcionado, es decir evitad que tenga cosas reales, más que una imagen podríamos considerar que es una 'textura'. También se debe tener en cuenta el tamaño de la imagen... considerando que nuestro control una vez compilado tendrá entre 30 y 60 kb, haceros una idea... en mi caso la imagen pesa 1' 73Kb. y hasta 5 kb, tampoco sería pesado...
Bien finalmente el código de esas líneas de inicialización pueden quedar claramente despejadas... en diseño hemos subido una imagen que ahora mismo está guardada en la propiedad picture del usercontrol, cuando el cliente cree una instancia de nuestro botón, se ejecutará esa y solo esa vez el evento initproperties, copia sobre la propiedad p_imagen la imagen contenida en el usercontrol.picture y luego elimina la copia de usercontrol.picture, por lo que en el control ya no aparece, desde ahora se conserva en p_imagen hasta que la persistencia se encargue de guardarla a fichero.

Hay algún detalle más acerca de la imagen, que se dirá un poco más adelante o quizás mañana y también diremos a estas alturas que debemos deciidir en que método visual va a consistir la deshabilitación del control, podríamos poner por ejemplo una imagen gris, podríamos trabajar con el relieve o hacer algún efecto gráfico. en este momento nos hacemos el loco, como si no se nos hubiera pasado aún por la cabeza (durante el diseño de un control siempre hay algún detalle que hasta que no estás sobre él no lo has decidido o bien se te había olvidado, o esperabas a ver que tal combinaba con otras opciones en conjunto, etc... por lo que está cuestión la decidiremos resolveremos en el mismo instante que se nos presente o incluso la demoraremos aún para más adelante.... (eso sí con su línea de recordatorio pertinente).

Ahora, antes de empezar a dibujar nuestro control (tampoco hemos empezado esta parte dando el código de pintar como seguramente se esperaba), para empezar a dibujar ya tenemos bastante detalles nos falta ordenarlos, yo en mi cabeza los tengo ordenados, pero evidentemente cuando uno se enfrenta por primera vez a una situación suele ser necesario anotar los detalles y ordenarlos... esto haremos en este instante que a modo de resumen fija la funcionalidad gráfica.

El control lleva un color de fondo que puede ser cambiado por el cliente en cualquier momento, lleva un texto que puede cambiar de color, además de la fuente y el propio texto, tenemos además que alinearlo sobre el control y para esto nos influye la existenciao no de un icono y finalmente (por ahora) tenemos una imagen... una vez que hemos enumerado los detalles ordenémoslos en capa, lo que tiene que ir más al fondo y lo que irá encima...

Al fondo del todo siempre va el ColorTapiz, luego irá la imagen, encima de esta irá el icono alineado a la izquierda con un margen que describiremos en el próximo párrafo y finalmente encima del todo en primer plano irá el texto. Pués es en este orden que debemos empezar a pintar....

Si colocamos un icono debe ser para que se vea, si no no tiene sentido entonces el icono debería tener unas medidas mínimas, pongamos 16x16 píxeles, luego cuando hagamos un relieve perimetral nos comeremos 2 píxeles por cada lado, y sería agradable a la vista que el icono no fuera completamente pegado al relieve luego estimemos un margen y digamos que sean 2 px. mínimo por arriba, izquierda y abajo... entonces resolvemos que para poner el icono necesitamos una medida como mínimo de 16+4+4= 24 píxeles de alto y lo mismo de ancho, si esa medida es menor aunque tengamos icono no lo pondremos. Y finalmente que haremos cuando el botón sea gigantesco... horizontalmente dijimos desde un principio que lo queríamos alineado a la izquierda, luego el icono estará ubicado en: 2px relieve + 2 px margen = 4px. y verticalmente pocríamos decidir una de 3 opciones:
A - Alineado arriba
B - Centrado verticalmente:
C - Alineado arriba y abajo, es decir se expandería al hacerlo el control.

Examinado la opción C, Hacerlo así haría que laimagen se mostrada se viera distosionada si no creciera también, proporcionalmente en dirección horizontal, pero hacer esto nos limita el acnho para el texto, luego esta opción la descartamos. Examinado la opción A, quedaría bien pero parecería más el botón de un título de algo que la descripción de un botón de ación, luego nos decantamos por la opción B.
Aún respecto del icono queda otra noción, si tenemos un tamaño mínimo de icono, podríamos tener un tamaño máximo de icono, o podría quedar fijo?.... nos decantamos porque sea elcliente quien en este caso decida el tamaño del icono, esto requerirá una nueva propiedad que exponga al cliente la capacidad de modificarlo, de momento creamos sólo la enumeración y la variable privada, luego la propiedad es como otras que ya hemos realizado... En cualquier caso nos parece que si se usa un icono tampoco deberá tener un tamaño infinito, luego parece razonable limitarlo a un tamaño máximo. en estas circunstancias parece que el icono deba ser cuadrado, pero definitivamente muchas veces un icono alargado a lo ancho o alto podría ser más vistoso, y por tanto adoptamos esta idea...  Total decidiremos un total de 24-25 tamaños de icono... que ya se presentarán en el código en una enumeración... y un último detalle para este caso, es qué ha de suceder cuando el usuario tiene un alto de botón y fija un tamaño e icono mayor que él... bien en este caso lo que haremos será fijar un alto del botón tal que sea el alto del icono + los márgenes y el relieve es decir altoicono + 8 px, lo mismo para el ancho.

Debe uno darse cuenta como este icono nos está complicando la vida casi más que el resto de propiedades que hemos definido hasta el momento. Nos parece razonable, así que aceptamos seguir adelante, confiamos en que el resultado merece la pena. No hay que olvidar que el objetivo de este control es mostrar como se diseña un control y como se resuelven ciertos detalles, podríamos haber tirado por lo sencillo y fijar que el icono tuviera un tamaño siempre fijo centrado a lo alto del botón. Todos estos detalles sin embargo nos mostrarán como nos apoyamos en otras variables e incluso constantes para lograr nuestros propósitos.
La enumeración de tamaños.... 2 detalles a tener en cuenta, primero debe verse como nuestra enumeración lejos de ser compleja, ayuda al cliente a decidir que tamaño tiene el icono, pués inserto en el nombre de la constante está. el otro detalle es fijarse en como, la enumeración la hemos emepzado e -3 y no en 0, la razón es porque queremos dar la impresión general de que el tamaño de 24x24 es eltamaño normal y por tanto valores menores sería considerarlos pequeños, no hay más razonamiento que ese, y seguro estamos que el cliente tendrá esa misma impresión.
Primero vemos una variable que guardará la propiedad del tamaño del icono. Luego usamos 2 constantes, que realmente no necesitamos, se pone simplemente para ilustrar su uso (nótese como yo suelo nombrar a las constantes empezando por 'c_', esto cada cual a su gusto. Los valores de las constantes son los límites de la enumeración de tamaños de los iconos, y los usamos exclusivamente para determinan en la propiedad si el cliente introduce un dato válido...
al final tenemos dos variables que son también privadas, no guardan valor de propiedad pero indirectamente guardarán la medida que representa el tamaño de icono elegido.

Éste es el aspecto que viene presentando a estas alturas el código del evento initproperties, las líneas que ahora nos interesan son las 3 últimas que he separado del resto para mayor claridad... vemos que tal como deseábamos a la variable que da soporte a la propiedad del tamaño deicono le damos el valor 'normal' que hemos hecho coincidir con 0, de hecho por eso mismo, podríamos omitir esa línea las variables numéricas siempre valen 0 al inicializarse... conjuntamente con dicha variable y acorde a su valor las variables que han de mantener el valor de las medidas, deben ser siempre como corresponde, la correspondencia puede mirarse en la enumeración...

Ahora nos fijamos que algo parecido necesitamos hacer en la persistencia de la propiedad.. a la propiedad al final la hemos llamado Iconotamaño.
 
La propiedad ya sabemos guardarla, vemos que en coherencia con el valor por defecto dado en initproperties le damos el mismo valor  (vale igual si ponemos el nombre de la constante ICONO_24x24). Debajo hay una línea que llama a un método, en dicho método (cuyo código se expone a continuación) lo que se hace es obtener el valor real que tendrá el icono dado un valor asignado a la propiedad, en initproperties como sabíamos que el valor era 0, las medidas eran 24 de ancho y 24 de alto.
El método para calcular cada medida no tiene más complejidad que la correspondencia siendo que únicamente hemos unificado casos comunes.
También es de resaltar que podríamos haber hecho persistencia sobre las variables así, al leer los valores de las propiedades no tendríamos que saltar a esta rutina y buscar (más que calcular) el valor correspondiente. La razón es que el evento readproperties sólo se ejecuta una única vez justo cuando la aplicación se inicia luego, no hay apenas sacrificio de CPU, después de todo acceder a disco para leer valores seguramente no es más rápido que esto. Finalmente si sólo se usara esta rutina en dicho lugar quizás no merecería la pena las líneas de código empleada, pero dado que también la precisa la propiedad justo está bien...

Ahora rematando la cuestión del icono, su propiedad:

Ya creo que la propiedad no merece ser comentada... ved como usamos las constantes, realmente si no las vamos a usar en ninguna parte más, se  podrían omitir, no obstante una razón para usar constantes es que te recuerdan para qué sirven por e hecho de tener un nombre, una vez pasado el tiempo al ver el código y ver un -3 y un 20 uno podría preguntarse, porque 20 y no 30... su nombre refleja su significado... ya sabeis que al compilar, las constantes son remplazadas in situ por su valor, y por tanto no hay traducción de valores ya con la aplicación compilada en ejecución, como puede suceder cuando el código es interpretado.

Y como al final nos hemos enrollado con propiedades y el texto se ha hecho largo, cortamos aquí esta parte y finalmente no va aser hoy cuando pintemos aunque ya tenemos todos los detalles... (excepto el relieve, del que de momento hemos decidido que es perimetral, pegado al margen y de 2 px de ancho) para hacerlo.

Hoy en esta parte, ahondaremos en el evento resize para mostrar como se controla el tamaño del control y terminaremos de pintar el control dando respuesta al estado deshabilitado y el dibujado del relieve.

En la parte anterior se mostró un 'portero', que es una técnica para asegurarse de que determinado código no se ejecuta más de una vez una vez que se ha emepezado a ejecutar, concretamente lo aplicamos para la rutina 'DibujarTodo' que podía ser reinvocada incluso 2 veces si se originaba en un cambio de tamaño provocado desde dentro del código. Analizaremos el código de modo suelto para entenderlo mejor.
Si se examina el código, lo primero que encontramos es que la variable que realiza el control es declarada estática, es decir que su valor permanece, aún después de haber salido de la rutina. Es necesario que sea estática, porque aunque las variables internas conservan su valor (siguen en memoria) hasta que se salga completamente de la misma, sin embargo una rellamada a la rutina crea nuevas instancias de las variables locales al método, luego el valor del 'portero' de la nueva instancia (llamada al método) no tiene nada que ver con el vaor de la llamada anterior y aún en curso. Se entiende por salida del método cuando lo hace por el final o por una salida incondicional (Exit Sub), es decir por una salida sin retorno.
Lo siguiente que vemos es que el portero está controlando el acceso, si el portero es false(es decir no está previamente una llamada cargada en memoria) entonces accede al interior y se marca el portero como 'presente'. Se va ejecutando el código y más adelante puede suceder (o no, no es absolutamente necesario que ocurra, basta con que exista la posibilidad), una llamada al exterior, desde donde puede originarse de nuevo una llamada (directamente o indirectamente a trvés de otra/s rutina/s a la que a su vez ésta llame)  a la rutina de la que procede. Si es el caso, se observa que el portero denegará el acceso a la re-ejecución del código. Finalmente antes de salir de nuestra rutina, debemos indicar al portero, que estamos saliendo, permitiendo con ello que una futura lamada pueda tener acceso.

Como se ve, el mecanismo evita ejecutar código que es invocado recursivamente. La razón para evitarlo, pueden ser varias, desde evitar que desactualice el estado de unas variables a simplemente no perder tiempo en ejecutar código que simplemente es repetitivo de lo que estamos haciendo. Éste era el caso del uso por lo que se aplicaba a la rutina 'DibujarTodo'. Ahora también lo volveremos a aplicar a la rutina Resize, por las razones que se detallan en el siguiente párrafo.

Un control una vez que se crea una instancia de él y es puesto en el formulario del cliente, puede tener las medidas que determine el cliente, ya que de momento no hemos impuesto restricciones, sin embargo nosotros podemos determinar varias cosas a éste respecto:
1 - Podría tener un tamaño fijo e invariable.
2 - Podría tener un tamaño máximo.
3 - Podría tener un tamaño mínimo.
4 - Podríamos evitar que tuviera un tamaño dentro de un rango dado, es decir se permitiría una tamaño menor que cierta medida y un tamaño mayor que cierta medida, pero entre ambas medidas.
5 - Puede no tener restricciones de tamaño, pero si estar sujeto a ciertas reglas, por ejemplo su ancho fuera siempre múltiplo de 10px. , etc...
6 - Puede no tener restricciones de ningún tipo.
Cada caso se aplicaría según convenga o según decidamos, de momento nuestro control se aplica el caso 5, no tiene restricciones (el cliente le puede dar el tamaño que quiera) excepto, cuando el tamaño del icono supera (en alguna de sus dimensiones) las del control, en cuyo caso se fuerza a aumentar el tamaño del control hasta el tamaño del icono + 8 píxeles, por los márgenes ya descritos.
Lo cierto es que carece de sentido hacer un control tan pequeño que resulte difícil deusar, por lo que es aconsejable limitar siempre (al menos) el tamaño mínimo. Por otra parte un control no debe tener medidas cuyo valor sea 0, ya que cualquier posible cáclculo realizado con sus medidas puede ocasionarnos un problema por división entre 0 o incluso arrojarnos un valor negativo... un control jamás va a tener un ancho de -10. el modo de evitar estos posibles problemas es fijar un tamaño mínimo.
Al fijar un tamaño mínimo para un control debe tenerse en cuenta para qué se usa dicho control, y ver qué utilidad práctica resulta para dicho control tener una medida lo más pequeña posible, esto nos servirá para determinar que menor de cierto tamaño para dicho control resulta inútil.
Con esto en mente, determinamos que un botón, puede llegar a tener un tamaño muy pequeñoy aún ser útil, por ejemplo fijémonos en un control de texto previsto para contener una ruta, a menudo puede verse un botón al final del mismo que sirve para seleccionar una nueva ruta, podríamos poner un botón tan ancho que pueda acoger dicho texto: 'Seleccionar ruta', pero a veces vemos este texto es superfluo, es intuitivo que dicho botón debe servir para esto en cuyo caso se pone un botón con el mismo alto que la caja de texto y un acho que permita apenas 3 puntos suspensivos, para indicar que se abrirá una ventana que nos permitirá elegir la ruta...
La descripción de este ejemplo nos demuestra que efectivamente un botón puede llegar a tener un tamaño muy pequeño, fijamos dicho tamaño por tanto en 12píxeles (a gusto vuestro si lo quereis variar ligeramente) .
Ahora nos vamos a limitar el tamaño del control, trabajando sobre el evento resize, antes teníamos...
Ahora añadimos la regulación de las medidas, para ajustarlas al mínimo cuando las medidas que se le den sean menores, es decir comprobamos en cada cambio si las medidas son menores en cuyo caso lo aumentamos al tamaño mínimo. cada medida se hace por separado...

Si se da el caso de que el ancho del control que en dicho momento se recibe es menor de 12, entonces hacemos que valga 12, lo mismo para el alto. Al hacerlo cambia la medida lo que provoca de nuevo el evento resize, y como dijimos no queremos perder tiempo en ejecutar varias veces el mismo código cuando no es necesario, como en este caso, luego decidimos ponerle un portero, y el código de la rutina, nos queda finalmente tal como se aprecia en el siguiente código:
A este código, puede verse que hay un caso aparte cuando el portero no deja acceder... si miramos bien, sucede que si el redimensionado que provoca la llamada recursiva procede desde un cambio del cliente o un cambio por ajuste interno, no necesitamos hacer nada más, ya que cuando regrese de la rellamada terminará de ejecutar las líneas que quedaban. No obstante tenemos un caso más, que desata el evento resize, por nuestra regla del icono, que dice que si éste era de mayor tamaño que el control, se ajustaba el tamaño del control, provoca también este evento. Como ahora hemos puesto un portero, no se ejecutaría el código, sin embargo en este caso necesitamos de modo excepcional que se ejecuten determinadas líneas que mantienen actualizada ciertas variables. Para complicarse más el caso, esta regla puede suceder en las 2 'direcciones', variar el alto tal que hace que sea menor que el alto del icono, o variar el alto del icono para que sea mayor que el alto del control, así las cosas, debemos observar la cascada de llamadas que produce uno y otro caso...
Caso Alto del control se hace menor y como consecuencia este valor es menor que alto del icono:
 1º salta el evento resize por cambiarse el tamaño del control, el portero de esta rutina se pone en TRUE.
 2º llega a la línea que llama a dibujartodo y establece su portero a TRUE.
 3º Esta llamada hace que llegue a la rutina 'VerificarIcono' que comprueba que en efecto el alto del control es menor que el alto del icono.
 4º fuerza por tanto un cambio de tamaño para adaptarlo, y salta un evento Resize, pero el portero está en TRUE, luego no nos permite acceder, sin embargo necesitamos actualizar las variables s_Ucalto (por ejemplo) entre otras...
 5º Sale del evento resize sin establecer el portero a false.
 6º Sale de la rutina 'dibujartodo', y regresa su portero local a False.
 7º Sale del evento resize poniendo el portero a False.

Caso alto del Icono se hace mayor y como consecuencia este valor es mayor que el alto del control:
 1º La propiedad Iconotamaño, llama a 'dibujarTodo'... quien establece su portero a TRUE.
 2º llega a la línea que llama a 'VerificarIcono', comprueba que en efecto el alto del control es menor que el alto del icono.
 3º fuerza por tanto un cambio de tamaño para adaptarlo, y salta un evento Resize, pero el portero está en False, luego nos permite acceder.
 4º El evento Resize, marca su portero a TRUE, y entra en su código, llega hasta la l´nea 'dibujartodo' pero su portero no lo deja entrar.
 5º Sale del evento resize y queda el portero en false.
 6º Sale de la rutina 'Diibujartodo' y pone su portero en false.
 7º Sale de la propiedad Iconotamaño.

Como se ve, cada caso sigue un camino distinto, podemos decir que cuando sucede desde el cambio de icono, el recorrido que hace no requiere código adicional, en cambio si se requiere código para solucionar el caso cuando se debe a un cambio desde el tamaño y SOLO SI en 'verificarIcono' nuevamente se vuelve a cambiar el tamaño para ajustarse al icono. entonces vemos que para que la salida del resize no nos deje sin actualizar las variables que necesitamos actualizar, necesitamos añadir control sobre esta situación.
De entrada creamos un caso adicional al portero del evento resize (ELSE) y creamos una variable de tipo buleana, que nos permita diferenciar éste caso concreto de otros (véase la línea: If s_ResizeDesdeIcono = True Then :  s_ResizeDesdeIcono = False ..... End If).
Y dentro colocamos el código que necesitamos se ejecute para éste caso. Sabemos que por lógica necesitamos tener actualizado el 's_TopIcono' y sabemos que éste a su vez depende de la actualización de 's_Ucalto', luego también la línea para este debe actualizarse y finalmente vemos que cada vez que actualicemos s_UcAlto, también necesitamos actualizar 's_TopTexto'. Por supuesto la variable s_Ucancho debe actualizarse. Tal vez sólo haya cambiado el alto y no el ancho, en cuyo caso no necesitaríamos actualizar s_Ucancho, o al revés que cambiara el ancho y no el alto, en cuyo caso sólo necesitaríamos actualizar sólo s_UcAncho, por tanto podríamos modificar el código para no actualizar más variables que sólo las que cambien, sinembargo puesto que el evento resize nos llega sin discriminación de a quien de las dimsensiones se debe el evento (si al alto, al ancho o a ambas), nos resultará más farragosos y largo separar cada caso que actualizar la 'otra' aunque sólo varíe la 'una'. aun así si nuestor control fuera extremadamente complejo y hubiera mucho código asociado a cada caso podría entonces darse el caso que discriminar cada situación sería más provechosa que no hacerlo. aquí sin embargo no se da el caso.

Falta eso sí, poner la línea de código que señala que el evento viene por 'resize desde icono' que es el significado de la variable s_ResizeDesdeIcono, en el evento resize, la comprobamosy la apagamos, pero no la encendemos, el lugar para encenderla es como se debiera sospechar justa en la línea anterior que proovocan o pueden provocar esta llamada, es decir en la rutina de 'VerificarIcono', tal como se señala en las líneas de código, siguientes:

Antes teníamos...

Ahora debemos tener...
Sin olvidarnos de la declaración de la variable...

Ahora ya nuestro control está limitado para que nunca tenga menos de 12 px. de ancho y/o alto, con ello evitamos divisiones entre 0 y valores de cálculo negativos como consecuencia de actualizar variables que no permiten un valor negativo
El texto siempre puede empezar a dibujarse en -10px. sin lugar a error, lo mismo que el icono, aunque el icono a diferencia del texto, nunca tendrá un top negativo, ya que lo forzamos a que como mínimo sea 4px. todavía si el texto tiene un alto muy grande puede quedar cortado. en principio esta corrección debe quedar a cargo del cliente, ya que debe ser consciente de que si el botón tiene 20px de alto no esconsecuente tener la fuente a 60px. de alto. Queda a gusto de cada uno si decide  o no que debe reducirse el tamaño del texto a para que quepa en el control a medida que el alto de éste también disminuye el alto. Yo entiendo que proporcionado una propiedad fuente es el cliente quien tiene medios para remediarlo, y aunque sucede parecido con el tamaño del icono, sin embargo el cliente no está familiarizado con el control, además el ejecrcicio de adaptación se muestra como ejemplo de lo que supone diseñar unapropiedad (icono) que tiene varias reglas y consecuncias y por tanto ejemplo de como se han ido resolviendo los posibles problemas uno a uno.

También se alienta para que cada uno decida si el texto debe o no dibujarse en otra capa, es decir antes del icono, ya que si habeis probado lo suficiente el control podreis ver (nunca con una alineación izquierda) como el texto cuando es largo respecto del control se monta sobre el icono... en partes anteriores ya se habló de posibles soluciones para deciidir que hacer con el texto en estos casos y ahora se comenta el caso de si conviene mejor dejar en la capa más cercana el icono y justo debajo el texto, o dejarlo como está. En cualquier caso tal como se avisó, este control tiene el propósito de servir de modelo para aprender a diseñar modelos, por lo que no es absolutamente necesario resolver todas las cuestiones que puedan darse, pero si comentar acerca de como puede solucionarse y que el aprendiz aporte y aplique por su cuenta su propia solución.

Ahora pasaremos a dibujar el relieve que comose recordará nos quedó pendiente. El relieve que haremos será de tipo 3D, y por tanto al botón le daremos un aspecto similar a como estamos acostumbrados a verlo, cuando el botón está en estado normal le damos un relieve 'UP' y cuando se pulse el botón, le daremos un relieve 'Down'. Puesto que estos estados están proporcionados internamente, no se establece una propiedad relieve para el botón, pero que si podría ponerse para contrles comopor ejemplo una caja de texto. Por dicho motivo la variable que ha de mantener el estado interno de dicho relieve y puesto que sólo son dos valores podemos asignarlo a una variable Boolean:
En cambio si nuestro relieve fuera una propiedad decidible por el cliente nos interesaría tener una enumeración, parecida a lo que se señala a continuación.

Hemos decidido pués como será el comportamiento de nuestro relieve, será automático, elevado en estadonormal y hundido cuando se pulse el botón. Hagamos pués la rutina de dibujado:
Nuestra rutina de dibujado del relieve es muy sencilla, usamos 4 colores 2 claros y 2 oscuros, los claros se colocan, arriba en la vertical y la horizontal izquierda, los oscuros en la vertical inferior y horizontal derecha, esto por sí solo nos da una impresión visual de relieve, ya el relieve y el 3D no existe realmente en un plano, siempre será una impresión visual (un engaño a la vista).
La configuración de hundido, es opuesta a la configuración de elevado, es decir donde están los colores claros se colocan los oscuros y viceversa.
Hay que señalar que existe una API, que realiza el relieve 3D, aceptando el parámetro del tipo de relieve, no obstante vemos que realizarlo a nuestro antojo es tan sencillo que no nos planteamos recurrir a ella.
Sobre el propio código y de forma comentada, está superpuesto el tratamiento que se le daría al relieve si fuera expuesto como una propiedad y ésta fuera elegible por el cliente. Obsérvese que el 'borde plano', equivaldría a no dibujar nada, es decir dejar el color del fondo o lo que muestre una imagen, y que el 'borde coloreado' requiriría una propiedad llamada 'ColorBorde' y que por tanto podría ser un color distinto del ColorTapiz, sería por tanto un recuadro perimetralde un determinado color de 2 píxeles de ancho, sin embargo se dibuja con la misma técnica en todos los casos.
El código de dibujado de las líneas, se traza línea a línea porque recordemos que cada color dibuja un diedro (las 2 líneas que van a parar a una esquina). finalmente indicar que los colores elegidos no conviene que sean justo el blanco y negro, ya que el caso habitual es que un fondo donde se hay sea blanco o negro, con lo cual una de nuestras líneas se quedaría 'perdida' con el fondo, por tanto si desviamos los colores ligeramente hay posibilidades de que queden 'definidas'... queda por supuesto al gusto de cada cual si decide usar 3 px. para dibujar el relieve en vez de 2. Se eligen 2 colores distintos precisamente para garantizar que 1 si un color queda 'comido' por el fondo externo, y el otro 'comido' por el colorTapiz (es una posibilidad) todavía los colores de la esquina diametralmente opuesta quedan válidos siendo suficientes para reflejar y quedar constancia de una impresión de relieve 3D...

Aún no hemos terminado de hablar sobre el relieve, nos faltan algunos detalles y empezamos por uno de ellos (está emparentado con el relieve luegose indicará porqué), es decir, ahora nos falta decidir como reflejamos el estado de desactivación del control para poder dibujarlo, recordamos que igual que hemos ido viendo a lo largo de la guía, hay varias opciones para llevar a cabo una idea o concepto, básicamente depende de la imaginación del diseñador, yo aquí os propongo una solución muy vistosa que sin embargo tiene algún riesgo que luego se comentará. Antes de proceder con el código, pondremos una imagen de como nos va quedando nuestro control.


Para trabajar con la deshabilitación nos vamos a la propiedad 'Activo', donde haremos cambios y/o añadidos... tal como refleja el código siguiente:

Es decir hemos remplazado el nombre d ela rutina a la que llamamos, ahora pondremos el código de esa rutina y veremos que el mismo podríamos haberlo puesto dentro de la propiedad, sin embargo no lo haremos ... ¿porqué?, bueno hay razones por las que a veces conviene tener una rutina suelta y no todo el código junto, básicamente tenemos 2 razones para ello, la más razonable es que el mismo código sea llamado desde varias partes (acordaros de la rutina 'MedirTxto') y en otras ocasiones simplemente por claridad, las propiedades nos interesa tenerlas bien despejadas, que sean fácilmente legibles si nos lleva mucho código, pensemosmejor en sacar todo lo que no es el carácter específico de la propiedad fuera, colocado en una rutina (acordaros de la rutina 'MedirIcono'). Esto es lo que hemos hecho y he aquí su código:
Como se ve el código es muy sencillo, al entrar se le pregunta si el control está activo, si lo está (es decir hace un momento no lo estaba), entonces es señal de que estaba deshabilitado, por tanto conviene borrar todo y redibujarlo, tal como sucede en la derivación a la cuestión ¿usercontrol.Enabled=false ?.. else... dibujamos todo de nuevo. En cambio si está desactivado ( es decir hace un momento estaba activo) implica que ahora tenemos que dibujar el estado desahbilitado, y nos basta con 2 líneas de código, en la primera cambiamos el modo de dibujado, por el 5 (Mask Pen Not) y a continuación dibujamos una caja rellena con el color rojo en este modo, el resultado puede apreciarse en la siguiente imagen...


Como se aprecia tiene un efecto de 'deshabilitado' fuera de toda duda, además nos ha sido muy sencillo realizarlo. Fijémonos en el código y ved como una vez que habilitamos el control (activo=true), volvemos a establecer el modo de dibujo al valor 13 (copy Pen).
Antes mencionaba que esta técnica tiene un riesgo, y en efecto lo tiene, nosotros hemos dibujado el cuadro de relleno con el color rojo, y nos ha dado un resultado adecuado, sin embargo esto depende hasta cierto punto del colorido que tiene nuestor control, puede darse el caso de que quede completamente negro o blanco o rojo y puede darse el caso peor aún de que quede un aspecto 'arañado' de colores, es fácil de evitar si nos limitamos a usar colores 'sin mezcla' es decir que esencialmente se componen de 1 o 2 componentes rgb y muy poco o nada del 3º como son los colores fácilmente reconocibles con la vista, (rojo, amarillo, verde, azul, cyan, rosa,etc...) en cambio si elegimos colores cuyos componentes RGB estén bastante presentes, puede darnos aspectos 'desagradables' en algunos casos y más frecuentemente aspectos con una elevada transición en la fusión de colores es decir aparecerían degradados con franjas muy anchas de un tono en vez de temer multitud de franjas impreceptibles con levescambios de tonalidad, por ejemplo sustituyendo el rojo por este color: 723458, una vez deshabilitado me queda complatamente negro.
Para quedar fuera de toda duda sobre el aspecto de nuestro control deshabilitado, podríamos elegir un vaor en el modo de fusión de colores de 6 (invertir color), con lo que obtenemos el negativo... siempre nos dará un resultado aceptable, en este caso no importaq el color indicado.


Todavía nos resta poner el código que se encarga de cambiar el relieve cuando se presiona y suelta el botón...
Nos vamos a los eventos mousedown y mouseUp y ponemos el estado correspondiente a nuestra variable en cada caso y luego acto seguido llamamos a la rutina 'Dibujarrelieve', fijaos que en este caso no llamamos a la rutina 'DibujarTodo', la razón es que el relieve es realmente la capa más cercana de todas, la única que puede tapar al resto y que no es tapada por ninguna otra.

Y para terminar con esta parte por si aún no lo habeis hecho se recuerda que hay que activar la línea que teníamos comentada en el código en la rutina Dibujartodo'

De dibujar sólo nos resta una cosa... señalar cuando el control tiene el foco, esto lo dejaremos para más adelante, cuando hablemos de otras cuestiones.
En la parte de mañana nos meteremos con los eventos, como provocar y diseñar nuestros propios eventos.

Hay más cosas que decir de las propiedades, más adelante veremos (al paso que explicamos eventos) como se realiza una propiedad que es escribible sólo x veces, pero ahora que nuestro control está perfectamente dibujado, es el momento de avanzar, más adelante cuando volvamos sobre las propiedades, con esos cambios que de modo pactado, sugerimos que se nos ocurrirán a última hora y que aprovecharemos para ver como añadidos de última hora nos afecta al código ya realizado, es entonces cuando volveremos sobre las propiedades y diremos algunos detalles más...

Ahora nos centramos en explicar lo fundamental que debe saberse de los eventos: cómo se declaran, como se utilizan, dónde van, qué deviene de ellos, síncronos o asíncronos, etc... . Hasta ahora podemos asignar propiedades (casi todas relacionadas con un aspecto visual) y podemos cambiar sus valores tanto por diseño como por código, pero nos falta que el control provea eventos para que el cliente pueda darle utilidad...

Los eventos son mecanismos de 'intro-alimentación', es decir provocan interrupciones dentro de su ejecución lanzando una llamada al cliente para que pueda en dicho momento introducir (ejecutar) el código deseado o tomar decisiones... y luego regresa el flujo de control al código... por tanto nos centraremos en ver los eventos que para un control son importantes y los eventos que dadas las características del control pueden ser deseables...

Al igual que con las propiedades, el usercontrol, nos provee de eventos, de hecho excepto las propiedades y funciones añadidas el resto del código descansa sobre los eventos que nos provee el usercontrol, no obstante no todos los eventos que nos provee el control son útiles para el cliente, ni los necesita, por lo que muchos de ellos quedarán ocultos y sin trascender fuera,  hay sin embargo 2 de ellos sobre los que hemos puesto código y sobre los que más adelante colocaremos código; los eventos MouseDown y mouseUp...

El modo de  crear y desatar eventos al cliente consiste en un mecanismo (visualmente) compuesto de 2 partes, en el primero se hace una declaración de los eventos que se van a emplear, de modo parecido a como se declaran variables, en la 2ª parte simplemente se usan...

La declaración es como sigue: 1º Alcance - 2º Evento - 3º nombreevento 4º (lista de parametros), veamos un ejemplo en código de una declaración, que usaremos para enviar al cliente un evento TextoCambiado:
Aquí vemos una declaración de evento que pasamos a comentar. El alcance implica hasta donde será visible ese evento, en VB todos los eventos son públicos, por lo que puede ser omitido, se supone que en una nueva versión esperada (esto ya nunca será) podría haber eventos 'Friend' es decir que sólo podrían verse si el control se usaba dentro del proyecto (por ejemplo para crear otro control) no siendo asequible al cliente. Event, declara que es un evento, del mismo modo que Sub , Function o Const, definen que son, (los no definidos se toman por variables), luego viene el nombre del evento (el nombre que se nos antoje) TextoCambiado, esto provoca que cuando instanciemos un control de nuestor tipo (CtlBoton) dicho evento pase a verse reflejado en el formulario como 'CtlBoton1_TextoCambiado'. Finalmente los parámetros que deseemos pasar, debe fijars eque al igual que con las funciones puede ser por valor o por referencia, sin embargo no se admiten parámetros opcioneles, ni de tipo ParamArray...

Ahora la 2ª parte, donde lo que procede es usar el evento, en el ejemplo mostrado justo es acompñarlo del código donde se usaría... en la propiedad texto:
Se marcan flechas para el código añadido sobre lo que teníamos antes, debe uno fijarse que dado que pasamos un parámetro 'Textoanterior', necesitamos poder contar con ese valor en el momento de enviar el evento, podríamos haber optado por poner justo el evento al principio, cuando ambas variables se conservaban (se pierde la antigua cuando hacemos p_texto= t), pero diremos que los eventos de tipo 'cambiado' conviene que se ejecuten justo al final del código, es decir cuando además se haya actualizado el mismo, imaginemos que cabría pensar en una situación en la que salta un evento de texto camnbiado, que recibimos y sin embargo nosotros vemos en el gráfico que el texto es el mismo que teníamos antes... Hay que ser consecuente, un evento cuya idea es en tiempo pasado requiere enviarse cuando se haya completado, en cambio un evento en tiempo presente puede y debe enviarse mientras o antes de cambiarse, imaginemos un evento como 'event Textocambiando (byval Textosugerido as string)' tendría un lanzamiento como se señala en el siguiente código:
Aunque francamente un evento en este caso concreto no resulta de utilidad al cliente, ya que solamente le estamos diciendo que vamos a introducir el texto que él mismo (se supone) acaba de introducir. Podríamos ser más explícitos y útiles si en cambio le aportáramos algo como el evento sugerido en el siguiente código:
Aquí le estamos diciendo al cliente que ha introducido un texto vacío, y que si lo desea puede dejar como texto el nombre del control, si el cliente utiliza el evento en su código, tiene la ocasión de alterar (obsérvese que el parámetro se pasa por referencia) por un nuevo texto a su conveniencia o bien permitir que el texto sugerido sea el que se utilice. Imaginemos un caso donde se está leyendo código de un archivo y una línea hubiera de asignar el texto al botón, si por casualidad se encontrara una línea en blanco elcliente podría forzar la lectura de la siguiente línea y entregarlo, habiendo utilizado nuestro aviso mediante dicho evento... Naturalmente el cliente puede aún remplazar el texto por una cadena vacía si su intención es que no haya texto. Desde luego en tiempo de ejecución dejar como texto el nombre de un botón no dice mucho más que dejarlo vacío. No se trata de ver la idoneidad o no de dejar el texto vacío para el botón sino, de ver y comprender la utilidad práctica que deban tener los eventos. Para el caso de un botón un evento de textoCambiado no resulta práctico, pero nos ha servido para ilustrar algunos ejemplos y ver la importancia de dónde deben ir.

Ahora analizaremos otra cuestión relativa a los eventos, evitar bucles infinitos. Aunque no lo parezca, un evento mal programado puede acabar enun bucle infinito. Usando la misma propiedad (Texto) y el mismo evento usado hasta ahora (TextoCambiado), veremos como puede producirse un bucle infinito y analizaremos como evitarlo y se darán indicaciones en base a ello...
Tenemos la siguiente firma y código donde se dispara el evento:

Con este código puede crear un bucle infinito si el cliente responde a éste código con algo como lo siguiente:
Supongamos que el cliente en ejecución, introdujo un texto al botón: 'Domingo", antes tenía el nombre del control, luego al cambiar  salta el evento, pero ahora en el código de respuesta del evento (en el formulario del cliente) yo le asigno el valor 'Lunes', luego nuevamente la propiedad se asigna y como el valor cambia de nuevo, produce un evento, ahora mi variable 'cambio' es true, luego ahora le asigno el texto 'Domingo', la propiedad ejecuta su código para actualizarse, con lo que al volver a cambiar, nuevamente me produce un evento textocambiado, ahora la variable Cambio vale  false, por lo que nuevamente le asigno a la propiedad Texto el valor 'Lunes'... el ciclo comienza de nuevo y no hay ninguna salida... estamos en un bucle infinito. Desde luego puede alguien pensar que el código del cliente está muy rebuscado, al respecto debe decirse que el cliente no tiene porqué saber que puede producirse un bucle infinito, después de todo él sólo está asignando un valor a una propiedad, también puede decirse que este caso puede darse usando un código en la parte del cliente menos clara que el código expuesto aquí y que le resultaría más difícil al cliente detectar la falta de respuesta (como si se volviera loco y no atendiera).

Hay varias formas de evitar los bucles infinitos para los eventos. La primera medida sería, como ya conocemos colocar un portero. Así mientras se esté ejecutando el código del evento, no se aceptarían  alteraciones de la propiedad... este tipo de bloqueos suele darse en las llamadas 'transacciones' una vez elegido unos valores no pueden ser modificados (en este caso de las transacciones para evitar manipulaciones y problemas de seguridad). Veamos como sería nuestro código añadiendo un portero:

Es una solución, pero entonces vemos que si el cliente decide cuando responde al evento cambiar la propiedad, el cambio no se opera, esto no es malo en si, lo malo es que el cliente no advierta que no se ha producido ningún cambio. Puede uno pensar que si el texto acaba de ser cambiado, el cliente debe saberlo y qué sentido tendría que volviera a tener que cambiarlo justo con el evento del cambio que acaba de producirse... bueno, aunque a alguien no se le ocurra una respuesta, lo cierto es que hay muchas, ya dijimos 1, al decir que el primer cambio, podría provenir por ejemplo de la lectura de un fichero que estaba tomando entradas y aparecía una línea en blanco donde se esperaba encontrar un texto para ponerlo en el botón, por tanto el cliente hace bien si detecta que el texto está en blanco en poner por ejemplo un texto por defecto (ya se habló que a nosotros no nos interesa forzar a que por narices el texto deba contener una cadena, una cadena vacía es perfectamente tolerable en un botón, de hecho a veces sóloes un estado transitorio hasta que el cliente le ponga otro). Otras razones por las que el cliente puede querer cambiar el texto que aún  acaba de ser cambiado, es por ejemplo para verificar que cumple ciertas reglas y si no las cumple debe cambiarse, evidentemente el mejor sitio para verificar dichas reglas es precisamente la oportunidad que nos brinda el evento TextoCambiado. (imaginad que en vez de un botón, que suele tener un texto más perenne, fuera un control de texto  (Textbox) donde a menudo verificamos si se trata de sólo números o sólo letras, etc...).

Entonces la solución de añadir un portero, vemos que es una solución a medias, sin embargo podemos darle un pequeño hervor más, por ejemplo si en el evento el parámetro que se le proporciona al cliente se le pasa por referencia en vez de por valor, puede en ese punto reasignar el nuevo valor para el texto y el portero por tanto no nos impide hacerlo, veamos el código, y obsérvese como hemos cambiado la ubicación del RaiseEvent, debe quedar claro el porqué..:

Debe verse como tal como dijimos (puesto que es un control visual), antes que nada hacemos los cambios visuales oportunos,para reflejarlo (en este caos no es estrictamente necesario, ya que la velocidad de ejecución del código, hace que sea innecesario), pero eso si vemos como el disparo del evento lo hemos subido arriba, para que si el cliente cambia el parámetro (que el ve como...) NuevoTexto, dicho valor sea el que definitivamente sea aceptado.

En este caso vemos que ahora el cambio (tamto si se produjo por parte del cliente o no cuando se le envió el evento), no provoca evento, aunque vemos que hemos podido hacer un nuevo cambio a pesar del portero. Esta solución es perfectamente aceptable en la mayoría de los casos, podríamos darle todavía una 'vuelta de tuerca' a nuestro código para permitir que se aceptaran x cambios sucesivos, es decir un bucle que parecería infinito, pero que está controlado... veamos el siguiente código:

Fijarse primero que hemos vuelto a la versión de byval para el parámetros del evento...
Al observar el código, veremos que hemos añadido un 2º portero, pero éste a diferencia del anterior no controla si ýa se entró, si no cuantas veces se entró, en este caso, en conjunto con el otro portero queda una regla claramente definida, se entra mientras portero= false o mientras x< 12, la única combinación por tanto que excluye la entrada es portero=true y X=12, esto proporciona hasta 12 cambios consecutivos 'en bucle infinito', sin salir por abajo (es decir que cada cambio se produce dentro de la respuesta que el cliente da al evento). Este mecanismo es más potente y versátil que usando sólo el primer portero. Cada uno deberá analizar cuando es necesario una solución y cuando conviene aplicar la otra.
Imaginad una aplicación destinada a evaluar respuestas de examen, lógicamente si un alumno cambia muchas veces una misma respuesta claramente no conoce la respuesta, por tanto proporcionar controles con un número máximo de cambios posibles antes de que el profesor resetee ese valor es una opción perfectamente válida  (Suponemos que lo que dura el examen y no sujeto a la duración de la aplicación, imaginad que alcanzo el límite impuesto y no pudiendo cambiar más, fuerzo a que se cierre la aplicación y con ello deba volver a empezar el examen, si sabemos que ese valor no cambiará en esa circunstancia nadie cerrará la aplicación por tal efecto inexistente).
Naturalmente en este caso propuesto, sobraría el portero 1º, se permiten cambios pero en número límitado, el portero permite que desde el evento, se cambie nuevamente el valor, pero hasta un número máximo de veces. Veamos un código que se encarga de hacer esto (entiéndase a la vez como una propiedad de escrituras limitadas) , véase que en dicho caso la importancia radica en la propiedad tanto como en el evento, ya que éste debe pasar por valor y no por referencia el parámetro para forzar que una nueva asignación 'entre' en la propiedad por asignación y por tanto aumente el portero contador de cambios:

Este código, como se podrá analizar permite un máximo de 12 cambios a la propiedad, incluso aunque estos cambios se hagan desde el disparo del evento, luego mientras no se encuentre que la variable 'ResetLimite' tenga el valor true, no dejará que se vuelva a poder hacer cambios en la propiedad. No analizamos que pasa detrás de la variable resetLimite, ya que éste no es el objetivo, sino ilustrar como un evento puede cambiar la 'vida' de una propiedad y las restricciones necesarias para controlarlo. si el disparo del evento proporcionara el parámetro por referencia habría el más posibilidades de cambio ya que en dicho caso, el cambio se haría por 'invitación' y no por la 'puerta principal'.

Sin embargo en determinadas situaciones donde absolutamente cada cambio deba ser verificado, no es aceptable, ninguna de las soluciones aportadas (esto con reservas comose indicará más adelante y sobre todo la verdadera razón) , así vamos por fin a proveer una solución que resuelve algunos de estos conflictos; cambiar una propiedad tantas veces se necesite desde donde se necesite sin quedarse colgados.
En realidad el problema real, la verdadera razón, no es el bucle infinito (aunque como tal el problema existe), si no el tamaño de la pila, puesto que cada cambio se realiza desde el propio evento, se entra de nuevo en la propiedad sin haber salido previamente, lo que supone que la dirección de retorno, del evento debe guardarse en la pila, también al entrar en la propiedad nuevamente debe guardarse la dirección de retorno para cuando salga de la propiedad, esto agota el tamaño de la pila, por el cúmulo de reentradas a la propiedad. De hecho si ejecutamos el código que pusimos en el cliente, en mi caso la pila se desborda después de 250 iteraciones.
Cuando Vb marque el error 28  - espacio de pila insuficiente, pulsad en el botón 'Depurar' de la ventana de aviso, y consultad el valor de X. como vemos ni siquiera podemos caer en un bucle infinito, porque un error es un impedimento para ello...
Después de todo uno debe tener claro cuando y como se produce un bucle infinito (como el código recién expuesto), por tanto adoptaremos una solución a cambio de una complejidad añadida de evitar que la pila se colapse.... siguen vigentes por tanto las soluciones indicadas con anterioridad a din de evitar en lo posible bucles infinitos, usando porteros y por tanto todo lo dicho con anterioridad es aunque no lo pareciera después de ver sus 'defectos', perfectamente válido. Nos centramos pués en evitar el agotamiento de la pila que como se ve, preocupa más que el bucle infinito que se supone el cliente debe saber evitarlo (el código anterior es obvio que genera un bucle infinito).

La solución pasa por devolver los eventos de forma asíncrona. Para poder devolver los eventos asíncronamente, necestiamos añadir a nuestro control un timer, llamémosle timEventos, y aunque sólo vamos a programar de forma asíncrona este evento de TextoCambiado, sin embargo se muestra toda la estructura de código necesaria como si empleáramos muchos más eventos de esta forma, así no quedará ninguna duda. La primera duda que puede sugir es cómo hago que unos valores privados en una rutina puedan ser pasados a otra rutina y más cuando aquella no lo va a emplear de forma síncrona, la solución pasa por empaquetar los datos que necesitan nuestro eventos... Supóngase que empleamos varios eventos de forma asíncrona en nuestro control, y supóngase que el evento más 'largo'  ebn cuanto a parámetros utiliza 4, pués entonces parece obvio que tenemos que 'transportar' cada evento  en un mismo 'camión' en el que quepa cualquier evento, por tanto construimos un camión (paquete de datos) que tenga 4 parámetros... es decir algo tan simple como una estructura. Como se verá más adelante, una estructura no nos sirve, Vb nos marcará un error, pero esto lo se yo, lo dejamos de momento porque el principiante se toparía con ello y lo mejor es seguir el camino lógico que tomaría. cuando llegue el momento se explicará como solucionarlo.

Qué más requisitos puede necesitar nuestro 'camión', si trasporta carne, necesitaría un congelador, si transporta líquido, necesitaría ser estanco, si transporta algo peligroso debería estar encerrado, podemos optar por 2 soluciones usar un 'camión' para cada caso o usar un 'camión' único para cualquier 'paquete-carga' (evento), por tanto si optamos por este último, todos nuestros 4 parámetros deberán ser algo que pueda portar cualquier cosa, es decir de tipo variant. Y puesto que hemos decidido usar el mismo camión para todos los eventos asíncronos, necesitaremos 1 identificador de evento y un 'almacén' donde esperan los paquetes a que el camión haga un 'reparto' y venga por el siguiente....  Como se podrá observar se usa un símil y se seguirá usando, para explicar el método, ya que en este punto nuestro sistema es equivalente al de una empresa que se dedica a la paquetería (recogida y entrega de paquetes), salvando las diferencias. Usando el símil se espera que el método quede 'iluminado' por la lógica y no se vea como una solución de la que no se sabe de dónde viene o el por qué de una cosa u otra.

Iremos expresando estas ideas con código, primero el diseño de la 'caja' de nuestro camión de reparto:

Como dijimos 4 parámetros, de tipo que 'acepten cualquier cosa', pescado, escombros, agua, alcohol... y un identificador que más adelante definiremos mejor... ahora necesitamos el camión de reparto en si:

Hemos dicho que tenemos un identificador de eventos, porque usamos 1 único camión para 'transportar' todas las 'cargas', y por tanto el que la recibe debe saberlo... mejor que dejar el identificador en un byte lo dejamos en una enumeración (las enumeraciones siempre son de tipo long ), ya sabemos que al compilar el código desaparece y en sustituído por las cosntantes que representan, pero para diseñar son muy cómodas sobre todo si sele dan nombres claros y muy explícitos:

Ya se dijo que para el control no vamos a hacer eventos asíncronos, la enumeración se expone sólo como ejemplo... no vamos a tener ningún evento Iconocambiado... Por tanto hacemos el cambio oportuno en la declaración del parámetro identificador en la estructura para que sea del tipo:

Ahora necesitamos un 'almacén', como dijomos,  ya que como es de esperar podría darse el caso de crearse varios paquetes de entrega y no sabríamos cual entregar primero o cual después... la variable 'camión' ReparteEventos, en vez de 1 sólo (camión) podría ser una 'flotilla' de ellos', es decir una matriz, ahora bien nos tendríamos que ocupar de asignar las tareas a cada camión de la flotilla, verificar si uno está libre para otorgarle una nueva carga etc... y nos resultaría muy engorroso (aunque desde luego el código sería muy interesante para el aprendizaje), no obstante si lo analizamos bien, nunca se van a producir 2 envíos simultáneos, porque el código del programa es lineal, por tanto realmente 1 sólo camión (para el reparto) puede realizar todas las entregas, además tenemos un medio de organizar todos los 'paquetes' a enviar y toda la logística recáe en el 'almacén'  y en el 'camión' si se ponen de acuerdo, para el almacén por tanto usaremos un objeto collection...:

Por tanto ya sólo nos falta, la logística de interrelación entre el que crea paquetes (disparo de eventos), el receptor de datos, el almacén, y el camión de reparto. En la práctica además de la variable 's_ReparteEventos', crearemos otra, ya que tendremos 2 camiones uno de recogida y otro de entrega, para evitar que mientras uno entrega al mismo tiempo se dé el caso de que se desee enviar y es´te ocupado, tened en cuenta que la recogida en lineal, pero la entrega es asíncrona (respecto de la recogida), luego efectivamente podrían coincidir que a la vez, un camión esté entregando mientras por otro lado se esté cargando su caja... Adiferencia de la empresa de paquetería, nuestros 'camiones' pueden estar al mismo tiempo entregando en el destinatario y recogiendo del remitente, por tanto para evitar esta circunsancia en efecto 'contratamos' 2 camiones, cada uno especializado en una tarea.

Se muestra ahora, finalmente, la recogida del paquete y su guarda en el almacén donde quedará a la espera:
Como se puede ver, hemos llamado al recogedor con una variable aclaratoria, ya dentro de la propiedad texto, vemos que primero ponemos el 'remitente' (identificador) y empaquetamos los datos, dentro del 'camión', finalmente lo llevamos y depositamos en el 'almaccén' (s_AlmacenEv.Add), y como vemos aquí no se dipara ningún evento.

Como se recordará hablamos de añadir un timer al control que llamamos Timeventos, éste será el repartidor de los paquetes (eventos). El timer debería estar desactivado en diseño, y lo activaríamos justo cuando por fin esté en modo de ejecución el control, el punto adecuado para activar el timer, es justo al final del evento readproperties. :
 
Hay que fijarse, el timer se activa en igualdad al modo de ejecución si estamos en diseño (usermode=False), el timer debe estar desactivado, sino veríamos parpadear el título de la ventana de Vb contínumanete, por efecto del timer...

También debe notarse que si el control se desactiva, no lo hace el timer, por lo que podría provocarse un redibujado posterior a deshabilitar el control, lo que como ya sabemos no dibuja el estado deshabilitado. La solución pasa por añadir una línea de control en la propiedad Activo:
Vemos que el timer está supeditado tanto al estado enabled del control como al modo de ejecución. Esto  hace que en tiempo de diseño siempre esté desactivado el timer sin importar el estado del control y en cambio en tiempo de ejecución irá a la par que esté el estado del control.

Para terminar de comprender el método asíncrono, nos falta entregar el 'paquete'. Ahora el código y luego la explicación y comentarios:
Analizando el código:
1º El repartidor comprueba si hay paquetes en el 'almacén' pendientes de enviar: If s_AlmacenEv.Count > 0 Then
2º Si lo hay llenamos el camión de reparto:  (s_ReparteEventos = s_AlmacenEv.Item(1)) con la carga primera que se encuentra.
3º Luego analiza el remitente, (select case .Identificador )
4º Ya que según éste (el identificador), el destinatario será uno u otro: (Case 1 : RaiseEvent TextoCambiado ) hace el efecto del destinatario...
5º Al final depositamos su carga(los parámetros): (Case 1 : RaiseEvent TextoCambiado ( .Param1)   . este evento sólo tenía 1 parámetro que cargamos en Param1.

Si ahora ejecutamos el código, tal como se señalaba más arriba, falla, VB nos canta un error, quedamos en que dejaríamos que apareciera el error, porque el camino lógico de un principante es caer en dicho error, no sería ningún favor si ya de entrada yo marco una solución, un principante (nadie, ninguno) no conoce la solución a un problema que aún se supone que no conoce (no le ha ocurrido). El error que Vb nos arroja dice algo como: 'Sólo los tipos definidos por el usuario públicos de módulos de objeto públicos se pueden usar como parámetros'.
Con este tocho de mensaje lo que Vb nos trata de decir es que no tiene implementada una solución(otra solución que marcar error) para una asignación de datos con las siquientes características: Una estrcutura declarada privada y que está en un objeto declarado público (el usercontrol tiene que ser público para que puedan ser creadas instancias por parte del cliente) no puede ser asignado a determinados tipos. La idea que trata versa sobre el problema para el destinatario, que no sabrá como tratar esa información, en cambio cuando el objeto (clase, usercontrol) es privado, el cliente no tendrá que vérselas con esa información 'cifrada'. Si se piensa bien, es muy razonable, se explica por qué:
ya que una estructura guarda sus bytes de modo consecutivo (como una matriz), puede alojarse cualquier cosa sobre ella, sin embargo si se pasa a un cliente, no sabrá como tratar dichos datos, porque la estructura se declaró privada (no tiene acceso a la información referida a ella), obviamente al ser privada el cliente no sabría si existe identificador, ni param1, etc... ni su orden, ni los tipos que la componen  sólo vería un conglomerado de bytes, por lo que no sabría que hacer con ello. Y habría constantes errores y preguntas acerca de si alguien sabe algo acerca de tal o cual cuestión relativa, a tal o cual objeto... vamos que sería un caos.

Todavía uno podría alegar, vale, pero es que yo no lo estoy pasando al cliente, los datos están declarados privados y se usan de modo privado. La respuesta a esta cuestión es la siguiente: si la estructura (aunque sea privada) se pasa a un variant, ¿ qué impide a un variant pasarlo como parámetro a una función pública al cliente ?... nada lo impide, luego el modo de controlar que no lleguen datos incomprensibles al cliente es impedir que las estructuras privadas vuelquen sus datos a procedmientos públicas o (la otra opción)a variables que puedan usarse como parámetros en procedimientos públicos, que en este caso son los variants y object.

Si declaramos la estructura como pública, (hagámoslo para probar) vereis que el código es totalmente ejecutable y sin error(nota también debe declarase como pública la enumeración que usa el campo Identificador, las razones son partes delas mismas ya explicadas.

Cambiad la declaración de la estructura de privada a pública y de la enumeración afectada, ahora ejecutad el código  y vereis que no hay ningún error. Pero claro naturalmente nosotros queremos aislar esos datos, el cliente no tiene que usarlos, y si no son de su provecho, tampoco deben servirle de distracción. Nada le impide declarar una variable con esa estructura, pero el no podrá usarla en ninguna parte con el control, por tanto adoptaremos ahora la solución que cabe aplicar al caso.

Si  no queda más remedio  que los datos, deban ser público, al menos le impediremos crear instancias de ellos.
Vamos al menú de Vb, proyecto: elegimos agregar 'Modulo de clase', renombremos a la clase con el nombre que le dimos a la estructura y luego, cortamos (CTRL+X) el código de la estructura y la pegamos en la clase (dejando sólo los parámetros, pero declarándolos públicos), también cortamos la enumeración (que señala identificador) y la pasamos a la clase y la declaramos también pública:

Ahora vamos a la ventana de propiedades de la clase, su nombre le cambiamos desde 'class1' al nombre que le dimos a la estructura (si os parece muy largo podeis abreviarlo, eso si añadid una línea comentada donde es explica el nombre de la clase y el propósito de la misma (proveer datos para portar los parámetros de los eventos que se lancen asincronamente), luego buscamos la propiedad instancing y cambiamos su valor a: 2 (publicNotCreatable), esto implica que el cliente verá la clase, pero no podrá crear instancias, a lo sumo usarla y sólo si nosotros le proporcionamos algún objeto público que la utilice (que no es el caso).

El siguiente paso es cambiar la declaración de las variables de 'entrega' y 'reparto':

Y ahora los cambios aplicados en los procedimeitnos recogida y reparto) con los cambios pertinentes ya corregidos, si quereis compararlos con el código anterior, comentad aquel y pegad encima o debajo el nuevo código:

Como se puede apreciar el código no ha cambiado mucho, entre usar una estructura y usar una clase. La razón por la que se destruyen los 'camiones' después de recoger o entregar la 'carga' es porque si no lo hiciéramos podría una de sus variables componentes mantener un valor para el próximo 'encargo' falsificando con ello el nuevo servicio. Naturalmente cada evento 'sella' sus campos, pero siempre hay lugar para errores. Si destruímos los objetos tras utilizarlos (vaciamos la caja del camión en cada servicio) , nos evitamos ese problema. Puede además verse, que la clase es destruída pero qque luego no es vuelta a construir, cómo es eso...?. bien, esto no es un detalle del usercontrol sino de VB, pero bueno... cuando en VB declaramos una clase como 'as NEW', a nivel general (formulario, usercontrol, class...) siempre existirá una instancia del objeto, luego cuando hacemos un set objeto=nothing, el objeto es destruído e inmediatamente es como si declarámos de nuevo la misma variable como 'As NEW' con lo que cuando se invoque algunos de sus procedimeintos, sucede un evento initialize para el objeto. Existen por tanto toda la vida que tiene el formulario, usercontrol, clase, etc...

Ya hemos resuelto los problemas que nos originaba la estructura. Ahora podemos probar de nuevo a ejecutar ese código que pusimos en el ejemplo del cliente, veremos que (salvo que olvidáramos comentar la línea Raiseevent en la propiedad texto) ya no sigue saltando el desbordamiento de pila.. es más uno verá como el control se dibuja a una velocidad endiablada y ve uno fugazmente alternarse 'Lunes' con 'Domingo'. Debe recordarse que lo que señalamos bastante más atrás acerca de los porteros para controlar los bucles infinitos podrían seguir manteniéndose ahora, yo lo he ido retirando del código para ceñirnos al caso que explicaba en cada momento sin distraernos en otros detalles...

Respecto de los eventos finalizaremos por hoy, por comentar que si los lanzamos sincronizados, tal como nos vienen los lanzamos, y con el objeto collection en el modo asíncrono, también como nos vienen en el mismo orden los entregamos. Si fuera necesario podríamos ofrecer prioridad a determinados eventos sobre otros, usando el objeto collection, simplemente tendríamos que indicarle cuando le añadimos, que posición ocupará, cuando no indicamos nada se añade al final... imaginemos que nuestro evento TextoCambiado debiera tener una cierta prioridad sobre todo lo demás, en ese caso, en vez de ponerlo a la cola, lo pondríamos el primero, o por ejemplo el 3º si hay más de 10 eventos pendientes en el 'almacén'.:

También podríamos crear nuestro propio almacén de datos e imponerle algún tipo de manejor de prioridades, pero esto se sale del propósito de esta guía que es el usercontrol.

Hay que decir que para nuestro control, el evento TextoCambiado carece de todo interés y ha servido de excusa únicamente para aprender acerca de los eventos, podemos eliminar todo el código relativo al mismo, o bien si lo preferís simplemente comentarlo, o bien mantener 2 proyectos. En uno, con las pruebas que en cada parte se sugieren y en otro el código 'puro y limpio' que definitivamente será nuestro control Boton.


Por hoy ya sale un mensaje demasiado largo, continuaremos en otra parte comentando acerca de los eventos.

En esta nueva parte acometemos una solución para realizar el foco.

Como sabeis, en un contenedor que tiene varios controles, siempre debe haber uno que sea el control 'actual', el que tiene la atención. Como efectivamente si hay varios se hace más que necesario casi obligatorio, indicar de alguna manera cual de ellos tiene la atención, el foco, ya que se requiere que el usuario final de la aplicación sepa a donde irá a parar por ejemplo una pulsación de teclado. si en este hipotético caso pulsamos la combinación de letras "ALT + P" puede tener un efecto totalmente distinto si se pulsa sobre un botón cuyo texto indica '&Pausar'  que sobre una lista de texto. Sobre el botón se ejecutará el evento 'click', mientras que para la lista se ejecuta el evento 'mousedown'. Si ahora en vez de la combinación dada pulsamos solamente "P", en el botón se ejecuta el evento mousedown, en cambio  en la lista se selecciona un ítem que empiece por 'P', la siguiente pulsación avanza al siguiente ítem que empiece por 'p'.

Por tanto es necesario que el usuario final sepa en todo momento que control tiene el foco.

Es el contenedor quien suplementa casi toda la funcionalidad del foco, por ejemplo provee la propiedad TabIndex a cada control, de modo que cuando se pulsa la tecla 'TAB' (tabulador), envía el foco al control cuya propiedad tabindex dentro del mismo contenedor le sigue al actual, y cuando alcanza el último control del contenedor, la siguiente pulsación va al siguiente control donde el contenedor (que también es un control) está contenido...

Ahora bien aunque el contenedor proporciones casi toda la funcionalidad, la de ofrecer al usuario la impresión de 'ganar el foco' o 'perder el foco' es responsabilidad total del programador que elabora el control.
VB proporciona el efecto de foco a sus controles, por ejemplo si vemos un botón que tiene el foco, éste es rodeado perimetralmente con una línea de puntos. Si miramos un listbox, hace algo casi idéntico, sobre el último elemento seleccionado, lo rodea con una línea de puntos, debido a que está seleccionado, no resulta fácil verificarlo, en cambio si cambiais la propiedad del listbox, 'Multiselect' a 1, vereis como pudiendo seleccionar más de 1  ítem, podreis apreciar claramente la linea de puntos, más aún cuando 'deseleccionais' un elemento, que deja de estar seleccionado, pero sin embargo conserva el foco.

Esto no es todo, el usercontrol proporciona una propiedad (como contenedor que es) llamada ActiveControl, que entrega el control que actualmente tiene el foco. Esta misma propiedad la podemos encontrar en el formulario... los contenedores pueden o no tenerla de acuerdo a si el diseñador 'exportó dicha propiedad o no al cliente, por ejemplo el contenedor picturebox, no lo tiene, pero nada impide que si estamos diseñando un contenedor nosotros si exportemos dicha propiedad. el usercontrol, lo mantien y es útil  si hemos incroporado varios controles en nuestro control (imaginad que en vez deconstruir el botón con tratamiento gráfico, hubiéramos incluído el icono mediante un control image y el texto mediante un control label, etc... Como queremos tener un control absoluto de lo que hace, puede hacer y como lo ha de hacer, nos decantamos (en su momento) por realizarlo todo, nosostros, y no depender de tal o cual funcionalidad que dichos controles pueden tener, carecer o simplemente que no conozcamos en profundidad su funcionamiento y nos resulte por tanto difícil adaptarlo a nuestras necesidades.

También sabeis que el posible enviar el foco a un control mediante la función SetFocus del propio control y que esto sólo funciona si se dan 3 condiciones, el control (o contenedor, incluso un formulario) ha sido cargado, está visible y su propiedad 'enabled' es true, de otro modo´, falla. Por supuesto el usercontrol, proporciona dicha función, pero además cuando se compila el control dicha función se incluye (función extendida) al control,  por lo que no es necesario exponer dicho método en nuestro control explícitamente (el compilador lo hace por nosotros) salvo que necesitemos incluir código, para, por ejemplo, redirigir  el foco a un control constituyente, o realizar determinadas acciones.

Cada contenedor, es de alguna manera responsable, quien se encarga de enviar el flujo al control que corresponda, de hecho sucede una cascada de eventos que es preciso conocer para dotar a nuestros controles de la debida funcionalidad.
Esto sucede a través del evento 'GotFocus', y 'LostFocus', sin embargo hay otros  2 eventos disponibles durante la creación de un control, 'EnterFocus' y 'ExitFocus'. (los eventos  'GotFocus', y 'LostFocus', también se adhieren al compilar si nosostros no los hemos incluído).
EnterFocus, sucede antes que GotFocus, y ExitFocus sucede después de LostFocus. Esto es importante saberlo para poner el código justo en el evento deseado. No es frecuente que necesitemos usar Enterfocus y ExitFocus, pero si que se usa con cierta frecuencia Gotfocus y LostFocus.

Bien, habiendo quedado claro algunos aspectos relativos al foco, ya nos centramos propiamente en el diseño de nuestro control. Como hemos dicho queremos y tenemos que reflejar de alguna manera cuando nuestro control tiene el foco, esto lo haremos de 2 maneras, la primera (que es la que hoy nos ocupa) es gráfica, visual pero para ayudar a usuarios con deficiencias visuales, también la haremos sonora, pero en la siguiente parte.

El modo en que VB refleja el foco es simple pero sobrio y a la vez soso, de hecho hay una API, que realiza esto mismo, dibujar el foco en la manera que lo hace VB, sin embargo como nuestro control provee un relieve perimetral pudiera entorpecer y en cualquier caso no nos complace lo simple que resulta, luego para el caso , he decidido dibujar una pelota que se mueve rebotando por las paredes del control... cual espectro fantasmal en un castillo...  Eso si, la pelota ha de tener un tamaño lo suficientemente pequeño para que no resulte molesto y los suficientemente grande como para que sea advertido, en cualquier caso nunca conviene que sea mayor de cierto tamaño para evitar un exceso de consumo gráfico, por tanto una 'pelota' de entre 6 y 20 ´px, de radio es suficiente para controles muy pequeños hasta controles muy grandes. en nuestro caso vamos a fijar el tamaño de la pelota a 12 píxeles.

Definamos entonces con claridad como ha de operar:
   Una pelota de 12px (tamaño fijo)
   Cuando gana el foco, la pelota se ve y se mueve
   El movimiento es en la forma: rebotando diagonalmente (angulos de 45º) contra los bordes del control.
   Cuando pierde el foco, se queda invisible y deja de moverse
   Cuando se redimensiona el control, la pelota se centra en el control y su movto. continúa en la dirección que llevaba
   Para dibujar la pelota usaremos un control de tipo  shape, que son muy ligeros y nos permiten algunso efectos gráficos sencillos sin complicarnos en exceso. Además nos permite elegir entre varias formas geométricas (que uno podría seleccionar aleatoriamente).
    La pelota ha de moverse en unidades de tiempo, que podemos probar y fijar valores una vez estemos de acuerdo en como funciona. Básicamente si es muy rápido puede resultar molesto y distraer en exceso laatención, y si es muy lento, puede pasar desapercibido... de un modo simple se acepta que 300msg. es un tiempo de respuesta que el ojo percibe con claridad, luego procuremos que exista un movimiento suficiente en esos 300msg. para que la atención visual lo perciba sin distraernos  (que no cambie de ser observado por un ojo  a otro en su mayoría).

Antes de empezar a meter código, primero declararemos las variables que vamos a usar...:

Vayamos pués escribiendo el código. Lo 1º es añadir un control shape a la interfaz del control, que llamamos ShaFoco. Así mismo el control (la pelota), lairemos moviendo con un control Timer que llamaremos TimFoco. Y ahora si, creamos dentro del evento timer una llamada a una función que realiza el movimiento definido como acordamos, le pelota al chocar contra los límites del control, rebota... El movimiento es diagonal (45º).

El movimiento de la pelota ya está descrito, ahora fijamos donde se le llama y cuando...


En diseño desactivamos el timer TimFoco, no queremos que se ejecute nada más cargarse el control si no sólo cuando reciba el foco. Podría ponerse opcionalmente en el evento initiproperties la línea: TimFoco.Enabled = False, para garantizar o recordar que así sea y además también en Readproperties, junto a las líneas que acabamos de poner.
El intérvalo del timer, también puede serfijado en diseño sobrela interfaz, pero resulta muy evidente como recordatorio si se especifica también en readproperties.
Debe tenerse en cuenta que tanto la propiedad interval del timfoco como los valores de desplazamiento de lapleota (dX y DY), son los que determinan la sensación de velocidad de movimiento de la pelota.. valores altos de Dx y DY proporciona una sensación de avance a saltos, cuanto más pequeño más fluído pero entonces el avance por unidad de tiempo es escasa, con lo que necesitamos disminuir interval, si interval se reduce mucho la rutina de avance de la pelota se ejecuta muchas veces, debeis encontrar un punto que satisfaga tanto la visual como el 'castigo' de la CPU. en lo expuesto avanza 3 px cada 20 msg, es decir en 300msg, avanza 45 px. para un tamaño típico de botón puede ser adecuado o incluso mucho. Yo lo pongo fijo, pero sería acorde que tanto el tamaño de la pelota como el avance dependiera del tamaño del control. El objetivo es ilustrar el efecto y vosotros ya lo adpatereis a vuestras consideraciones y necesidades.

Fijaos que dichos valores dX y DY, no son guardadas como propiedades, sino que se fijan a un valor inicial y si es preciso se cambian dinámicamente, debeis eso si aseguraros que cuando se asigne un valor basado en una función, nunca tomen  valor 0, que implicaría linea recta en la otra dimensión, o peor aún, si ambos son 0, se queda fijo y no se mueve. En nuestro caso los valores posibles que tomarán  serán siempre o 3 o -3, además logramos que el movimeinto sea diagonal en el momento que dX=dY, si quereis algún otro ángulo debeis jugar con dicha relación. dX=dY proporciona los ángulos 45º+0, 45+90, 45+180, 45+270 Esto es simples matemáticas..

Ahora la intercepción de puesta en marcha y paro del timer.
Como se indicó el foco sólo se recibe si el control está cargado, visible y activo, por eso usamos estos eventos para poner en marcha el timer y recíprocamente 'ver' el shape...

El shape en diseño puede ponerse la propiedad visible=false, además en diseño establecemos las siguientes propiedades (estas quedarán fijas operativamente) o bien pueden establecerse (también) al final en readproperties:
En cuanto a fillcolor, no importa, puesto que tenemos drawmode en 'invert', si fijáramos otro valor este color se fusionaría con el de la imagen, pero según el color elegido y el de la imagen podría no ser satisfactorio el resultado, es cuestión de que probeis...
En cualquier caso una pelota de color rojo siempre destaca si el fondo no es tambén similar...

Sin embargo nuestro movimiento no es perfecto, si lo ejecutamos en este momento, porque todavía no hemos establecido los valores para el punto de impacto 'sX' y 'sY'. Añadimos la siguiente línea justo debajo de donde pusimos dX=... dY=...
Ahora ya la detección de choque se realiza exactamente igual por los 4 costados. Este es el propósito de dicha línea (los valores que luego se utilizan para el cálculo de la colisión)

Ya nos falta menos.. Qué pasa si en medio de la marcha de la pelota se desactiva el control ?... el timer está en marcha, entonces, seguirá corriendo ?. No, porque cuando el control sedesactiva, se pierde el foco, el contenedor tiene que enviarlo a otro control, a qué control ?, justo al siguiente con el tabindex que le sigue dentro del mismo contenedor. cuando esto sucede se recibe un evento lostfocus, que recordemos desactivaba nuestro timer y hacía invisible al shape.
Podemos comprobar dicha funcionalidad, vayamos al formulario, añadamos varios controles, fijémosos en el tabindex de la instancia de nuestro control y en qué control sigue en el tabindex al control. Ahora añadamos un tmer al formulario pongamos en interval el valor 10000 (10 segundos) y este código dentro de su evento:
Ahora ejecutemos el proyecto y hagamos sólo una cosa, pulsemos en nuestro botón, para que tenga el foco y esperemos... después de 10 segundos saltará el timer y desactivará el botón, y veremos como aquel control que le segúia en el tabindex es ahora el que gana el control. si queremos verificarlo mejor, id al código del botón y poned un punto de parada en el evento: 'Private Sub UserControl_LostFocus()' . Volved a correr el proyecto, vereis como al pasar los 10 segundos, se invoca dicho evento, nuestro control pierde el foco y se para el timer y se oculta la pelota. Luego tal como hemos dicho, no tenemos necesidad de añadir código en el caso de deshabilitar el control.

Efectivamente falta menos, es el caso de cuando el control cambia de tamaño. si era pequeño y luego se hace más grande, no importa, pero imaginad un caso alrevés, un botón de 800x200px  que luego se reduce a 200x20 px... (probadlo si quereis). ...un posible resultado es que si cuando se cambia el tamaño la pelota tiene una posición fuera del nuevo tamaño, los límites ahora harán que rebote cuando se alcancen, es decir rebotarán, pero 'por fuera'. Podemos probar que sucede esto cambiando ligeramente el código del timer que añadimos al formulario cuando anteriormente hemos probado a desactivarlo:

Esto entonces debemos controlarlo, desde el evento resize de nuestro control, reubicando la pelota (por ejemplo) en el medio de nuestro control...
Ahora ejecutad de nuevo el proyecto y esperad a que salte el timer, vereis que ahora si la pelota sigue rebotando, pero dentro, como debe ser...
También debis notar como la sensación de velocidad es mayor sobre un control  muy pequeño con respecto a un control muy grande, es por eso que os dije que puede interesar hacer dinámico (variable) la propiedad interval del timer,  el avance de la pelota dX y dY... y el tamaño de la pelota. También es adecuado pensar que en controles muy alargados sean verticalmente u horizontalmente mantener un ángulo de movimiento diferente de 45º, probad a fijar elsiguiente valores para dX y dY:
Estos valores sobre uncontrol de poca altura y muy largo permite un avance horizontal con menos rebotes verticales, que cuando dx=dy... probad a cambiar los valores entre si en dX=1: dY=3 y ejecutadlo, ahora osresulta más evidente qué solución podeis adoptar en cada caso...

Para finalizar esta parte, incluiremos una nueva rutina de 'tengo el foco'. Digamos que la rutina actual resulta muy evidente y queremos una solución parecida pero más sobria... para lo cual parece adecuado por ejemplo que nuestra pelota simplemente 'de vueltas' cual atleta alrededor del estadio... Hay que decidir en qué sentido gira para darle los valores adecuados...
Lo 1º es crear la rutina que realiza el movimiento:
Es importante notar que un estado de avance se comprueba hasta que dicho estado cambie, es decir suceda el caso, mientras no se comprueba ningún otro caso.... a diferencia de lo que sucedía en la rutina anterior (ReboteDiagonal) donde debían verificarse todas los topes cada vez.

Luego quedan algunos cambos menores, como la invocación a la rutina que hemos creado ahora:

Cambiar los valores de 'dX' y 'dY', ahora se mueven en línea recta, luego uno debe valer 0 cuando el otro tenga un valor distinto, esto se hace en la rutina previa, pero hay que establecer inicialmentelos valores (no es imprescindibles, ante el primer choque se establecería un valor a 0.
También el valor de choque, antes el impacto se detectaba cuando se alcanzaba el centro de la pelota, ahora queremos que se detecte cuando alcance la parte extrema de la pelota, como antes, esto se calcula en la rutina anterior, pero necesitamos establecer los valores adecuados para 'sX' y 'sY'.
Si quisiéramos que la pelota circulaa a una distancia de margen respecto de los topes del control, añadiríamos esos píxeles a 'sX' y 'sY'. Pero además en nuestra rutina de movto. deberíamos en los topes que se comprueban con '0', poner el valor de margen elegido, lo mejor pués sería usar una variable llamada MargenFocoEstadio (o algo similar), cuando no queramos margen ese valor es 0, y esa variable se suma a sx y sy y el '0' de las comprobaciones se remplazar por dicha veriable.
quedaría por ejemplo así:
Recordar que el movto es sentido antihorario, cambiar el sentido es tan sencillo como cambiar de orden las veces que aparece la variables de 'avance', al valor correcto (o cambiando el valor de cada 'case').

Y con esto damos por terminado esta parte, sólo recordaros que podeis crear diferentes rutinas de movimiento y quedaros con la que más os guste, talvez un movimiento de zig-zag de derecha a izquierda sobre el centro del control, o... lo que se os ocurra.

---------------------

En la próxima parte trataremos un aspecto ligado al foco, pero sobre el que VB no ofrece ninguna funcionalidad, salvo para controles sin ventana, que no es precisamente el caso... hablamos concretamente de 'control apuntado' pero que no mantiene el foco aún, no ha sido enfocado, pero el cursor está sobre el control...

Perdonad que no haya terminado... pero he estado bastante ocupado.

En las próximas semanas espero encontrar el tiempo suficiente para terminar las partes que quedan...

Tranquilo amigo, este tema es un buen manual de consulta.