Unos correos del 2001 interesantes sobre activex

---

Clases, Tipos fuertes y parámetros

Tipos fuertes

Uno de los detalles que hacen utilizable realmente a Visual, es una mezcla entre los tipos de datos fuertes y débiles. Que es esto? Bueno, a grandes rasgos, Turbo Pascal se distinguió en su momento por la capacidad de darle un tipo determinado a una variable, por ejemplo, byte, shortint, string, longint, char, text, por decir algunos. Aunque las versiones originales de Basic, QBASIC y BASICA permitían una declaración de tipos fuertes, Los que usamos BASIC en ese tiempo, estábamos acostumbrados a ordenes como DIM NOMBRE$, donde el $ era equivalente al actual as String.

Por razones de compatibilidad, y de sentido común estructurado, poco a poco Microsoft fue creando una gran variedad de tipos de datos, algunos utiles y otros no. Por ejemplo, estan String, Variant, Object, Integer, Boolean, Single, Double. Pero, debido a que muchos programadores estaban acostumbrados a hacer las cosas a la carrera, desde la primera versión de Visual Basic for Dos, se tuvo que permitir utilizar tipos debiles, que significa esto ?

Un programador poco experimentado podía no declarar una variable, o cambiarle de tipo sobre la marcha. Un programa podía ser, por ejemplo:

10 nombre = space(30)
20 input nombre
30 print nombre
40 nombre = 0
50 for nombre = 1 to 10
60 hazotracosa
70 next nombre
80 goto 10
El verdadero problema fue que BASIC no solamente empezó a usarse por estudiantes, como fue en su momento, sino por profesionales que no tenian a la mano un compilador de Fortran, Pascal, o C. Y como Basic venía incluido en el MSDOS, Microsoft se encontró con que los programadores «avanzados» necesitaban características que no existian; por lo mismo el compilador en si tuvo que adaptarse. Recuerdo que en un momento dado Borland sacó un compilador llamado Turbo Basic, que compilaba en base a tipos fuertes. Para evitar la perdida del mercado, cuando se empezó a Promocionar el QBASIC, ya permitia usar tipos fuertes o debiles, sin embargo, empezaron a suceder problemas porque algunos programas hechos en BASICA, no funcionaban con el nuevo compilador, porque estaban hechos con tipos debiles.

Microsoft creó entonces un tipo de datos similar a lo que es el «any» a Lenguaje C, y su problema básico quedó resuelto. Pero se crearon problemas nuevos, para variar, el nuevo tipo fue llamado VARIANT, y es el tipo de datos predefinido por Visual Basic en las versiones actuales.

Porqué se crearon problemas? Bueno.. Aqui debo regresar otra vez a los tiempos de TP y C. El principal inconveniente de Turbo Pascal era la limitación de un programa a 64 kb de código y 64 kb de «data»; esta era una limitación porque por ejemplo, definir una cadena como string[255], usaba 255 bytes de 64,000 disponibles. Empezó a ser obligatorio andar haciendo ajustes en TP para convertir longint a shortint, y demás. (Esto no es estrictamente cierto, pero si usabas punteros en Turbo Pascal no tienes nada que hacer leyendo esto).

Visual no tenía este problema. Lo unico malo es que su tipo de datos Variant ocupaba bastante mas memoria que un integer, por ejemplo. Y un Variant permitía al mismo tiempo hacer cosas que no se debían segun los puristas. Utilizando el ejemplo anterior, la versión VB sería

dim nombre as string
nombre = space(30)
nombre=inputbox(«Introduzca el nombre»,,nombre)
print nombre
nombre = 0
for nombre = 1 to 10
hazotracosa
next nombre
Que si bien es perfectamente válido, permite errores como sumar algo que no debería sumarse. Pero si cambiamos el Dim nombre, por un Dim nombre as string, ya no es posible compilar el programa. Usando la metodología de tipos fuertes, el código debería ser:

dim nombre as string
dim i as integer
nombre = space(30)
nombre=inputbox(«Introduzca el nombre»,,nombre)
print nombre
for i = 1 to 10
hazotracosa
next i
Esto tuvo una serie de efectos no apreciables a largo plazo. Realmente el principal problema fue que los programas que no definian el tipo, es decir, que decian dim variables sin decir el tipo ( as string por ejemplo ), ocupaban a veces 10 o doce veces mas memoria de la necesaria. Se ha hablado mucho de elegir los tipos de datos correctos al programar, usar en lo posible integer por ejemplo, que esta ligado al sistema operativo y ademas de usar menos memoria que un long, se ejecuta mas rapido.

