Unos correos del 2001 interesantes sobre activex.
Creo que es tiempo de empezar a ver los controles OCX, que son y para que nos sirven, y para que NO nos sirven.
Asi como poco a poco hemos ido viendo datos sobre acceso a datos, empezaremos a ver de manera clara y gradual el manejo de controles OCX. Les aviso desde ya que esta introducción a muchos puede no gustarles, o parecer que yo diga que no sirven. Lo que quiero decir es que no puedes hacer todo con controles OCX, y que los controles no suplen los métodos normales de programación. No todos los desarmadores sirven para todos los tornillos. A partir del próximo correo empezaremos a ver para qué si sirven realmente los controles OCX. Asi como RDO sirve para ciertas cosas, no se debe de usar para desarrollos nuevos, por razones varias que comentamos en otro lugar y que pueden consultarse en muchísimos mas.
Empecemos sobre lo que no se debe hacer con los controles.
Historia
Para evitar confusiones comento que solo haré referencia a las clases desde VB5, aunque con VB4 se puede, es algo engorroso describir aquí.
Pasemos a la historia de los controles OCX. En 1993 Microsoft utilizaba una tecnología llamada OLE, en la que se podian establecer Lazos desde aplicaciones. Bruce Hinskey ( Autor del libro hardcore Basic ) tenía que ver con la definición de standares para los controles.
No se sabe bien de quien fue la idea, pero al mismo tiempo un grupo de Microsoft trabajaba en lo que se llamaba Excel Basic y Word Basic ( que en paz descansen ) pero aunque eran funcionales para hacer código, tenían el problema de que no funcionaba entre diferentes versiones del mismo producto, es decir, algo hecho en Excel en Ingles, no funcionaba en Excel en Español.
Mientras tanto se habia creado una nueva generación de empresas dedicadas a vender «anexos» a Visual Basic 3, que tenían la extensión VBX y generalmente estaban hechas en C. Todo esto era en la epoca de Windows 3.11.
Pues cuando se preparó VB4 surgió el problema de que ya se iba a manejar a 32 bits el sistema operativo, con Windows 95, y por lo mismo se hizo un desarrollo enfocado a poder usar diversos lenguajes, utilizando la idea de VBX pero aplicandola a otros lenguajes.
Esto fue la primera versión de OCX. Sin embargo, al poco tiempo a alguien se le ocurrió ligar los OCX con las clases, y se desarrolló un nuevo Standard llamado OCX 96 , al que conocemos mas bien como Activex. Pueden leer una pagina que tengo sobre activex en Active X .
Después empezó a surgir otra vez un mercado de controles personalizados para suplir las deficiencias de los de Microsoft, los mas conocidos son Sheridan, una empresa que generó el TrueGrid ( No recuerdo cual ) y otras importantes como Merant y Sybase con su Formula One.
Pero.. el mal código y el mal diseño son malos por donde se mire, y surgieron grandes problemas:
El mal diseño es malo aquí y en China
1)
A partir de la versión 5 del VB, era posible desarrollar controles ( hasta salió un VB5 Control edition, si no me equivoco ) , pero la mayor parte del código disponible correspondía a programadores que se complicaban la vida. Voy a explicarlo de otra manera:
Todos sabemos que algo que no está enabled no puede tener el foco, pero alguien hacia este proceso:
private function Pon_Foco( micontrol as control)
if micontrol.enabled then
micontrol.setfocus
else
‘ no puedo poner foco,
endif
end sub
Ese programador juntaba diez rutinas similares, Luego lo volvía control OCX, y quería que le pagaran por ello 30 dolares.
Otra forma que sucede es a la inversa.
Sabemos que :
2*2=4
2+2=4
1+1+1+1=4
2*2*2/2=4
.25*8=4
Y muchos controles y clases OCX son así. 8*.25=4. Cuando es mas cuerdo y rápido 2*2.
2)
La empresa equis quería un grid que permitiera cambiar el título de un dbgrid. Asi que como el programador no sabía como dar el efecto, compraban un grid de marca patito o no que lo hiciera, y luego se actualizaba por cada cambio de Sistema Operativo o compilador.
3)
La empresa equis tenía un buen montón de codigo hecho en clipper, fox o similar, y de repente decidían pasarse a windows. Como Trataban de seguir pensando en «reutilizar el código anterior» y pensar en modo DOS, empezaban a hacer programas que no funcionaban como debían, y era necesario comprar controles que «lobotomizaban» el procesador para que hiciera ciertas cosas o dieran el efecto del anterior , en vez de usar las prestaciones del actual ( ver punto uno )
4)
Hay un sistema interno de mensajería que funciona con DBFS y no ha tenido problemas.Consiste en ABC y un proceso que muestra mensajes no vistos. Algun genio decide lucirse dentro de la empresa, y hace código en Apis que envia de una terminal a otra por winsock QUE NO FUNCIONAN DE UN SISTEMA OPERATIVO A OTRO ( y a veces en distintas máquinas con el mismo SO tampoco), que mejora el rendimiento en veinticinco diezmilesimas, y quita todo lo anterior. Pero además ya no guarda los mensajes para referencia. Este ejemplo en particular es terrible por lo frecuente, y muchos creen que eso es ser buen programador, cuando lo que debió hacerse es pasarlo a ADO o instalar ICQ.
Reutilizar código solo cuando vale la pena hacerlo
La solución por lo general en todos los casos es cambiar el enfoque de pensamiento. Muchos sabemos que el proceso de un negocio es básicamente general, tienen deudores, cuentas por pagar, pedidos, etc, y son unos cuantos los procesos que cambian. La llamada standarización es sentido común, y sobre todo aquellos que trataban de cambiar de clipper a VB, cayeron mucho en la trampa de olvidarse que estaban programando en Visual.
A principios del 98 realicé un sistema en Vb versión 5, con OCX y DAO/SQL, de otro sistema de Clipper-ASM-C MUY grande, también hecho por mí. Lo que hice fue tomar los menús, una descripcion de los procesos y reportes ( sin mirar el código, eh ? ) , y el 90% era simple ABC, mas uno que otro proceso especial que correspondía al giro de la empresa. Me tomó tres meses dejar funcionando TODO en multiusuario, porque ABC estaba a los ocho dias. Fueron dos meses y medio de portar los procesos específicos del giro de clipper a VB.
Ahora bien, poco después por azares del destino y con el sistema VB funcionando en paralelo, se contrató a Coopers and Lybrand para hacer un análisis, pero sobre el sistema de clipper. Recibí la orden de desechar el sistema de VB que ya tenía instalado en paralelo en varias plantas y regresar al anterior. Lo hice. Se contrató a dos programadores VB altamente rotativos ( solo uno quedo de planta y otro lo rescataron del despido despues de haber pasado por tres o cuatro ) y llegué a recibir Memorandums en que se me preguntaba «Explique por favor para que sirve la orden PADR que usa en su código y donde tiene definido el código fuente, sin mas por el momento quedo de usted».
Para los que no manejen Clipper, los programadores VB querían que les explicara el código de una función interna de Clipper, mas o menos como si alguien me pidiera el código fuente de Form1.Show.
A los dos años apenas estaban empezando a liberar la nueva versión de VB, porque se estaba tratando de portar Clipper a VB, en vez de hacer VB. Y además estaban usando RDO.
Lo que SI se debe hacer con los controles
Los controles OCX evitan esta situación permitiendo utilizar código entre lenguajes y proyectos, lo que puede ser bueno si el código esta bien hecho, o espantoso si pasamos todos los errores de diseño TAMBIEN al otro Lenguaje, o al otro proyecto. Como dije en otro correo hablando de RAD, se trata de hacer las cosas simples y eficientes, y utilizar controles que no podemos ver el código tiene problemas, sobre todo si fueron hechas por otras empresas.
Los Controles nos dan desempeño si no nos casamos con tecnología sino con diseño y sentido común.
En el lenguaje que sea programar ABC es rápido, pero portar del lenguaje que sea al que sea, es lento. A mi me tocó en un momento dado, tener ocho programas diferentes en la misma empresa pero diferentes plantas, en tres versiones cada uno y a veces mas. Clipper, Clipper Gráfico, Visual Objects, Visual Basic. Pero todos usaban los mismos datos. El resultado de esto es…
Tengan una sola versión funcionando que use los mismos datos. Quiere reutilizar el código propio ? Vale la pena si vale la pena. O es un control Ponfoco.ocx ?
Y esto es solo sentido comun, para nada estamos hablando de ser avanzados.
Para poder ser claro, es necesario usar la navaja de Occam y hacer las cosas mas sencillas posibles. En lo personal no recomiendo usar OCX externos, prefiero que me paguen a mi lo que cuesta el control, y estar seguro que no tiene a su vez funciones destructivas. Casi no conozco empresas que garanticen su OCX, o si?
El control darakan OCX que veremos mas adelante, es un control que empezaron a usar varios programadores de una empresa y estaba volviendose el standard, y resultó tan práctico que lo usan ahora varios de ustedes, lo uso yo en proyectos por fuera, y sin embargo.. los programadores «RDO» con «SQL de alto desempeño» signifique lo que signifique, han olvidado que el poder de cualquier lenguaje está en el programador, pero eso no significa dejar de lado ICQ para programarlo por Winsock.
Quizá sea mas facil hacer algo en VB que en ensamblador. Pero son las técnicas lo que diferencian al buen programador del malo, no el lenguaje o los medios que utilice.
Si ustedes ven de repente un programa abierto con 12 indices en clipper o El SAE de Aspel, por ejemplo, no es simbolo de buen trabajo, me explico?
Y Con los controles OCX, que se van creando para el propio uso, hay cosas que pueden usarse en lenguaje C, VB, Visual Objects, y que no se tienen que mover en tres años; que se actualizan perfectamente bien con win2000 o w95, con Access o con SQL-MSDE.
El secreto de los controles es la reutilización del código, pero si tratamos de integrar de Fortran a Visual Basic, o de clipper a Visual Basic, solo debemos hacerlo en lo que NO es ABC o RAD. Los que trabajan en ventas por ejemplo, solo tendrían que rehacer desde cero o reutilizando, el proceso de liquidaciones. Los de las empresas de molinos, el proceso de básculas, las de multinivel las comisiones.
Los procesos generales deben hacerse de manera general y RAD, siguiendo el standard, y el standard es Windows, mal que les pese a algunos, y no nuestros programas. Pero usar Windows No es obligación de usar Apis para saber que 2*2*2/2=4.
Como dice la firma de una persona de una lista de VB..
«No subestime la capacidad de un lenguaje
de programación, el poder está más en la
lógica del programador que en las facilidades
que brinde la herramienta»