1.-
Bucles For
Me imagino que sabes hacer un bucle For. Lo que voy a contarte es como hacer que funcione más rápido.
|
Listado 1 (correcto, pero...)
' Las variables x, y, b serán del tipo por defecto (Variant)
Dim x, y, b, a$
a$="Hola Mundo"
For x=1 To 10
b = Len(a$)
For y = 1 To b
If Mid$(a$, y, 1) = Chr$(32) Then
GoTo OtraLinea
End If
Next y
OtraLinea:
Next x
Listado 2 (pues, eso...)
Dim x As Integer, y As Integer, b As Integer, a$
a$="Hola Mundo"
b = Len(a$)
For x=1 To 10
For y = 1 To b
If Mid$(a$, y, 1) = Chr$(32) Then
Exit For
End If
Next
Next
2.-
Usa siempre Option Explicit
Acostúmbrate a indicar siempre que
sea necesario declarar las variables.
Esta opción era una de las pocas cosas que me gustaban de C o
Pascal, ya que si no te acostumbras a declarar las variables, al
final acabas creando muchas más de las que necesitas.
Antes, (léase Qbasic, GWBASIC, etc.), tenía excusa. Ahora no!
Ya que puedes obligarte a declarar las variables, si indicas al
inicio del código: Option Explicit
Visual Basic puede hacerlo por ti, si se lo indicas en las
opciones del proyecto...
Menú Tools, solapa Environment, opción: Require Variable
Declaration
La ventaja: que si te equivocas al
escribir una variable, ¿a quién no le ha ocurrido?, VB te
indicará que no existe.
La desventaja: Que tienes que declarar todas las variables con
Dim, etc.
Ya sabes que si no declaras una variable, y por supuesto no
tienes la orden Option Explicit, Visual Basic le asigna por
defecto el tipo Variant y la crea si no existe. Con los arrays,
crea los valores de 0 a 10.
Por tanto puede que incluso estés desperdiciando memoria:
- Variant ocupa más espacio de memoria que cualquier otro tipo
- Puede que sólo necesites un array de 5 elementos, el resto que no necesitas, está ocupando memoria que puede ser necesaria para otras cosas: velocidad, más variables, etc.
3.-
Hacer comparaciones sin importar que sean mayúsculas o
minúsculas
Es muy fácil creer, sobre todo
para el no iniciado, que "Hola" es lo mismo que
"HOLA"
Para VB, o cualquier otro lenguaje, no es así. Estos trabajan
comparando carácter por carácter, y la A (a mayúsculas,
código ASCII 65), no es igual a la a (a minúscula, código
ASCII 97)
Si en a$ esperamos una entrada que sea igual a "Clave",
al hacer esta comparación, puede que pienses que estás
comprobándolo correctamente:
If a$ = "Clave" Then...
Pero el usuario, puede haber escrito "clave" o
"CLAVE", (hay mucha gente que todo lo escribe en
mayúsculas...), y la condición no se cumple.
Para "arreglarlo", podemos hacerlo de la siguiente
forma:
If Ucase$(a$) = "CLAVE" Then... o
If LCase$(a$) = "clave" Then...
Pero hay otra forma, con la que no tenemos que preocuparnos de
cómo se introduzcan los datos, cualquiera de las formas que
usemos para comprobarlo, dará un resultado TRUE en la
comparación...
¿Cómo?
Indicando OPTION COMPARE TEXT en el inicio del módulo en el que
hagamos la comparación.
OJO, sólo a nivel de módulo y en el módulo que se
especifique.
De esta forma, el usuario puede escribir "CLAVE" y esta
comparación se cumplirá:
If a$ = "Clave" Then...
4.-
Evita que al cambiar un ListBox entre en un bucle sin fin.
Para hacer esto, yo uso variables
estáticas mientras cambio un ComboBox o un ListBox...
Ya sabes que las variables estáticas conservan el valor entre
cada llamada.
A diferencia de las locales-dinámicas, que se generan cada vez
que entras en un Sub.
También puedes usar una variable a nivel de módulo, en lugar de
una estática.
Ya que la estática es visible sólo por ese Sub, mientras que la
variable a nivel de módulo, es visible por todo el módulo, o
por toda la aplicación, si está declarada como Pública o
Global.
Sub Combo1_Change()
Static YaEstoy as Boolean
If YaEstoy Then Exit Sub
YaEstoy = True
'El código...
YaEstoy = False
End Sub
5.-
Sobre los argumentos con ByVal y ByRef: Argumentos por Valor o
por Referencia (15/Feb)
Cuando VB pasa una variable a un
procedimiento, lo hace por referencia, es decir, le dá al
procedimiento la variable, de modo que cualquier cambio que se
haga en dicha variable, se reflejará en el contenido de la
misma.
¿Lógico? Se supone, ya que estamos acostumbrados a que así
sea, (me refiero a los programadores de Basic). Si queremos pasar
sólo el valor de una variable, debemos ponerla entre
paréntesis, de esta forma cualquier cambio que el procedimiento
realice en la variable, no será "actualizado" al
contenido de la misma... Esta bien, veamos unos ejemplos...
Tenemos un sub que recibe dos variables y le suma a la primera el
valor de la segunda:
Sub Sumar (A As Integer, B As Integer)
A = A + B
End Sub
Veamos que ocurre con esto del valor y la referencia:
'Parámetros por referencia M = 5 N = 3 Sumar M, N Print M 'Imprimirá 8, 5+3 'Parámetros por valor M = 5 N = 3 Sumar (M), N Print M 'Imprimirá 5, ya que no se cambia el valor
En el segundo ejemplo, la llamada
al procedimiento, podríamos haberlo puesto también de esta
forma:
Sumar ByVal M, N
El valor de la variable M, al pasarse por valor, no se modifica
en el suprograma Sumar, ya que lo que recibe este Sub es una
copia con el valor de la variable, no una referencia a
la dirección de memoria en la que la variable almacena el valor.
Todo esto viene a cuento de que en
ocasiones, necesitamos manejar una varibale en un procedimiento,
pero no nos interesa que se modifique "accidentalmente"
el valor. Este no sería el caso del Sub Sumar, ya que la
intención es modificar el valor del primer parámetro. Veamos
otro ejemplo, pero esta vez con cadenas de caracteres. (la aclaración de caracteres
es para el que aún no se ha enterado que normalmente en basic
cuando uno se refiere a cadenas, se hace referencia a las cadenas
de caracteres, de nada.)
Esta función, que de paso puede sernos de utilidad, recibe dos
cadenas, y devolverá el resultado de "extraer" de la
primera, el contenido de la segunda; en caso de que la segunda no
esté dentro de la primera, se devuelve la primera completa.
Por ejemplo:
Extrae("Hola mundo","mundo") devolvería
"Hola " y
Extrae("Hola mundo","gente") devolvería
"Hola mundo"
Veamos la declaración de esta función
' Listado 1
Public Function Extrae( Cadena As String, Parte As String) As String
Dim i As Integer
i = Instr(Cadena, Parte)
If i Then
Extrae = Left$(Cadena, i-1) & Mid$(Cadena, i + Len(Parte))
Else
Extrae = Cadena
End If
End Function
Tal como se manejan los datos en esta declaración, ni Cadena ni Parte se modifican. Pero podríamos tener el código "mal" definido y por "accidente" cambiar estos valores. Vemoslo con una modificación de la función, para que el valor devuelto no tenga espacios delante ni detrás:
' Listado 2
Public Function Extrae( Cadena As String, Parte As String) As String
Dim i As Integer
Cadena = Trim$(Cadena)
i = Instr(Cadena, Parte)
If i Then
Cadena = Trim$(Left(Cadena, i-1)) & Trim$(Mid$(Cadena, i+Len(Parte)))
End If
Extrae = Cadena
End Function
Ahora tanto Cadena, como Extrae
devolverían lo mismo. Pero puede que nos interese que Cadena
siga teniendo el valor original. Esto podemos solventarlo de dos
formas:
La primera, usando una variable temporal:
' Listado 3
Public Function Extrae( Cadena As String, Parte As String) As String
Dim i As Integer
Dim sTmp As String
sTmp = Trim$(Cadena)
i = Instr(sTmp, Parte)
If i Then
sTmp = Trim$(Left(sTmp, i-1)) & Trim$(Mid$(sTmp, i+Len(Parte)))
End If
Extrae = sTmp
End Function
La segunda, cambiado la
definición del parámetro Cadena para que sea por valor: en el
listado 2, cambiar la definición de la función para que esté
de esta forma:
Public Function Extrae( ByVal Cadena As String, Parte As String)
As String
De esta forma, no se reflejará ningún cambio en Cadena y no
tendremos que usar otra variable, para hacer el trabajo.
Resumiendo:
ByRef (por Referencia) es la forma por defecto y se pasa la
variable, o mejor dicho: se pasa la dirección en donde se
almacenan los datos de esa variable, después verás a que viene
esta aclaración.
ByVal pasa sólo el valor.
El siguiente apartado, te muestra las precauciones que debes tener con lo que se ha comentado, cuando se pasan valores a las API de Windows.
6.-
Cuidado con las cadenas pasadas al API de Windows con ByVal (15/Feb)
Normalmente las llamadas al API,
se hacen por valor, que es la forma que tiene el lenguaje C de
hacerlo.
Según lo expuesto en el apartado anterior, si se pasan variables por valor, estamos pasando
el valor de la variable y por tanto no se modificará su
contenido: PUES NO... Bueno, no cuando al API de Windows se refiere y si se trata
de cadenas.
En el caso de las cadenas pasadas al API con ByVal, se le está
pasando la dirección que apunta a los datos, (puntero o referencia a la
variable, según los señores de C ), por tanto la función podrá
"libremente" modificar el contenido de la
"susodicha" cadena.
Por tanto: precaución. Y para ser precavidos, pues eso: mejor
prevenir que curar.
Cuando pasemos cadenas al API de Windows, u otro API cualquiera
que use funciones en formato del lenguaje C, debemos asegurarnos
que las cadenas son suficientemente largas, para que almacene el
valor que deba almacenar.
La precaución: no ser "roñosos" a la hora de declarar
la variable.
Por ejemplo, si queremos usar una función que devuelve una
cadena, como sería el caso de GetWindowsDirectory, que devuelve
el directorio de Windows:
Declare Function GetWindowsDirectory Lib "Kernel32" Alias "GetWindowsDirectoryA" _ (ByVal lpBuffer As String, ByVal nSize As Long) As Long Dim WinDir As String Dim Cadena As String Dim ret As Long Cadena = String$(300, Chr$(0)) ret = GetWindowsDirectory(Cadena, Len(Cadena)) WinDir = Left$(Cadena, ret) 'Esta sería la forma "lógica" de obtener el valor 'Pero podemos "rizar el rizo" y hacerlo de esta otra: WinDir = Left$(Cadena, Instr(Cadena, Chr$(0)) - 1)
Fijate en que he puesto dos formas
de asignar a WinDir el directorio de Windows.
La primera es la que se debería hacer, ya que el valor devuelto
por la función GetWindowsDirectory es la longitud de la cadena
resultante.
Mientras que la segunda es una forma genérica de obtener las
cadenas cuando es una función escrita en C la que la devuelve. Y
es por la razón de que las cadenas en C, normalmente, siguen el
formato ASCIIZ, es decir una cadena acabada en el carácter de
código ASCII 0 (cero)
Lo que quiero decir con todo este
rollo, es que debemos ser generosos con la longitud de las
cadenas pasadas a funciones del API, si sabemos que son
directorios o archivos los valores que van a devolver, con una
longitud de 260, sería más que suficiente, ya que este valor es
el máximo soportado por los nombres largo. Este valor, está
definido en la constante MAX_PATH del SDK del API de Windows.
Por cierto en el fichero Win32API.TXT está mal, ya que indica
que son 32 caracteres, cualdo deberían ser 260.
7.-
Efecto ToolTip para Visual Basic 2.0 y superiores (22/Feb)
Este programa es para hacer el
efecto ToolTip.
Adjunto un listado de ejemplo, válido para todos los VB a partir
de la versión 2 incluida.
Si quieres echarle un vistazo al listado de la rutina que se encarga de hacer el efecto, pulsa aquí. Está en formato TXT para que puedas verlo directamente con el browser.
Listado de ejemplo en
formato zip (tooltip.zip 3.27 KB)
8.-
Comparaciones más rápidas con IF...THEN (5/Mar)
Este es un truco
"antiguo", pero que aún sirve. Lo he sacado de una
revista que tenía de mis tiempos del VIC-20.
El mirar la revista ha sido un poco de añoranza, ya que al
comunicarme Álvaro Ibañez de que me había incluido en los
recomendados de iWorld, comentó que "Es
bueno encontrar gente que *también* conoció los tiempos del
Vic-20 & Co... :-)"
Y me puse a hojear las
revistas que tenía del Commodore World, que por cierto las tengo
todas, soy un "forofo" de las colecciones de revistas
que me interesan...
Bueno, vamos al truco en cuestión:
Esto es para cuando se quieren hacer "múltiples"
comparaciones usando el AND, por ejemplo:
If A=2 AND B=3 Then ...
Se puede sustituir por esto otro:
If A=2 Then If B=3 Then ...
O si lo hacemos estructurado:
If A=2 Then
If B=3 Then
'...
End If
End If
Como verás, haciendo la
comparación con IF en bloques, se entiende mejor el porqué es
más rápido de la segunda forma.
Sólo se pasa al segundo IF si el primero se cumple, lo mismo que
ocurriría con el AND.
9.-
Las declaraciones del API y Tipos definidos en un Form o módulo
de Clase (24/Mar)
Cuando declaras una función del
API o de una DLL externa, se suele hacer de la siguiente forma:
Declare Nombre_Funcion...
Si pretendes usarla de forma local en un Form o un módulo de
Clase, debes ponerle delante Private y así no te dará error.
Private Declare Nombre_Funcion...
Lo mísmo ocurre con los tipos definidos. Antes (VB3 y
anteriores), sólo se permitía en los módulos BAS, pero ahora
se pueden declarar en los Form y CLS, pero si son privados. Por
tanto debes hacerlo con Private delante:
Private Type El_tipo_que_sea...
Por supuesto puedes usar también Private en un módulo BAS, pero
sólo estarán visibles dentro de ese módulo.
10.-
La "visibilidad" de las variables (24/Mar)
Ya que he comentado lo de las declaraciones en el "consejo" anterior, voy a aclarar un poco de que va eso de la visibilidad de las variables. Y viene al caso porque a más de uno le ha pasado que "se encuentra" atascado porque le da problemas el programilla con cosas "raras".
Veamos las posibilidades que podemos tener al declarar las variables:
| Globales: | Para
usarlas en todo el proyecto. Cuando queramos que una variable sea "visible" a todo el proyecto en el que estamos trabajando, (es decir que podamos usar esa variable en cualquier sitio), debemos declararla como Pública o Global en las declaraciones generales de un módulo BAS. |
| Globales (Propiedades) |
Para
usarlas en todo el proyecto, pero poniendo el nombre del
Form en el que se han declarado delante de la variable,
si queremos usarla fuera del propio form. A estas variables se las considera
Propiedades del Formulario. |
| Nivel de Módulo: | Para
usarlas sólo en un módulo o form determinado. Las variables declaradas en la parte de las declaraciones de un módulo, (BAS, FRM o CLS) con el atributo de Private o simplemente con DIM, se consideran locales al módulo y sólo serán visibles dentro de ese módulo. |
| Nivel de Procedimiento: | Para
usarlas sólo en un procedimiento. Las que se declaren dentro de un procedimiento (SUB, FUNCTION o PROPERTY) sólo serán visibles dentro de ese procedimiento. |
Hay que tener en cuenta que cuando se declara una variable en un nivel inferior, esta declaración "prevalece" sobre cualquier otra, de forma que usará la que tenga más cercana a donde se usa, al menos así ocurre con los procedimientos, en caso de variables a nivel de módulo con respecto a las globales, no lo he probado...
Veamos un ejemplo:
Tenemos un módulo BAS con esta declaración:
Option Explicit Global sVar1 As String
En el Form_Load:
sVar1= "en Form_Load" 'Mostramos el contenido de sVar1 MsgBox "El contenido de sVar1 es: " & sVar1
En un procedimiento tenemos:
Private Sub Form_Click()
Dim sVar1 As String
sVar1 = "en Procedimiento"
'Mostramos el contenido de sVar1
MsgBox "El contenido de sVar1 es: " & sVar1
End Sub
Bien prueba este ejemplo y verás lo que ocurre. Para comprobarlo, haz CLICK en el form.
11.-
El Tipo de las variables por defecto (24/Mar)
En los tiempos del GWBASIC y otros
Basics, antes del Visual Basic versión 2.0, las variables que no
se definían de un tipo en especial, eran variables tipo Single.
A partir de la versión 2.0 de VB se introdujo el tipo Variant y
de esta forma si la variable no se declara de un tipo en
especial, pues VB entiende que son del tipo Variant. En aquellos
tiempos (los del Basic normal), era una costumbre más o menos
extendida, al menos para los que nos gustaba "ahorrar"
memoria y ganar en velocidad, poner al principio del módulo la
siguiente instrucción: Defint A-Z, con ella declarabamos todas
las variables sin un tipo específico como variables INTEGER.
Pues hoy he recibido un mail de Harvey Triana para que lo recomendara a los "novatos" y
así lo hago.
Si sueles usar, por regla general, variables de tipo entero,
acostúmbrate a incluir al principio de cada módulo (Frm, Bas o
Cls) las siguientes declaraciones:
Option Explicit
Defint A-Z
De esta forma te obligará a declarar todas las variables (Option Explicit) y a las que no le des un tipo en particular, las tomará por Integer (Defint A-Z). ¡OJO CON ESTO! si estás acostumbrado a que las variables por defecto sean Variant, sobre todo en las que declares como opcionales, que siempre deben ser Variant, al menos en la versión 4, ya que VB5 permite especificar el tipo.
12.-
Listados de ejemplo para crear un ToolBar, ToolTips y efectos 3D
para VB3 (8/Abr)
Estos listados son un ejemplo para
crear un ToolBar, incluye también la rutina para hacer el efecto
de los ToolTips y hacer el efecto 3D en cualquier control.
Estos listados son válidos para VB3 (y creo que VB2)
Listados de ejemplo para crear el ToolBar, los ToolTips y ejemplo para efectos 3D (tb_vb3.zip 5.67 KB)
Aclaración: El hecho de que esté aquí es porque en su día puse en este apartado lo de los ToolTips.
13.-
Evitar que una aplicación se cargue más de una vez (VB2 y
posteriores) (6/Jul)
Rectificación (11/Jul): Por error u omisión... vamos, por despiste, indicaba que el PrevInstance no servía para VB3 y si que funciona; es con el VB2 (¿y anterior?) con el que hay que usar el API para impedir que una aplicación se cargue más de una vez. Gracias a Arturo Tena por la aclaración en las NEWS, pero es que algunas veces no prueba uno todo lo que dice...
Algunas veces nos puede interesar que nuestra aplicación sólo se ejecute una vez, pues bien, con el VB3 y superiores eso es fácil, ya que existe una instrucción que ahora veremos, pero en VB2, la cosa no es tan sencilla, aquí te muestro cómo hacerlo para todas las versiones.
Para VB3 y posteriores usa la propiedad PrevInstance del objeto App. Sólo tienes que poner esto en el Form_Load:
If App.PrevInstance Then
End
End If
En el caso de VB2, podemos usar
unas funciones del API de Windows: GetModuleHandle y
GetModuleUsage.
Donde dice "nombre.exe" deberás usar el nombre que
tenga la aplicación.
Un aviso: Esto sólo debes usarlo en Win3.x aunque en Win95
funcione... debes usarlo con prudencia...
'Poner estas declaraciones en un módulo BAS
Declare Function GetModuleHandle Lib "Kernel" (ByVal lpModuleName As String) As Integer
Declare Function GetModuleUsage Lib "Kernel" (ByVal hModule As Integer) As Integer
'En el Form de inicio, poner esto en el Form_Load:
Private Sub Form_Load()
Dim hModule As Integer
Dim numCopias As Integer
hModule = GetModuleHandle("nombre.exe")
numCopias = GetModuleUsage(hModule)
If numCopias > 1 Then
End
End If
'...
End Sub
14.-
Evitar los eventos en cascada... ¿te suena OUT OF STACK SPACE?
(9/Jul)
Sé que no es cosa nueva, incluso el 4º truco de esta sección trata de lo mismo, pero al parecer alguno no captasteis la intención de la solución allí presentada. Aprovecho una de las consultas hechas para poner la respuesta, que de camino sirve un poco de explicación. Allá va... Y si aún no te enteras... pregunta, pregunta.
> una: que es el error "cascada de eventos" Esto es un error que nos suele pasar a todos cuando empezamos con el VB, ya que el Windows está enfocado en los eventos, es decir que si pulsas sobre un TextBox con el ratón, se producen una serie de eventos, si pulsas una tecla en un control se producen otra serie de eventos... total que hasta si te rascas la cabeza se produce un evento... y si mientras estás escribiendo en un TextBox haces algo que obligue a que se produzca ese evento de nuevo... produces una cascada de eventos... Por ejemplo prueba esto: Private Sub Text1_Change() Dim sTmp As String sTmp = Text1.Text Text1.Text= sTmp & "a" sTmp ="" End Sub Esto te producirá un error de que no hay espacio en la pila o algo similar, ya que cada vez que se produce el "evento" Change, haces que cambie el contenido del Text, por lo que vuelve a producirse un nuevo evento change, sin que termine el anterior... y el VB se pone "malo" Solución: evitar este tipo de cosas... (elemental) ¿Cómo? con trucos y variables estáticas, por ejemplo: Private Sub Text1_Change() Dim sTmp As String Static YaEstoy As Integer If YaEstoy Then Exit Sub YaEstoy = TRUE sTmp = Text1.Text Text1.Text= sTmp & "a" sTmp ="" YaEstoy = FALSE End Sub Al crear una variable estática mantiene el valor entre llamadas. La primera vez que entra en el evento, al valer CERO (FALSE), pasa por alto el IF YAESTOY THEN... Por tanto se pasa al resto del código y se asigna un valor TRUE Ahora al asignar el valor al Text1, se produce el evento change, pero cuando entra por segunda vez, se encuentra con que la condición es cierta, por tanto se sale sin continuar... Una vez que termina el primer evento, el valor YaEstoy vuelve a ponerse a CERO para que en el siguiente se vuelva a procesar lo que haya que procesar...
Novato
= Al_que_empieza (24/Ene)
Que nadie se mosquee. No es por
faltar al respeto; pero el que se inicia, siempre es un novato;
aunque algunos que llevamos algunos años, puede que sepamos
menos, pero... así es la vida, los novatos son los que se
inician y los veteranos, aunque sepan igual o menos, son lo que
llevan más tiempo... 8-)
En fin, esta página va dedicada a aquellos que necesitan saberlo
todo desde el principio.
A ver si os ponéis pronto al día en la programación en VB.
¿Por qué te das por aludido Manolo? 8-))))