Para fines prácticos, lo que necesitamos saber es que ademas de los tipos de datos tradicionales, existen dos tipos llamados comodines, que son Variant y Object. Mas adelante hablaremos sobre Object. Un ultimo detalle es que los tipos en Visual Basic, si no se define el tipo, quedan como variant por default, ejemplo:

dim a,b as string ‘ a es variant, b es string
dim c,d ‘ c y d son variant
dim e as string, f as string ‘ los dos son cadena.
Quiero destacar que no necesariamente usar Variant es malo, solo que tiene la desventaja de ser mas lento y usar más memoria, pero hay ocasiones en que voluntariamente a fuerzas la solución mas elegante es usar variant en algun proceso. Sin embargo, creo que un buen programador siempre debe de tratar de usar en lo posible tipos fuertes ( y se evita el problema de hacer «casting» como en lenguaje C ).

Parámetros

En el correo anterior mencionamos algunas cosas sobre los sub y function, pero hay que hacer de una vez una aclaración importante. Los Function o funciones, pueden ( y en casos ideales deben ) regresar un tipo fuerte. Si nosotros no especificamos el tipo, obtendremos un variant. Veamos un ejemplo:

private function nombre_empresa
dim pass as string
pass=»www.laempresa.com»
nombre_empresa=pass
end function
Fuera de toda lógica aparente, el resultado será un variant y no un string. Lo correcto sería:

private function nombre_empresa as String
Muchas personas se preguntan que es un parámetro y para que nos sirve. Nos sirve para modificar nuestro código sin tener que hacer gran cambio. Por ejemplo, supongamos que hemos hecho un programa que usan nuestras diez sucursales, pero no queremos hacer una funcion diferente para cada una. Vamos a suponer que de un lugar determinado, leimos el numero de la sucursal o empresa y lo guardamos como la variable numcons. Y mas adelante queremos hacer un reporte que de un encabezado diferente para cada sucursal. Podríamos usar algo similar a:

private function nombre_empresa (num_empresa) as String
dim pass as string
select case num_empresa
case 1: pass= «www.laempresa.com»
case 2: pass= «www.laempresa2.com»
case 3: pass= «www.laempresa3.com»
case else
pass = «Empresa desconocida !!!!»
end select
nombre_emperesa=pass
end function
Este código nos permite de manera muy simple usar en la cabecera del reporte un print nombre_empresa(numcons), que hace el código mas legible.

Es importante destacar que podemos usar también tipos fuertes en los parámetros, e igual que dijimos antes, si no especificamos el tipo por default tomará variant, por lo que si queremos tipos fuertes, deberíamos declararlo así:

private function nombre_empresa (num_empresa as integer) as String
Parámetros por referencia y por valor

Otro de los detalles que nos heredó BASIC / BASICA, fue que cuando empezaron a usarse los procedimientos en la versiones mas avanzadas, los procesos a veces cambiaban el valor de una variable. Por ejemplo, supongamos un sub que genera el cuadrado de un numero:

numero=4
msgbox numero
call cuadrado(nume)
msgbox numero

private sub cuadrado(nume as integer)
nume=(nume*nume)
end sub
Nos da una desagradable sorpresa. Numero ahora vale 16, aunque no debía ser. Esto se debe a que por default, Visual Basic toma los parámetros por referencia, es decir, considera el parámetro como el NOMBRE de lo que debe cambiar. Una aproximación mas razonable, y menos propensa a errores, sería declarar lo anterior como una función o function, ya que obviamente regresa un valor, asi que por principio de cuentas no tiene nada que hacer como sub.

numero=4
msgbox numero
msgbox cuadrado(nume)
msgbox numero

private function cuadrado(BYVAL nume as integer)
nume=(nume*nume)
cuadrado=nume
end function
Esto nos permite evitar efectos secundarios en el código. La palabra Clave BYVAL es un indicador que le dice a Visual Basic, que solo tome el VALOR del parámetro, sin alterarlo. Los que han seguido las lecciones desde el principio, recordarán que dije que usar parámetros byval nos quita muchos quebraderos de cabeza. Ahora es posible entender de manera mas completa el ejemplo que puse en el correo anterior:

