Professional Documents
Culture Documents
CONTROLES
Índice de contenido
INTRODUCCIÓN................................................................................................................................2
NOMBRES DE OBJETOS..................................................................................................................3
NOMBRES DE CAMPOS...................................................................................................................4
NOMBRES DE CONTROLES............................................................................................................6
PARA FINALIZAR ESTE ARTÍCULO...............................................................................................7
1
Visítame en http://bit.ly/NckAccess
INTRODUCCIÓN
Este artículo nace debido a que, en estos años de ver bases
y bases de usuarios, he podido comprobar que la utilización
de nombres en objetos, campos y controles es algo que
“usuarios inexpertos” descuidan. Descuidan por
desconocimiento, básicamente. Es decir, que ese
“descuidan” no lo digo con ninguna implicación negativa.
Un usuario sin conocimientos de Access decide hacer una inmersión en esta aplicación y crea
una base de datos simple. “La base de datos tiene que ser lo más clara posible”, piensa (y con
razón). Y es cuando crea unas tablas así:
Y, por extensión, la cosa funciona perfecta y crea los demás objetos de Access siguiendo la
misma mecánica:
En la primera tabla, por ejemplo, crea, entre otros, los siguientes campos
Y sobre esta tabla crea un formulario llamado FORMULARIO CON INFORMACIÓN DE CLIENTES,
donde le aparecen los anteriores campos, y, además, descubre los controles y empieza a
añadir cuadros combinados, cuadros de lista, botones de comando...
La base de datos funciona a la perfección., con lo que las necesidades están perfectamente
cubiertas.
Pasan unos meses (por ser optimista) y nuestro usuario aprende algunas funciones de Access,
aprende algunos rudimentos de VBA y, por seguir siendo optimista, aprende algo de SQL.
¡Fantástico!
2
Visítame en http://bit.ly/NckAccess
NOMBRES DE OBJETOS
Los nombres de objetos deberían ser nombres cortos y lo
más descriptivos posible. No habría que utilizar acentos en
dichos nombres (insisto, por última vez, en que todo lo que
diré son recomendaciones).
T: Tabla
C: Consulta
F: Formulario
R: Informe
TClientesAlta
De esta manera, si yo os digo que he escrito RInventario no necesito deciros que me estoy
refiriendo a un informe.
Hay otros sistemas, como anteponer los siguientes prefijos para designar los objetos:
tbl: Tabla
qry: Consulta
frm: Formulario
rpt: Informe
Volviendo a nuestro estimado usuario de Access, supongamos que quiere crear un código VBA
para manipular un subformulario en un formulario. Entonces debería escribir:
Y si lo anterior se repite muchas veces en el código pues... para “tirarse de los pelos”.
Si yo escribo lo siguiente:
Forms!FCli.subFrmActCli.Form.cboAct.visible=False
Otro problema que podría aparecer sería cuando, al ejecutar el código, nos salta un error
diciendo que no se encuentra el subformulario. ¡Pero si está ahí! ¡Lo estoy viendo! Y después
de un buen rato de mirar y mirar nos percatamos que el nombre real del subformulario es
[SUBFORMULARIO CON INFORMACION DE ACTIVIDADES DE CLIENTES]. ¿No es el mismo?
Pues no, porque escribimos INFORMACION sin acento gráfico (¡anda, se nos olvidó ese
acento!).
Si “sabemos” que a los nombres de objetos NUNCA les ponemos acentos, ese problemilla que
nos ha consumido diez minutos (por ser de nuevo optimista) de búsqueda del error... “¡plof:
3
Visítame en http://bit.ly/NckAccess
desapareció!”
Pues la verdad es que sí. Pero eso tiene una solución muy
sencilla: si sacamos las propiedades del formulario y nos
vamos a la pestaña Formato, a la propiedad “Título”, ahí
podemos escribir el nombre que queramos. Una vez escrito,
y cuando abramos nuestro formulario, veremos que su
título es el que hemos indicado en esa propiedad.
NOMBRES DE CAMPOS
Lo explicado para los nombres de objetos en el punto anterior, en cuanto a la extensión de los
mismos, es perfectamente aplicable a los nombres de campos.
Imaginaos que nuestro querido usuario aprende a utilizar una SQL de inserción de datos. Para
programar la ejecución de una sentencia SQL de este tipo debería escribir:
miSql=”INSERT INTO [TABLA CON INFORMACIÓN CLIENTES] ([Nombre del cliente], [Domicilio
del cliente], [Número de DNI del cliente]) VALUES (‘Pepito Pérez’, ‘C/ de la Zarzamora, 23’,
“123456789Z’)”
Si se hubieran escrito los nombres reducidos la SQL podría haber quedado así:
miSql=”INSERT INTO TInfCli (NomCli, DirCli, IdCli) VALUES (‘Pepito Pérez’, ‘C/ de la
Zarzamora, 23’, “123456789Z’)”
Ventajas:
En definitiva, ponemos los nombres de campos reducidos y sin espacio entre palabras
Algunas veces nos podemos encontrar con tablas diferentes que utilizan nombres de campos
que son muy parecidos. Lógicamente, podríamos escribir:
IdCli
en todas esas tablas para el campo que recoja el identificador del cliente. Ahora bien, eso
podría causar confusión tanto en el código VBA (y SQL) como, por ejemplo, si necesitamos
fijar el campo de relación entre un formulario principal y un subformulario.
La solución a este problema puede pasar por añadir algún tipo de identificador relacionado con
la tabla. Por ejemplo, si yo escribo como nombres de campos:
IdCliNac
IdCliExt
4
Visítame en http://bit.ly/NckAccess
no os costaría nada en absoluto identificar a qué tabla pertenecen si yo os digo que mis tablas
se llaman:
TCliNacionales
TCliExtranjeros
A continuación vuelve a escribir un código VBA y... ¡sorpresa! Saltan errores por todas partes.
¿Qué es lo que está pasando?
Pues que está utilizando caracteres reservados de VBA en los nombres de campos. Y el código,
al intentar leer los nombres de campos, interpreta el tanto por ciento (%) y el ampersand (&)
como partes de código y no como nombre de campo.
Moraleja: no podemos utilizar caracteres reservados en los nombres de campos. ¿Y cuáles son
esos caracteres reservados? Pues son los siguientes:
Nota: aprovecho la ocasión para comentaros, como curiosidad, que si en alguna ocasión, con
vuestro código VBA, tenéis problemas con algún carácter en los valores de los campos (ojo, en
los valores de los campos, no en los nombres), podéis solucionar ese problema utilizando
variables temporales. Os recomiendo este excelente artículo de Chea aquí o, si os lo queréis
bajar en pdf, aquí.
De nuevo nuestro usuario nos dirá ahora: “Pero si yo hago un formulario basado en una tabla
los nombres de los campos quedan muy “feos”. Efectivamente, un nombre de campo llamado
“PorcVtasCli” queda muy poco elegante de cara a un usuario de la base de datos. Pero,
¡tranquilos! No hace falta “matarse” cambiando etiquetas de campos.
¿Por qué? Porque cuando estamos creando el campo en la tabla, en la parte inferior donde
5
Visítame en http://bit.ly/NckAccess
están las propiedades del campo, tenemos una propiedad llamada “Título”.
NOMBRES DE CONTROLES
Finalmente, todo lo dicho en los puntos anteriores es de
perfecta aplicación aquí. Si insertamos un cuadro
combinado en un formulario podemos observar que Access
nos escribe como nombre predeterminado “Cuadro
CombinadoXX”, donde XX es un número.
Imaginaos que nuestro usuario tiene un código en un módulo asociado a un formulario así:
…
Private Sub Cuadro_Combinado23_Click()
‘Código
End Sub
Private Sub Cuadro_Combinado37_Click()
‘Código
End Sub
Tendríamos que irnos al formulario en vista diseño, localizar cuál es el cuadro combinado 37, y
arreglarlo. Os aseguro que como tengamos muchos errores de código eso es muy “time
consuming”.
Existe una nomenclatura para los controles. Os pongo a continuación la correspondiente a los
controles más comunes:
6
Visítame en http://bit.ly/NckAccess
Nombre control Prefijo
Cuadro de texto txt
Etiqueta lbl
Cuadro combinado cbo
Cuadro de lista lst
Casilla de verificación chk
Botón de opción opt
Marco de opciones mrc
Botón de comando cmd
Objeto OLE ole
Es decir, que si yo creo un cuadro combinado para recoger información sobre el campo [%
Desviación Aplicado] lo que haría sería:
Yo no utilizo esta letra en ninguna parte de Access. “¿Por qué?”, me preguntaréis. Pues
básicamente por dos motivos:
• Primero, porque si, por los motivos que sean, utilizamos un teclado no español vamos a
encontrarnos con que no tenemos esa letra.
• Segundo, porque si pedimos ayuda a algún amigo no español (lo que implica, en el
fondo, que no va a tener un teclado español) se va a “tirar de los pelos” cuando tenga
que “lidiar” con esa “letrita”... je, je...
De una manera u otra, y utilicéis el sistema que utilicéis, lo que debemos tener en cuenta,
desde mi humilde punto de vista, es que todo resulte lo más cómodo posible para nosotros
como administradores-programadores de la base de datos.
7
Visítame en http://bit.ly/NckAccess
Un saludo, y...
¡suerte!
8
Visítame en http://bit.ly/NckAccess