Public Function Padl(ByVal cadena As String, ByVal largo As Byte) As String
If Left(cadena, 5) = «- » Then cadena = Trim(Right(cadena, Len(cadena) – 5))
If largo >= Len(cadena) Then ‘ no simplificar
Padl = String(largo – Len(cadena), » «) & cadena
Else
Padl = cadena
End If
End Function
La regla es usar siempre BYVAL en los parámetros, y si necesitamos el modo standard , usar en su lugar la palabra clave BYREF, aunque esto no es obligatorio puede hacernos la vida bastante mas sencilla. Finalmente nuestra función quedaría:

private function nombre_empresa (byval num_empresa as integer) as String
Además nos protege si por error cambiamos el valor de num_empresa dentro del proceso, y al ser byval, un beneficio adicional es que el código se ejecuta mas rápido.

Clases

En la lección anterior decíamos que una unidad de Turbo Pascal nos permitía procesos publicos y privados. Una clase de Visual Basic, disponible desde la versión 4, nos permite lo mismo, sin embargo, para fines prácticos vamos a referirnos solamente de VB 5 en adelante. Un detalle interesante, es que una clase de Visual Basic NO es algo orientado a objetos, por lo menos en su forma pura. Los que han manejado OOP conocen terminos como herencia, polimorfismo, etc, pero VB no permite algunas de las características distintivas de los objetos, por lo menos en la forma tradicional.

El tema de las clases es muy extenso, y lo tomaremos en las siguientes lecciones. Por mientras , sugiero que hagan un pequeño experimento. El archivo Bas que generamos en el correo anterior, desde windows o sistema operativo cambienle la extensión de BAS a CLS

Unos correos del 2001 interesantes sobre activex.

---

abemos que un buen programador o equipo de programadores no reinventan el hilo negro cada rato. Para poder llevar un control de lo que se ha hecho, es comun que usemos partes de nuestros programas anteriores. Si bien era común que se usara el modo de cortar y pegar hasta 1990, cuando se popularizó el uso de Turbo Pascal, de Borland, se le dio difusión a la idea «aparentemente» nueva de encapsular los procesos usandolos en varios proyectos, en versión compilada. Estos trozos reutilizables y NO MODIFICABLES POR TERCEROS de código, eran llamados units, o unidades, y eran muy parecido a lo que hacía C, pero se manejaba desde dos puntos de vista:

Interfase >( Rutinas publicas a otros proyectos )
Implementation ( Rutinas internas a este proyecto )
Junto con la implementación de un sistema llamado de «tipos fuertes», esto provocó que Turbo Pascal se hiciera un favorito en su tiempo, y ahora es un lenguaje gratuito en la versión 5.5 y esta disponible en el mismo sitio de Borland, o en la sección de archivos del grupo.

Con el paso del tiempo Clipper tuvo que crear una versión similar, creandose las llamadas Librerías, que permitian lo mismo solo que todos los procesos eran interfase, es decir, publicos. Aqui se dieron las primeras posibilidades reales de integración multilenguaje, entre MASM, TASM, C estandar microsoft, y clipper / dbase. Cabe destacar que una ventaja extra de estas librerías de CLipper era que podian usarse en diversas versiones del compilador y en cierta medida por otros lenguajes, mientras que las librerías de TP eran unicas para version de compilador, una librería 5.5 no funcionaba con 6, por ejemplo. Estos son los archivos LIB, que reconocerán los que usan librerías de terceros, como CATOOLS, FASTLIB, o mi propia CADMUS, UNIT.

Las dos principales diferencias de las versiones actuales de Visual Basic contra las versiones de QBASIC o BASICA, son los llamados tipos fuertes, que veremos mas adelante, y la posibilidad de crear procesos publicos y privados.

Todos sabemos que podemos crear functions y subs, que devuelven y no respectivamente un resultado. Los famosos archivos BAS que vemos en los proyectos, son librerías de SUB y FUNCTION, que son publicas a todo el proyecto. Sin embargo, estas rutinas deberían ser lo suficientemente generales y bien diseñadas para poder usarse en varios proyectos. Por lo general los sistemas realmente pesados que suelo hacer en VB, tienen tres modulos:

proyecto.bas ( por ejemplo, perfum.bas, inv_equipo.bas ) donde guardo el código que solo sirve para este proyecto por ser demasiado específico.
reporte.bas Aquí guardo el codigo que genera todos los reportes de este proyecto. No hay confusion de nombres porque cada proyecto tiene su directorio.
clasific.bas Las rutinas generales que no he enlazado en una clase.
Vamos a suponer que ya tenemos una serie de procesos que podemos usar en otros programas y queremos volverlos un control. Vamos a suponer que no tienen que ver con los controles que estan en ningun formulario, es decir, vamos a suponer que no tenemos ninguna llamada tipo

Form1.Caption=»Este es el nombre de mi programa»
Para este caso usaré tres rutinas que uso mucho en mis proyectos, y que son «hijas» de CLipper. Cada una de ellas se parece a una orden de clipper, pero es su versión en VB.:

Taller:

Crear un nuevo modulo de VB al que le pondremos clipper.bas, y pondremos dentro este código:

option explicit
Public Function strtran(ByVal origen As String, anterior As String, nuevo As String)
Dim posicion As Integer
Dim cadpaso As String
Do
posicion = InStr(origen, anterior)
If posicion = 0 Then Exit Do
cadpaso = Left(origen, posicion – 1) & nuevo
cadpaso = cadpaso & Right(origen, Len(origen) – (posicion + Len(anterior)) + 1)
origen = cadpaso
DoEvents
Loop
strtran = origen
End Function
Public Function Padl(ByVal cadena As String, ByVal largo As Byte) As String
If Left(cadena, 5) = «- » Then cadena = Trim(Right(cadena, Len(cadena) – 5))
If largo >= Len(cadena) Then ‘ no simplificar
Padl = String(largo – Len(cadena), » «) & cadena
Else
Padl = cadena
End If
End Function
Public Function Padr(ByVal cadena As String, ByVal largo As Byte) As String
If Len(cadena) > largo Then cadena = Left(cadena, largo)
Padr = cadena & String(largo – Len(cadena), » «)
End Function
Public Function Padc(ByVal cadena As String, ByVal largo As Byte) As String
If Len(cadena) > largo Then
Padc = cadena
Else
Do Until Len(cadena) = largo
cadena = cadena & » »
If Len(cadena) = largo Then Exit Do
cadena = » » & cadena
Loop
End If
Padc = cadena
End Function
Una vez que tenemos hecho lo anterior, podríamos utilizar este archivo con atributo de solo lectura, en varios proyectos. Porque de solo lectura? Porque lo que se tiende a hacer es o cortar y pegar, o modificarlo directamente. Un problema de modificar directamente en cada proyecto un modulo ( que asi se llaman los archivos BAS ), es que podemos terminar con muchas versiones ligeramente distintas del proceso, o peor aun, con versiones que no funcionan en todos los sistemas. Me tocó ver una empresa con quince programas que comercializaban, todos con su grales.bas, proc.bas, y func.bas… pero a veces completamente diferentes entre un proyecto y otro.

Otro problema que podemos tener es lo engorroso que resulta reutilizar un archivo bas en diferentes proyectos, si usamos Source Safe o si otros programadores tienen acceso a el. Una de las escenas mas hilarantes y deprimentes al mismo tiempo que me tocó ver, fue un pleito entre dos programadores que por orden de su jefe inmediato estaban haciendo un sistema entre los dos, pero cuando uno modificaba el codigo, el del otro programador ya no funcionaba. Todos conocemos casos así, no ? Sin embargo, un control o librería o Unit compilada, o el equivalente en cada lenguaje, puede crear una gran uniformidad de código. Desde el punto de vista de los datos, el objetivo que se tiene es tener una sola tabla de usuarios que usen todos los sistemas de la empresa, y no que cada programador o programa tenga su propia tabla de usuarios.

Sin embargo, en lo que reunimos la cantidad adecuada de rutinas, Y LAS PROBAMOS, los modulos son una alternativa viable, que mas adelante podremos convertir a clases y controles, conservando las ventajas, ganando otras, pasando a una sola desventaja.

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»