Algunas joyas escondidas en Access 2010

Access Services

Estoy impresionado. He aprovechado la oferta de Access Hosting que el otro día anunciaba el Access Team Blog para abrir una cuenta “trial” de Access Services. He probado a crear y subir una aplicación web hecha con una plantilla de Access 2010 y, como era de esperar, ha funcionado a la perfección.

Las aplicaciones web funcionando en Sharepoint 2010 son la novedad estrella de Access 2010, sin embargo, lo que me ha impresionado ha sido algo mucho más simple: He subido una sencilla aplicación de escritorio y funciona de maravilla, a una velocidad equiparabla a la de cualquier aplicación web; naturalmente, no se ejecuta en Sharepoint, sino que lo usa de Back End, pero hace mucho más, pues no sólo aloja y sirve datos, sino que también guarda todos los demás objetos de la aplicación.

Navegando por el sitio creado en Sharepoint para nuestra aplicación, tenemos una opción para modificar la base de datos:

image

Pinchas en ella y, en pocos minutos, se ha descargado una copia de la aplicación perfectamente operativa que trabaja con los datos alojados en el sitio. La siguiente vez que pinches, sólo tardará un poco más de lo que tardarías en abrir la aplicación en el escritorio. Para conseguir esto, durante el proceso de subida a Access Services se han ido sincronizando no sólo tablas y consultas, sino todos los objetos; así, cuando realizamos una modificación en nuestra BD, en cualquier objeto, no sólo en los datos, el cambio se realiza también en el sitio Sharepoint, de manera que siempre está disponible desde la web la última versión. Una maravilla.

Como la opción para modificar la base de datos es un acceso directo, podemos copiarlo y usarlo directamente o, remitirlo a otros  usuarios, en vez de andar navegando por el sitio.

Esto me ha reconciliado con la proyección a la nube de Access 2010. Las listas vinculadas en Access 2007 son una opción interesante, pero bastante más limitada y lenta de lo que se prometía, para colmo, lo que tuviéramos hecho con listas vinculadas ya no nos vale ahora para los Access Services, de manera que no estaba muy seguro de que el premio mereciera el trabajo de aprender a manejar las macros, el formulario de navegación, etc.. Ahora, sólo por esta posibilidad de tener los datos en la web de manera fácil u operativa, ya merece la pena subirlos y, ya puestos….

Access 2010 viene con grandes novedades de las que, desde el inicio de la Vista Previa Técnica, el Access Team Blog nos viene poniendo al día. Eventos y macros de datos, campos calculados en tablas, aplicaciones en la web, formularios de navegación, control WebBrowser vinculado a datos… son serias innovaciones que cambiarán la forma de trabajar con Access y que parecen todas orientadas a las aplicaciones web. Había dejado para cuando estuviera con más ánimo el ir probando todo lo referente a esas novedades estrella,  pero, mientras, he ido descubriendo cosas más terrenales, mejoras sobre cosas que ya se venían usando, que o no se mencionan en los blogs, o lo hacen de pasada, pero que por sí solas ya justificarían una nueva versión. A esas pequeñas joyas voy a referirme ahora.

Formato condicional

Casi parece que no ha cambiado en nada, a simple vista, los asistentes parecen los mismos, pero uno se pone a meter hasta cuarenta y nueve formatos condicionales y no se queja, mientras que antes venía limitado a tres.

image

Si, además, nos fijamos bien en el asistente, vemos que tiene un desplegable, “Seleccionar tipo de regla” con una opción, comparar con otros registros.

image image

 

Seleccionamos entre distintas opciones, y el resultado es una barra proporcional a los distintos valores de nuestro formulario o informe, un estilo a lo que ya existía en Excel

image

No sólo funciona con informes y formularios continuos. También se pueden usar, y funciona correctamente, en formularios estándar

image

Texto enriquecido en subformularios

Aunque parece que lo corregirán en breve, en Access 2007 no era posible editar el texto enriquecido en los subformularios. Ahora sí, en cualquier lugar, incluso en subformulario continuos, aunque sean en vista Hoja de Datos.

image

SubInformes en formularios

Estamos tan acostumbrados a que no se puedan meter SubInformes en formularios que hasta cuesta pensar en la utilidad que pueden tener.

Por ejemplo, haciendo un refrito, en muy pocos minutos hemos convertido el  informe “Listín de teléfonos” en panel de navegación del formulario “Detalle de clientes” de la BD “NorthWind”.

image

Se me ocurre que navegar de manera semejante por un Diario o un Libro Mayor correctamente formateados en un subinforme, con sus Totales por asiento, Sumas Contínuas, etc., dentro de un formulario para editar los asientos, puede resultar muy vistoso, incluso muy útil, y realmente fácil de hacer.

Se trata de una “Vista Informe” por lo que faltan las opciones de impresión que tiene la “Vista Previa”, pero, a cambio, podemos disponer de eventos (Clic, doble-clic…) filtros, etc.. Nada cuesta poner un botón en el informe o en el Ribbon para que nos muestre una “vista previa”

En otros casos, como corresponde a un SubInforme, está vinculado al Formulario principal por las propiedades LinkChildFields y LinkMasterFields, de manera que, al cambiar de registro el formulario, el subinforme a la vista se filtra según estos campos.

También existe la posibilidad contraria, la de mostrar subformularios en informes. El subformulario no es editable por lo que no le veo ninguna ventaja sobre un subinforme en vista informe, salvo ahorrarse el trabajo de crearlo, pero seguro que, entre las muchísimas barrabasadas que se harán con esta posibilidad, alguien le encontrará un uso brillante.

Plantilla de ajuste de controles

Se trata de que los controles se ajustan a una plantilla o tabla, como en las hojas de estilo en el diseño web, en la que podemos añadir o quitar filas y columnas, cambiar alto y ancho de celdas, dividir éstas o combinar varias entre sí.

Access 2007 ya había aportado algo a la colocación de los controles, agrupándolos en formato tabular o apilado, que sigue siendo posible, pero, aunque era una forma muy rápida de poner cierto orden visual, no era una solución muy lograda, ya que todos los controles apilados en el mismo grupo, tenían el mismo ancho.

En Access 2010 cuando agrupamos controles, de forma apilada o tabular, podemos moverlos a un lado, encima o debajo, como si añadieramos filas y columnas a una tabla de word; de la misma manera, podemos combinar o dividir esas celdas y los controles que coloquemos se ajustarán a ellas. Es como si debajo de los controles hubiera una tabla o plantilla invisible. Verla es fácil utilizando otra de las novedades de Access 2010, las líneas de división también en formularios.

image image image imageimage

Botones con formas, colores y relieves

Los botones, incluidos los de los TabControls, pueden tener distintas formas colores y texturas. Como muestra, unos pocos:

image

 

El botón “Estilos rápidos” muestra una galería rápida, pero también podemos combinar “Cambiar forma”, “Relleno de forma”, “Contorno de forma” y “Efectos de forma” para conseguir un montón de posibilidades.

imageimage image image image image imageimage

     

Las formas y colores de los botones no quitan para que puedan seguir teniendo imágenes y pie de imagen, por lo que podemos conseguir unos botones resultados muy vistosos en los que, además, se sigue visualizando el efecto de apretar el botón:

image

Los botones con formas y colores se ven afectados por el “Tema” que hayamos elegido. Al cambiar de tema, cambia la galería de “Estilos rápidos” y, si ya lo hemos creado, también cambia la apariencia de nuestro botón.

image image

 

Si queremos cambiar la imagen de un viejo formulario Access 2007, de entrada puede que no tengamos habilitadas estas opciones. Se soluciona fácilmente cambiando la propiedad “Usar tema” del control.

Si nuestra aplicación es en formato mdb, no existe esta propiedad y, por tanto, tendremos que conformarnos con los botones tradicionales.

 

Generador de expresiones

Cambia la interface del generador de expresiones.

image

Es más completa y con grafía que diferencia los objetos, pero lo más novedoso es que aplica el “intellisense” en aquellas propiedades en que se puede usar el generador.

image 

 

Imágenes compartidas

Aunque ya en Access 2007 las imágenes se guardan en el tamaño del formato original, no deja de ser un desperdicio de espacio repetir la misma imagen, por ejemplo el logotipo de la empresa, en cada formulario o informe. Aunque había soluciones, ésta síque es sencilla de manejar.

image

Una vez que para una imagen en la propiedad “Tipo de imagen” hemos elegido “Compartidas”, queda guardada y a disposición de los demás objetos de la aplicación en la galería que se despliega al pulsar el botón “Insertar imagen”.

image 

Las imágenes compartidas se guardan como datos adjuntos en la tabla MSysResources, de manera que sólo ocupan espacio una sóla vez. Contiuará existiendo en nuestra BD, y ocupando ese espacio, mientras no la borremos de aquí. Si queremos cambiar el anagrama de nuestra empresa en todos los formularios e informes, basta con que lo cambiemos aquí.

 

Título en la barra de navegación

Un pequeño detalle, casi insignificante, pero que refleja cómo en Access 2010 nos encontramos con mejoras a cada paso. Con la propiedad “Título de navegación” podemos indicar qué queremos que ponga en la barra de navegación en vez de “Registro”. Sin pasarse, eh, que el espacio reservado para ello no aumente ;-)

 

imageimage

 

 

Publicado por Chea con 7 comment(s)
Archivado en:

Magia Potagia II: El desenlace

En el capítulo anterior habíamos usado ingredientes mágicos de Access 2007 para conseguir crear una serie de calendarios sin apenas usar código. Hoy se trata de licenciarnos como aprendices de brujo haciendo que la magia trabaje para nosotros resolviendo problemas de la vida real.

Necesitaba crear un subinforme que, para cada uno de los elementos del informe principal, me mostrara un conjunto de fechas representadas en tantos calendarios mensuales como fueran necesarios para mostrar todo el periodo entre la primera y la última. Más o menos, como en las imágenes.

 image     image

Evidentemente, ya lo he hecho y el caso real lleva tiempo funcionando correctamente. Hay una demo, la de las imágenes, que se puede descargar en Access siglo XXI.

La magia en la vida real tiene un problema: que no hay quien entienda cómo funciona. Lo mágico de estos calendarios es que apenas usan código, pero el código se puede leer, está estructurado, se autodocumenta; es como un plano de la aplicación. Sin código es muy difícil ver cómo está hecho algo, tanto que, para que el que quiera pueda adaptar mi ejemplo, he tenido que incluir un pequeño asistente.

No obstante, voy a intentar explicar cómo está construido, aunque me temo que será bastante pesado. Cuando empieces a aburrirte, salta directamente al último punto, al desenlace.

El punto de partida es una tabla con un campo de fecha y un campo ID numérico, en este caso de usuario, es decir, con un conjunto de fechas, que son las que queremos mostrar en calendario, para cada usuario.

image

El idEmpleado es númerico y si se muestran nombres en la imágen es porque uso un campo de búsqueda.

En el ejemplo del capítulo anterior utilizaba una tabla tipo Calendar, con campos StartDate y EndDate, y mediante una consulta, la convertía en un resultado parecido a éste. Sin embargo, aunque no lo decía, trabajar directamente con la consulta afectaba mucho al rendimiento y sería preferible volcar los resultados en una tabla temporal.

Obtener todas las fechas de cualquier año

El primero de los ingredientes mágicos , es una tabla Numeros, con un campo Num con número consecutivos. La mía tiene poco más de mil.

image

A partir de esta tabla, mediante una consulta construimos todas las fechas que se corresponden con las del calendario “de fondo”

SELECT [Numero]+DateSerial(nz(TempVars!jbAnyoInicial,Year(Date())),1,1)-1 AS Fecha, Format([Numero]+DateSerial(nz(TempVars!jbAnyoInicial,Year(Date())),1,1)-1,"dddd") AS Dsemana, (Month([Numero]+DateSerial(nz(TempVars!jbAnyoInicial,Year(Date())),1,1)-1)) AS Mes, (1+(([Numero]+DateSerial(nz(TempVars!jbAnyoInicial,Year(Date())),1,1)-1-2)\7)) AS Fila, Year([Numero]+DateSerial(nz(TempVars!jbAnyoInicial,Year(Date())),1,1)-1) AS Anyo
FROM Numeros
WHERE (((Year([Numero]+DateSerial(nz([TempVars]![jbAnyoInicial],Year(Date())),1,1)-1))=nz([TempVars]![jbAnyoInicial],Year(Date()))));

Mediante el procedimiento de sumar al campo Num una fecha inicial menos uno y hacer que sea menor o igual que una fecha final, podemos obtener cualquier rango de fechas que no supere el total de registros de nuestra tabla Numeros. Pero en el informe podemos superar este límite usando otro de los ingredientes mágicos de Access 2007, TempVars. Al utilizar una variable TempVars en el cálculo de la fecha inicial, podemos cambiar ésta sobre la marcha en el informe de manera que la consulta se vaya recalculando las veces que sea necesario. Ya nos pararemos en ello más adelante; de momento, guardamos esa consulta como jbFechasVirtuales y los resultados sería algo así:

image

 

Resaltar los festivos de cada empleado

Sobre ese “calendario de fondo” se trata de resaltar las fechas de nuestra tabla tblFechasEmpleados usando el tercer ingrediente mágico de A2007, el formato de texto enriquecido. Comparamos tabla y consulta y en las fechas coincidentes añadimos las etiquetas html necesarias para mostrar el resultado resaltado, en nuestro caso en rojo, tal como habíamos visto en el capítulo anterior.

Sin embargo, antes vamos a anticiparnos con un problema con el que nos toparíamos más adelante en el caso real. El objetivo es presentar los calendarios como subinformes, pero si construimos y formateamos como calendarios todo el conjunto de datos, al vincular por un campo ID informe y subinforme y, por tanto, filtrar los datos de éste, destrozamos el formato de calendario que hemos dado a todo el conjunto. En resumen, que debemos dar forma de calendario a cada subconjunto en vez de filtrar el conjunto de datos total y para ello la mejor solución que se me ha ocurrido es volver a usar TempVars de manera que, cambiando sobre la marcha la variable TempVars!jbID cada vez que cambie el ID del informe principal se recalcula la consulta en la que se basa el subinforme calendario filtrándose por ese ID.

Así, en vez de usar directamente la tabla tblFechasEmpleados, usaré la consulta que he llamado jbqFestivosVirtuales y que tiene el siguiente SQL.

SELECT tblFechasEmpleados.idEmpleado, tblFechasEmpleados.Fecha
FROM tblFechasEmpleados
WHERE (((tblFechasEmpleados.idEmpleado)=[TempVars]![jbID]));

Ahora ya podemos juntar las dos últimas consultas para resaltar con formato de texto enriquecido los festivos de los empleados.

SELECT jbqFechasVirtuales.*, IIf(Not IsNull([jbqFestivosFiltrados].Fecha),"<font color=red>" & Day(jbqFechasVirtuales.fecha) & " </font>",Day(jbqFechasVirtuales.fecha)) AS Expr1
FROM jbqFechasVirtuales LEFT JOIN jbqFestivosFiltrados ON jbqFechasVirtuales.Fecha = jbqFestivosFiltrados.Fecha
ORDER BY IIf(Not IsNull([jbqFestivosFiltrados].Fecha),"<font color=red>" & Day(jbqFechasVirtuales.fecha) & " </font>",Day(jbqFechasVirtuales.fecha));

Guardamos la consulta como jbFechasyFestivosVirtuales y el resultado es como en la imagen siguiente (hasta 365 días) donde destaca un campo que en ocasiones pone algo como <font color=red>10</font> con el que más adelante conseguirems que el número 10 se muestre en rojo.

image

Ya tenemos una secuencia con todas las fechas del año para un determinado usuario con los festivos formateados para que más adelante se muestren en rojo. Para que se parezca a un calendario falta ordenarlo en columnas por días de la semana.

Dar a los datos forma de calendario

Ya habíamos visto en el capítulo anterior que para ordenar en columnas por días de la semana una secuencia de fechas podemos usar una Consulta de Referencias Cruzadas que voy a llamar jbqCalendarioFormateado y que será el origen de datos del subinforme calendario:

TRANSFORM Min([jbqFechasyFestivosVirtuales].Expr1) AS MínDeExpr1
SELECT [jbqFechasyFestivosVirtuales].Mes, [jbqFechasyFestivosVirtuales].Anyo, [jbqFechasyFestivosVirtuales].Fila
FROM jbqFechasyFestivosVirtuales
GROUP BY [jbqFechasyFestivosVirtuales].Mes, [jbqFechasyFestivosVirtuales].Anyo, [jbqFechasyFestivosVirtuales].Fila
PIVOT [jbqFechasyFestivosVirtuales].Dsemana In ("lunes","martes","miércoles","jueves","viernes","sábado","domingo");

El resultado, algo parecido a esto:

image

El subinforme calendario

Es pequeñito, para que me quepan más calendarios en una hoja, que hay que ahorrar papel,

image

El Origen de Datos es la consulta jbaCalendarioFormateado y el truco principal es que los campos Lunes, Martes, Miércoles … están ocultos (en la imagen en amarillo) y sobre ellos se superponen sendos campos calculados dLunes, dMartes, dMiércoles… que tienen por origen el campo que está debajo. Al ser campos calculados, pueden tener formato de Texto enriquecido, que no es posible en campos de texto, de manera que el campo que antes habíamos construido con etiquetas html del estilo <font color=red>10</font>, ahora se mostrá como 10.

También están ocultos los campos Mes y Anyo, que nos van a servir para vincular con el subinforme MesesAnyos.

Este subinforme no tiene ni una sola línea de código.

El subinforme Meses-Año

El subinforme anterior muestra un solo calendario, pero necesitamos que nos muestre tantos calendarios como sean necesarios en el subinforme. Por eso lo incrustamos en otro subinforme Meses-Año que tiene todos los meses necesarios para mostrar las fechas de cada empleado.

image

El origen del subinforme es la consulta jbqMesesAnyos y tiene por objetivo obtener tantos registros identificados por mes y año como sean necesarios para mostrar todas las fechas de un empleado:

SELECT ((([Numero]-1)\12)) AS Fila, 1+([Numero]-1) Mod 12 AS numMes, MonthName([NumMes]) AS NombreMes, (([Numero]-1)\12)+Year(DMin("[Fecha]","jbqFestivosFiltrados")) AS Anyo, DateSerial(((([Numero]-1)\12))+Year(nz(DMin("[Fecha]","jbqFestivosFiltrados"))),1+([Numero]-1) Mod (12),1) AS Expr1, [TempVars]![jbID] AS jbID
FROM Numeros
WHERE (((DateSerial(((([Numero]-1)\12))+Year(nz(DMin("[Fecha]","jbqFestivosFiltrados"))),1+([Numero]-1) Mod (12),1)) Between nz(DMin("[Fecha]","jbqFestivosFiltrados"))-30 And nz(DMax("[Fecha]","jbqFestivosFiltrados")) And (DateSerial(((([Numero]-1)\12))+Year(nz(DMin("[Fecha]","jbqFestivosFiltrados"))),1+([Numero]-1) Mod (12),1))>0));

image

La consultita se las trae, pero, resumiendo, obtiene los meses y año del subconjunto de fechas de un empleado a partir de la tabla Numeros y usando como filtro las fechas mayor y menor de la consulta jbqFestivosFiltrados. Además, obtiene el campo jbID, por el que se vincula con el informe principal, de la Variable Temporal TempVars!jbID.

En la seccion detalle tenemos el subinforme jbSubRptCalendarioFormateado y, cada vez que se formatea esa sección, cambiamos mediante código la variable temporal TempVars!jbAnyoInicial que, como vimos se usaba en la primera consulta, jbFechasVirtuales, de manera que al cambiarse, esto sí que es magia, se se recalcula toda la consulta y se refresca el subinforme jbSubRptCalendarioFormateado.

Este es el todo código del subinforme:

Option Compare Database
Option Explicit

Private Sub Detalle_Format(Cancel As Integer, FormatCount As Integer)
TempVars!jbAnyoInicial = Me.Anyo.Value
Me.SubRptCalendario.Requery
End Sub

Private Sub Report_Close()
TempVars.Remove ("jbAnyoInicial")
End Sub


Private Sub Report_Open(Cancel As Integer)
TempVars!jbAnyoInicial = Year(DMin("Fecha", "jbqFestivosFiltrados"))
End Sub

El informe principal

En el informe principal incrustamos el subinforme jbSubRptMesesAnyo y necesitamos un campo ID por el que vincular con éste.

image

Es necesario que tengamos una agrupación por ese campo ID y que ese campo se encuentre en la sección encabezado de ese grupo.

¿Por qué? Por que es la única forma que he conseguido que me funcione el abracadabrante rizado del rizo:

Los campos por los que se vinculan informe y subinforme son respectivamente id y jbid.

image

En el evento Format de la sección EncabezadoDelGrupo0 le doy a la variable temporal TempVars!jbID el valor de ese campo ID y, como resulta que el campo jbID del subinforme lo toma de esa variable temporal, estoy asignando sobre la marcha y mediante código en el informe principal el valor del campo del subinforme por el que éste se vincula con el informe principal ¡Con dos c…!

Para más magia potagia, cambiar por código TempVars!jbID, como forma parte de la primera consulta, jbFechasVirtuales, hace que ésta se refresque y haga los cálculos sólo para el empleado del ID. Como también está en la consulta jbqFestivosFiltrados y del máximo y mínimo de ésta depende la consulta jbqMesesAnyo, no sólo se restringen los festivos a los del empleado, sino que se recalcula jbqMesesAnyo, que es precisamente el origen del subinforme.

Todo el código necesario es el siguiente:

Option Compare Database
Option Explicit

Private Sub EncabezadoDelGrupo0_Format(Cancel As Integer, FormatCount As Integer)
TempVars!jbID = Me.ID.Value
Me.subRptMesesAnyo.Requery
End Sub

Private Sub Report_Close()
TempVars.Remove ("jbID")
End Sub

Private Sub Report_Open(Cancel As Integer)
TempVars!jbID = DFirst("id", Me.RecordSource)
End Sub

El desenlace

Yo ya advertí que iba a ser aburrido. Resumiendo, usando TempVars y consultas basadas en una tabla Numeros, se pueden hacer cosas inimaginables de otra manera.

Es magia empaquetada. No es necesario entenderla toda ni seguir complicados rituales para usarla en una aplicación propia pues, de todos los objetos y consultas que utiliza sólo es necesario cambiar el informe principal y la consulta jbqFestivosFiltrados. En Access siglo XXI puedes descargarte la aplicación de ejemplo que, además, tiene un asistente elemental para modificar esa consulta y el código del informe principal.

¿De dónde he sacado yo estas cosas de mágia? Ni idea, supongo que andaré hechizado, aunque algo de inspiración se me habrá pegado de Ramón Poch o de Julián Sánchez, aficionados también a jugar con una tabla Numeros.

Por cierto Dominguín iba a las siete de la mañana… ¡A contarlo!

Access 2010- Hermenéutica sobre un volcado de pantalla

Ya tenemos, como un pastel en un escaparate, sin tocar, sin oler, sin probar, sólo ver, las primeras imágenes de Access 2010. Son una parte de un pqueño conjunto de volcados de pantalla sobre Office 2010 que podemos ver en Leaked: Office 2010 Technical Preview screenshots. Es poco lo que se muestra, pero lo imagino delicioso.

image

Sobre lo que vemos, unido a algunos comentarios que se han ido desgranando casi desde que salió 2007, podemos hacer un ejercicio de hermenéutica para interpretar qué nos puede traer de nuevo Access 2010, que, por si alguno no lo sabe ya, presentará su Technical Preview, sólo por invitación, junto con el resto del paquete de Office, en julio de este año.

Sabemos que VBA seguirá existiendo

Sabemos que funcionará con Windows XP SP3, Vista y Windows 7 y que tendrá versiones de 32 y 64 bits.

Sabemos que no formará parte de las Office Web Apps.

Desentrañemos ahora esos volcados de pantalla en busca de nuevos augurios, fijándonos primero en los que muestran distintos Ribbons:

- Cambia el botón de Office. A muchos no les gustaba por ostentoso; a mí sí. Ahora es más pequeño, discreto y deja de ser redondo, aparentando una pestaña más, aunque destacada (y más fea).

- El Tab Home apenas muestra diferencias respecto al actual

- En Create tenemos un nuevo grupo, Templates, y, dentro de él, el botón desplegable Aplication Parts. A cambio, ha desaparecido el botón Plantillas de tablas, que es de suponer que estará incluido en el primero. Por los comentarios de Access Team Blog y sus peticiones a los usuarios para que reportaran los formularios más usados, convenciones de nombre o ejemplos de expresiones, formularios e informes reusables, es de esperar que Access 2010 venga cargado de plantillas de todo tipo, incluido código al estilo del Administrador de fragmentos de código de Visual Studio

Algo que pasa desapercibido a primera vista es que el botón de Macro, que tiene el mismo icono de antes, ya no se llama Macro a secas, sino Client Macro ¿Significa este calificativo que va a haber también algo como un Server Macro? Después de observar las imágenes de los Ribbons siguientes, yo no lo descartaría.

- En External Data, en el grupo Import, nos encontramos con un botón Web Service. Ya lo conocíamos; era de lo poco que se había dejado ver de Office 14, también en Ars Technica. Yo apostaría por que está en relación con la Plataform de Servicios Windows Azure, y más en concreto con los SQL Services, aunque no habría que descartar otros. Quizás sólo sea que mi imaginación se deja llevar por mis deseos.

- Y la gran sorpresa para el final. Bajo el supertab Table Tools, en el Tab Modify Fields, aparece un Ribbon desconocido y sorprendente. Unos pocos botones, como los del grupo Formatting, son previsibles y, al parecer no hacen más que poner en el Ribbon accesos a funcionalidades que ya existían, pero otros son completamente novedosos

Un botón Calculate Field ¡En el diseño de tabla! y un grupo Table logic, con los botones Create Table Events, desplegable, y Manage Table Events, nos hablan de un nueva dimensión de Access que, si es lo que parece a muchos nos va a dejar con la boca abierta.

Ya no es cuestión de si un Evento de Tabla se parecerá a un Trigger, o a un Flujo de Trabajo, más fácil, o si será algo distinto y propio de Access, sino, más bien, cómo co…o (córcholis) puede producirse un evento de tabla en un ACCDB si es un simple archivo. Tenemos dos meses hasta la Technical Preview para jugar haciendo conjeturas; por ejemplo, que las tablas con eventos no puedan ser leídas por versiones anteriores del motor de Access (que sería el encargado de disparar los eventos) o, con mucha imaginación, que dispusierámos de un WSS local.

Los campos calculados en las tablas y los eventos de tablas recuerdan mucho a las listas de Sharepoint, y en nombre Sharepoint se repite y se repite cada vez que leemos algo de Office 2010; que si Groove ahora va a ser Sharepoint Workspace, que si las Office Web Apps estarán integradas en Sharepoint

¡Oh! ¡No lo había visto! Volviendo al primero de los volcados de pantalla de Access, el que está antes de los de los Ribbons y se corresponde con la ventana de apertura de Access, disimuladamente, en el primer apartado, Avalaible Template, junto al icono de Blank Database, tenemos el de Blank Web Database. Qué significa esto es pronto para decir, pero, si es lo que parece, promete ser la novedad más importante de Access 2010. Seguro que también tiene que ver con Sharepoint.

 

Publicado por Chea con 3 comment(s)
Archivado en:

Filtros en Access 2007

Access 2007 incorpora importantes herramientas para facilitar que el usuario pueda realizar filtros complejos sobre formularios, incluso sobre informes, de una manera manera muy sencilla, tanto que uno se pregunta si merece la pena continuar con los procedimientos que, durante años, hemos ido añadiendo a nuestras aplicaciones para filtrar.

Para muestra vale un botón (el de filtro): 

image

image

Con sólo posicionarnos en un campo de un formulario, en este caso de fecha, y pulsar el botón de Filtro que encontramos en la Cinta de Opciones, Access despliega una abrumadora relación de opciones para filtrar el formulario por el campo en el que nos encontramos.

Las opciones que se despliegan varían según el campo por el que vamos a filtrar sea numérico, de texto o de fecha.

 

Varias maneras de acceder a las herramientas de filtro

Usando el menú contextual

Pulsando con el botón derecho del ratón sobre un control del formulario, se despliega un menú contextual que, además de las opciones de edición y orden, muestra las de filtro. Son muy parecidas a las que hemos visto antes con el botón de filtro de la cinta de opciones, pero falta el combo multivalor y se añade la opción de filtro por selección, es decir, el valor actual del control como opción de filtro igual, distinto, mayor o menor.

image

Dos posibilidades de herramientas de filtro casi iguales, pero distintas. El caso es que el menú contextual no está disponible con la runtime de Access y el Ribbon no es accesible en los formularios emergentes :-(

Sin embargo, podemos invocar el menú de filtro (el del Ribbon) posicionándonos el cualquier control y usando el código:

DoCmd.RunCommand acCmdFilterMenu

Y, si lo queremos que se mueste es el menú contextual, podemos usar:

CommandBars("Column Filter").ShowPopup

Usando el Ribbon

En el grupo de la Cinta de Opciones Ordenar y Filtrar, no sólo tenemos el botón de filtro que veíamos antes. Los botones Selección y Avanzadas despliegan una serie de opciones que ya existían en versiones anteriores de Access.

imageimageimage

  • Las opciones de Selección ya existían en versiones anteriores, salvo la última, Entre…, también disponible en el menú contextual y en el botón de filtro, bastante novedosa y útil: muestra un cuadro de diálogo con dos cuadros de texto para indicar los límites de un rango por el que filtrar.

image

La imagen es para un rango de fechas, pero también existe para un rango de números. No existe para texto, aunque para texto hay otras alternativas.

  • Desplegando el botón Avanzadas encontramos Filtro por formulario y Filtro avanzado/Ordenar. Son viejos conocidos de versiones anteriores; el primero presenta el formulario en una vista especial para introducir criterios y el segungo muestra la cuadrícula QBE para editar el text SQL correspondiente al filtro.

Son herramientas mas complicadas de usar que las nuevas de 2007, pero siguen siendo necesarias si queremos manejar cierta complejidad.

Mediante las herramientas del botón de Filtro del Ribbon o del menú contextual, los distintos criterios de filtro se van concatenando con AND sin opciones de usar OR y sin mostrar una vista conjunta de los distintos criterios que se están aplicando. No es necesario elegir entre una y otras, pues se pueden ir complemantando: el filtro que hayamos creado con el menú desplegable podemos editarlo con Filtro por formulario o con Filtro avanzado/Ordenar para hacerlo más complejo.

Alternar el filtrado

Al filtrar, se resalta en naranja un nuevo botón poniendo “Filtrado” en la barra de navegación del formulario :

image

Pulsando sobre él, se desactiva el filtro y cambia el texto del botón a “Sin filtrar”. Si volvemos a pulsar, se vuelve a activar el filtro y a cambiar el texto. Es decir, el botón sirve para alternar la propiedad FilterOn del formulario.

image

Pero aún afina más. Como hemos visto, los criterios de filtro se van acumulando con AND, de manera que un formulario puede estar filtrado por varios criterios; pues bien, ir eliminando selectivamente esos criterios es tan sencillo, como volver a posicionarse sobre el control con el que habíamos filtrado y pulsar de nuevo el botón derecho del ratón, se mostrará entonces una opción en el menú desplegable para quitar ese criterio.

clip_image001[1]

 

Filtros en hojas de datos

Los menús de filtro también están disponibles en las vistas de hojas de datos de tablas y consultas, sin necesidad de que se trata de un subformulario. Además, están directamente accesibles ambos menús de filtro, el contextual y el que veíamos desde el Ribbon, para el primero usando el botón derecho del ratón y, para el segundo, pulsando sobre el pequeño triángulo con un vértice hacia abajo que aparece junto al nombre de cada campo.

imageimage

Al aplicar el filtro, junto nombre del campo que hemos usado aparece un minúsculo icono de filtro

image

Y, si pulsamos en él se despliega el menú de filtro con, entre otras, la opción para quitar el filtro por ese campo.

image

Filtros en informes

Algo sorprendente en Access 2007 es que los informes también pueden filtrarse dinámicamente de la misma manera que hacemos en un formulario. Como veíamos en un artículo anterior, existen Nuevas vistas de informe en Access 2007 distintas de la Vista Preiliminar.

 image image

Si abrimos nuestro infrome como Vista Informe, se presenta de una forma peculiar, sin opciones de impresión o vista previa y sin saltos de página, pero con algunas opciones propias de los formularios, como la posibilidad de seleccionar y copiar texto, etiquetas inteligentes o las opciones de filtro, todas las que hemos visto antes para filtrar informe. Una vez filtrado, podemos imprimirlo directamente utilizando Botón de Office | Imprimir o pasar a la Vista Preliminar desde la opción Vistas del Ribbon.

 

Un poco de código

Menú de filtro en formularios emergentes

La cinta de opciones no está disponible si estamos utilizando un formulario emergente, por lo tanto, no podemos usar el menú de filtro propio de esa cinta, salvo que lo hagamos por código:

Private Sub Filtro_Click()
Dim ctrl As Control
   On Error GoTo Filtro_Click_Error

Set ctrl = Screen.PreviousControl
ctrl.SetFocus
DoCmd.RunCommand acCmdFilterMenu

   On Error GoTo 0
   Exit Sub

Filtro_Click_Error:

    MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure Filtro_Click of Documento VBA Form_Detalles de empleados"

End Sub

 

clip_image001image

El mismo botón sirve para filtrar en el formulario principal o en un subformulario. Sólo es cuestión de posicionarse previamente en el campo por el que queremos filtrar

 

Aprender de Access

Resulta un ejercicio interesante ver cómo los menús de filtro de Access construyen los criterios de filtro. Para ello, en un formulario para ensayos añadimos un cuadro de texto txtFiltro y el siguiente código:

Private Sub Form_ApplyFilter(Cancel As Integer, ApplyType As Integer)
Me.txtFiltro = Me.Filter
End Sub

De esta manera, cada vez que apliquemos un filtro, veremos el criterio que se ha generado.

image

(([Productos].[Categoría]="Bebidas")) 
AND ([Productos].[Costo estándar]<=13.5)

 

Observamos que, a medida que vamos filtrando, se van añadiendo cadenas de filtro unidas por AND, lo cual era perfectamente previsible. Claro, que sólo cabe unir los distintos criterior con AND y a lo mejor nos interesa unir alguno con OR. Con un par de líneas nás de código podemos hacer que, si editamos el texto que nos muestra el filtro, éste se convierta en el nuevo filtro de nuestro formulario.

Private Sub txtFiltro_AfterUpdate()
Me.Filter = Me.txtFiltro
Me.FilterOn = True
End Sub

 

Desplegable Multivalor para filtrar

Resulta curioso observar cómo la sintáxis va cambiando según la cantidad y proporción de elementos que vayamos seleccionando para filtrar en el desplegable multivalor del menú de filtro.

image image image image

Las distintas selecciones provocan distintos criterios de filtro según se haya seleccionado un sólo elemento o unos pocos, o todos menos uno o todos menus unos pocos. Los criterios generados son las siguientes.

 

([Empleados ampliados].[Apellidos]="Acevedo")
([Empleados ampliados].[Apellidos] In ("Acevedo","Bonifaz","Jesús Cuesta"))
([Empleados ampliados].[Apellidos]<>"Chaves" Or [Empleados ampliados].[Apellidos] IS Null)
([Empleados ampliados].[Apellidos] Not In ("Chaves","Jesús Cuesta") Or [Empleados ampliados].[Apellidos] IS Null)
 
Filtrando campos multivalor

Nada de todo esto nos resulta novedoso, así que vamos a ver cómo se generan los filtros con campos multivalor, específicos de Access 2007.

image

En el menú contextual de filtro elegimos el valor actual de nuestro campo multivalor: “Contiene Proveedor D; Proveedor F”. Filtramos y vemos que el filtro generado es el siguiente:

([Lookup_Supplier IDs].[Compañía]="Proveedor D" 
AND [Lookup_Supplier IDs].[Compañía]="Proveedor F")

 

LookUP

Es decir, que ha concantenado con AND los distintos valores de nuestro campo multivalor, algo previsible. Sin embargo, si nos fijamos, nuestro campo se llama [Supplier IDs] mientras que el nombre que aparece es [Lookup_Suplier IDs], o sea, lo mismo pero con un “LookUp_” delante. Eso me suena de versiones anteriores utilizando “Filtro por formulario”…

Utilizando la herramienta de filtro “Avanzadas | Filtro avanzado/Ordenar…” vamos a verlo por dentro.

Esa herramienta se encuentra en el Ribbon y, como estamos en un formulario emergente, no podemos acceder a ella, de manera que, o bien quitamos la propiedad Emergente al formulario y seleccionamos la opción correspondiente en el Ribbon…

image

O bien añadimos un botón que llame a la herramienta mediante código:

Private Sub FiltroAvanzado_Click()
DoCmd.RunCommand acCmdAdvancedFilterSort
End Sub

De cualquiera de las dos maneras el resultado será que se muestre el diseñador gráfico de consultas con el filtro actual

image

Observamos que a la tabla origen de nuestro formulario, Productos, se le ha relacionado una tabla o consulta llamada Lookup_Supplier IDs y que coinciden con los campos que se encuentran en el Origen de la Fila del cuadro combinado que usamos para la búsqueda de Id de Proveedores. Recordemos que, para que un campo sea Multivalor, en el diseño de la tabla, en la pestaña “Búsqueda” debemos usar un cuadro combinado con un origen válido y Permitir varios valores.

Por lo tanto, el filtro con Lookup se usa en los campos multivalor porque son cuadros combinados. La sintáxis, si queremos crear nuestro propios criterios con Lookup_ , sería algo así:

([Lookup_NombreControl].[NombreColumnaMostrada]="Criterio filtro")
 
Usando el operador "=" no deja de ser una chorradita, pues para eso podemos buscar directamente por el campo dependiente. Pero si usamos "Like" o cualquier otro operador en su lugar, la cosa cambia, pues el filtro se hace por la columna mostrada que no está en el origen de datos del formulario filtrado. Evidentemente, esto es una gran ventaja a la hora de construir un filtro.
 
Si utilizamos esa sintaxis al montar nuestra propia cadena de filtro, funciona perfectamente, añadiéndole potencia de una forma muy sencilla.
 
En resumen, que es una herramiento muy maja y que funciona muy bien y, sin embargo, no he encontrado nada en la ayuda ni en ningún otro lado. Todo lo que he encontrado, y con ayuda de Emilio Sancha, es este enlace de Allenbrowne que lo usa, para búsquedas, en una aplicación de ejemplo: http://www.allenbrowne.com/AppFindAsUType.html. Prometo que profundizaré en el asunto y publicaré los resultados, aunque todo el mundos sabe ya que, para estas cosas, soy hombre de poca palabra ;-)
 
 

ApplyFilter

Entre las novedades en Access 2007 se cita la nueva sintáxis de AppliFilter

Sintaxis anterior

Sintaxis nueva

Sencillamente se le ha añadido un parámetro ControlName y, probando, nos encontramos con que sólo es válido el nombre de un control de subformulario o subinforme, por lo que es fácil deducir que sirve para filtrar directamente el subformulario o subinforme desde el principal.

Por ejemplo, si queremos filtrar el subformulario Child22, podemos poner en el formulario principal un botón con el siguiente código.

Private Sub Mibotón_Click()
DoCmd.ApplyFilter , "Transacción='Compra'", "child22"
End Sub

Teniéndolo en mente, esto puede facilitar un poco las cosas en determinadas ocasiones, pero no pasa de ser una insignificancia ¿Para qué se han tomado la molestia? Me imagino que será para facilitar el uso de macros. Las macros ejecutan comandos y, si sólo añadiendo un parámetro, el filtro se puede aplicar a un subformulario, la macro se simplifica notablemente.

Publicado por Chea con 10 comment(s)
Archivado en: ,

Online: Mejora de las aplicaciones Access 22/01/09

 

Mejora de las aplicaciones Access con SQL Server y Sharepoint

El evento lo vamos a grabar y lo transmitiremos online, os paso los datos de conexión para que probéis el acceso:

 

Evento Online 1era parte – sesión mañana

  • Event URL :
  • Evento Online 2da parte – sesión tarde

  • Event URL :
Publicado por Chea con 3 comment(s)
Archivado en: ,,

Access Developer Extensions en español

En el grupo de noticias de Access, Freddy M. Aragón nos ha informada que ya están disponibles para su descarga las Access Developer Extensions en español.

Las Developer Extensions añaden una nueva opción Programador al menú de Office que nos permite crear un paquete de instalación y guardar como plantilla.

Si ya teníamos instalada la versión en inglés, sencillmanente sustituya una por otra.

image

Publicado por Chea con 3 comment(s)

El uso de las Cintas de Opciones (Ribbon) y XML (Lenguaje de Marcado Extensible). RibbonAndXML_01

Capítulo 1

 La pretensión de este artículo (se incluye demo) es aprender a cambiar de Cinta de Opción (Ribbon) haciendo uso del XML (Lenguaje de Marcado Extensible).

Sin ánimo de ser exhaustivo la sintaxis es muy similar a la del HTML, es otro lenguaje basado en marcas pero estas son “más estrictas”, contiene propiedades que la hacen que tenga un formato de datos útil para poder ser leído por varios programas e incluso sistemas.

 Las reglas básicas de la especificación XML son las siguientes:

·         Sólo se permite un único elemento raíz.

·         Deben de existir etiquetas de inicio y fin para cada elemento, <elemento>…</elemento>.

·         Es sensible a mayúsculas y minúsculas.

·         Los atributos deben estar entrecomillados.

·         El texto comentado tiene la siguiente estructura <!-- … -->

·         y más, pero dejo a San Google para complementar la información.

Primeros conceptos del código XML que genera la Cinta de Opciones (Ribbon).

<customUI xmlns=http://schemas.microsoft.com/office/2006/01/customui>

      <ribbon startFromScratch="true">

</ribbon>

</customUI>

 

La primera etiqueta a utilizar siendo necesaria para las personalizaciones del Ribbon, es también el elemento raíz.

<customUI xmlns=http://schemas.microsoft.com/office/2006/01/customui">

La siguiente etiqueta hace referencia al objeto Cinta de Opciones y que cuenta con el atributo que puede tener dos valores true y false. Si su valor es true se quitarán todas las fichas predetermiadas por Office y la personalizada es la que quedará visible. False para no modificar las existentes dejando a la derecha la nueva.

      <ribbon startFromScratch="true">

Importante conocer que este modo también oculta los comandos que tiene el nuevo menú Office excepto Nuevo, Abrir, Guardar como y Cerrar base de datos, tal como veremos a continuación en la imagen.

Así de sencillo, con tan sólo una línea hemos modificado toda la Cinta preparándola para usar nuestras propias fichas y grupos.

El modo startFromScratch está diseñado para ser compatible con las futuras versiones de Office, es decir, si se agrega una nueva ficha o elemento del menú Office, el modo startFromScratch debería ocultarlos automáticamente.

Por estos motivos es más conveniente usar startFromScratch que no ir ocultando uno a uno los elementos del menú Office y las diferentes fichas y grupos de la Cinta de Opciones.

Usando estas cinco líneas ya podemos conseguir un efecto significativo en la ventana de Access y que se presenta en la imagen siguiente.

BotónOffice01

 En caso de querer modificar la visibilidad de los comandos que están incluidos en el Botón de Office hay que usar la etiqueta <officeMenu>

Para ocultar el comando Nuevo utilizar el identificador de Office "FileNewDatabase" y cambiar su atributo visible a "false"

<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">

      <ribbon startFromScratch="true">

             <officeMenu>

                  <button idMso=" FileNewDatabase" visible="false" />

            </officeMenu>

 </ribbon>

</customUI>

Analicemos la nueva etiqueta button para entender un poco más como penetrar en este nuevo mundo del XML y del Ribbon.

                  <button idMso="FileNewDatabase" visible="false" />

Los controles de la Cinta deben de contener como mínimo un elemento que los identifique como únicos y puede ser uno de los siguientes de esta lista:

·         idMso: es el identificador de un menú que contenga Office, nombre interno.

·         id: Identificador para los controles personalizados y debe de ser único.

·         idQ: Identificador cualificado cuyo contenido debe de ser una abreviatura del espacio de nombres.

El siguiente elemento de la etiqueta es un atributo y que en este caso que se llama visible. Modificando su valor (“entrecomillado”) conseguimos ocultarlo ("false") o hacerlo visible ("true").  

Para conocer una lista de los nombres internos que ha establecido Microsoft para los comando podemos descargarnos un archivo desde la url siguiente, http://www.microsoft.com/downloads/details.aspx?FamilyID=4329d9e9-4d11-46a5-898d-23e4f331e9ae&displaylang=en. Conseguiremos un montón de libros de Excel organizados por producto, Access, Excel, Outlook, Word, etc.

Continuamos con los comandos que todavía nos quedan visibles, Abrir, Guardar como y Cerrar base de datos, así como la lista de Documentos recientes.

Para ocultar el comando Abrir, "FileOpenDatabase" y el botón desplegable Guardar como, "FileSaveAsMenuAccess" podemos usar el siguiente código,

            <button idMso="FileOpenDatabase" visible="false" />

            <splitButton idMso="FileSaveAsMenuAccess" visible="false" />

 

Por último de esta serie está Cerrar base de datos, "FileCloseDatabase"

            <button idMso="FileCloseDatabase" visible="false" />

Quedando de este modo si queremos desactivar las cuatro acciones.

      <officeMenu>

            <button idMso="FileNewDatabase" visible="false" />

            <button idMso="FileOpenDatabase" visible="false" />

            <splitButton idMso="FileSaveAsMenuAccess" visible="false" />

            <button idMso="FileCloseDatabase" visible="false" />

      </officeMenu>

Pero es posible que queramos hacer visible alguno de los comandos para poder imprimir un objeto o mandar por correo electrónico, para ello usaremos las siguientes líneas a continuacion de las anteriores,

            <button idMso="PrintDialogAccess" visible="true"/>

            <button idMso="FileSendAsAttachment" visible="true"/>

BotónOffice02 

Doy por finalizado este capítulo primero, espero poder presentar otros sucesivos en los que podremos encontrar el modo de deshabilitar el botón de ayuda, minimizar, restaurar, cerrar e incluso los botones de Opciones de Access y Salir.

McPegasus, 14/01/2008

Publicado por McPegasus con 1 comment(s)
Archivado en: ,,

Vincular Vistas de Sharepoint desde Access 2007

Si desde Access 2007, en vez de vincular una Lista de Sharepoint, vinculamos una Vista de ésta, obtenemos claras ventajas, la más evidente limitar el tráfico de datos por la red a los que realmente queremos, pero también otras bastante interesantes, como restringir los datos a los del usuario registrado en el sitio Sharepoint. Sin embargo, los asistente de Access sólo facilitan vincular Listas, debiendo recurrir al método TransferSharePointList para poder conseguirlo.

La misma ayuda de Access sobre TransferSharePointList nos informa de cómo obtener algunos de los paramátros necesarios:

Para obtener el identificador GUID de una lista o una vista del sitio de SharePoint puede utilizar el procedimiento siguiente:

  1. Abra la lista de Windows SharePoint Services.
  2. Si no se muestra la vista que desea, haga clic en la flecha desplegable Ver y, a continuación, seleccione la vista deseada.
  3. Haga clic en la flecha desplegable Ver y, a continuación, seleccione Modificar esta vista.

    La dirección de la barra de dirección del explorador contiene los identificadores tanto de la lista como de la vista. El identificador GUID de la lista sigue a List=, y el de la vista sigue a View=. Sin embargo, en la dirección, cada carácter { (abrir llave) se representa mediante la cadena %7B, cada carácter - (guión) mediante la cadena %2D, y cada carácter } (cerrar llave) mediante la cadena %7D. Por ejemplo:

    http://MySite12/_layouts/ViewEdit.aspx?List=%7B2A . . . 7D&View=%7B357B4FE6 . . . 1579B%7D

    Para poder utilizar los identificadores GUID de la dirección como argumentos de esta acción de macro, primero debe reemplazar cada cadena %7B por el carácter {, cada cadena %2D por el carácter - y cada cadena %7D por el carácter }. No incluya el carácter & (y comercial) que sigue a la cadena %7D en el identificador GUID de la lista.

(Me he permitido recortar la URL que la ayuda usa de ejemplo para que me quepa mejor y porque, en el mismo ejemplo de la ayuda, ya la URL está truncada al final)

Le faltan unas imágenes que ayuden un poco ¿no? Pues se las ponemos:

image    image

Seguir las instrucciones “a mano alzada”, cortando y pegando con el ratón y editando una cadena tan larga, se hace aguantando la respiración y, al final, casi seguro que sale mal (a mí nunca me ha salido bien). Pero para seguir instrucciones al pie de la letra está la programación y en Access contamos con VBA, así que me he hecho el siguiente procedimiento que sólo necesita que copiemos la URL y se la pasemos como cadena de texto:

 

'---------------------------------------------------------------------------------------
' Procedure : VincularVistaWSS
' DateTime  : 30/12/08 20:36
' Author    : Chea
' Purpose   : Vincula una Vista de Sharepoint a partir de una URL
'             Para vincular una Vista de Sharepoint, debemos, en primer lugar, ir al
'             sitio de Sharepoint, a la página de configuración de dicha vista y copiar
'             la URL completa: Esa URL, delimitada por comillas, es el argumento que
'             debemos pasar a esta función en el parámetro CadenaURL
'---------------------------------------------------------------------------------------
'
Public Sub VincularVistaWSS(CadenaURL As String, Optional NombreTabla)

Dim GUIDList As String
Dim GUIDView As String
Dim strSite As String
Dim v As Variant, V2 As Variant, V3 As Variant, i As Integer
Dim stTmp As String

' "Traducimos" caracteres de la cadena URL
CadenaURL = Replace(CadenaURL, "%7b", "{")
CadenaURL = Replace(CadenaURL, "%7d", "}")
CadenaURL = Replace(CadenaURL, "%252E", ".")
CadenaURL = Replace(CadenaURL, "%252F", "/")
CadenaURL = Replace(CadenaURL, "%253A", ":")
CadenaURL = Replace(CadenaURL, "%2D", "-")

' Obtenemos la segund parte de la URL, desde el aspx?
v = Split(CadenaURL, "aspx?")
stTmp = v(1)

'Obtenemos las distintas secciones, que van separadas por "&"
v = Split(stTmp, "&")
For i = 0 To UBound(v)
    V2 = Split(v(i), "=")
    If Trim(V2(0)) = "List" Then
        GUIDList = V2(1)
    End If
    If Trim(V2(0)) = "View" Then
        GUIDView = V2(1)
    End If
    If Trim(V2(0)) = "Source" Then
        strSite = V2(1)
        V3 = Split(strSite, "/Lists/")
        strSite = V3(0)
    End If
Next i

' Vinculamos la vista
DoCmd.TransferSharePointList acLinkSharePointList, strSite, GUIDList, GUIDView, NombreTabla

End Sub
Publicado por Chea con 2 comment(s)
Archivado en: ,

Office Live Small Business en español

Desde hace tiempo está disponible una versión de Office Live Small Business en español, concretamente para México. Los servicios de pago están disponibles para empresas mexicanas, pero la parte “free” es de libre acceso, lo cual es una gran noticia para los hispanohablantes. Yo ya me había acostumbrado a las opciones y menús en lengua hereje, pero sigue sin gustarme que en mi sitio web determinados módulos, por ejemplo formularios, muestren irremediablemente encabezados,expresiones y formatos en inglés. La nueva versión lo traduce todo al español.

Al entrar en la página de Office Live Samll Business, la opción de país predeterminada es Unites States, pero al lado tenemos un botón “Change”. Al pulsarlo, podemos elegir país entre une breve relación de ellos en la que, sólo recientemente, aparece México.

imageclip_image001image

 

Lo había observado hace no sé si una o dos semanas, pero, al cambiar, sólo la página de presentación se mostraba en español y, al entrar en mi sitio, todo seguía en inglés. Probé  con una de esas viejas cuentas de prueba, cancelé la cuenta de Office Live y, con el mismo Live ID creé una nueva, que seguía con todo en inglés.

Ayer creé una cuenta nueva de Hotmail y, esta vez sí, al crear una cuenta de Office Live en México, todo aparecía en español. Es decir, por cambiarnos de país no se “traduce” nuestro sitio, ni si seguimos usando el Live ID que había usado previamente, pero si creamos una cuenta nueva con un ID sin estrenar, podremos tener nuestro sitio completamente en español.

No todo son buenas noticias. Intento hacer un backup desde mi sitio en inglés y restaurarlo en español y obtengo un mensaje de error de que no es posible hacer un Restore con una configuración de idioma distinta.

Publicado por Chea con 5 comment(s)
Archivado en: ,

Presentaciones Seminario Microsoft Access SQL Server del 17/10/2008

El viernes 17 de octubre se celebró en las oficinas de Microsoft en Madrid un seminario sobre la migración de aplicaciones Access a SQL Server, organizado e impartido por Serra GTS (www.SerraGTS.com) . El seminario era gratuito pero solo había 25 plazas disponibles que se completaron dos semanas antes del evento.
 
Asistieron responsables de informática de la Administración pública y empresas privadas, y desarrolladores de aplicaciones Access.
 
La primera presentación realizada por Valentín Playá, director general de Serra GTS, con el título "Access y SQL Server, que es mejor en cada caso" se centró en los distintos usos de las bases de datos dentro de una organización y la mejor arquitectura de las aplicaciones Access para cada caso.
 
A continuación Mario Playá, director de desarrollo de Serra GTS, presentó el tema "De Access a SQL Server, paso a paso", exponiendo detalladamente las formas de realizar la migración tanto de los datos como del código.
 
Durante la última parte del seminario, Alejandro Leguizamo de Solid Quality Mentors y MVP de SQL Server, expuso las funcionalidades de SQL Server y respondió a las preguntas que le plantearon los asistentes.
Aquí están las presentaciones:
Publicado por Chea con no comments

Seminario de SQL Server para desarrolladores de Access

Acaba de anunciarse este seminario gratuito sobre SQL Server para desarrolladores de Access que tendrá lugar en las intalaciones de Microsoft http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032391507&Culture=es-ES el viernes, 17 de octubre de 2008 de 9:0 a 13:30.

Publicado por Chea con no comments

Evento NotInList en Access 2007

En Access 2007, el evento NotInList puede funcionar exactamente igual que en versiones anteriores, pero dos nuevas propiedades de los cuadros combinados y listas, Permitir ediciones de la lista de valores y Formulario de edición de la lista, pueden hacer innecesario escribir una sola línea de código para este evento. Fue empezar a escribir estas líneas antes de las vacaciones y verme explicando en algún foro a algún no tan principiante cómo se utiliza NotInList, así que no está de más empezar repasando la manera más canónica de usarlo, pues aún hay gente que no lo entiende y se complica haciendo cosas raras; luego contaremos como, modificando un par de propiedades, en Access 2007 puede ser innecesario.

El evento NotInlist en cualquier versión de Access

Manejar el evento NotInList suele resultar complicado a los principiantes. A pesar de su simplicidad aparente, se manejan algunos conceptos con los que posiblemente no estén familiarizados.

Aunque esté claramente explicado en la ayuda, suele obviarse que el evento NotInList cuenta con dos parámetros con un cometido muy específico: NewData nos proporciona el valor que hemos introducido y que no está en la lista y Response espera que le demos un valor de entre una serie de opciones (acDataErrDisplay , acDataErrContinue o acDataErrAdded) para que la aplicación actúe en consecuencia, mostrando mensaje de error o no o aceptando el nuevo valor y haciendo un requery del combo.

A veces no basta con meter un dato directamente a una tabla, sino que es necesario abrir un formulario para añadir ese y otros datos. La cuestión aquí es cómo esperar a que se introduzca, o no, el nuevo dato y luego darle el valor apropiado al parámetro Response. Es fácil si se tienen las claves:

Si al abrir un formulario DoCmd.Openform utilizamos la constante acDialog en el parámetro WindowMode, éste se abrirá en modo diálogo, de manera que cualquier otro código se detiene hasta que cerremos el formulario.

DoCmd.OpenForm "Detalles de clientes", , , , acFormAdd, acDialog

Ahora, el problema está en pasar información entre el formulario que está abierto y el que ha detenido el código hasta que se cierre el otro. A mí me gusta dimensionar una variable como pública en la sección de declaraciones del formulario que contiene el cuadro combinado. Al declararla como pública será accesible desde cualquier lugar de la aplicación, como si fuera una propiedad del formulario, con la ventaja de que morirá con el formulario. Podemos asignarle un valor desde el formulario abierto en modo diálogo y luego comprobarlo al cerrar éste.

El código completo en el formulario del evento NotInList sería el siguiente:

Option Compare Database
Option Explicit

Public Respuesta As Integer

Private Sub Id_de_cliente_NotInList(NewData As String, Response As Integer
    DoCmd.OpenForm "Detalles de clientes", , , , acFormAdd, acDialog, NewData 
    Response = Me.Respuesta
End Sub

Y, en el formulario diálogo, bastaría con una cosa así:


Private Sub cmdAceptar_Click()
    Forms!Pedidos.Respuesta = acDataErrAdded
End Sub

Private Sub cmdCancelar_Click()
    Forms!Pedidos.Respuesta = acDataErrContinue
End Sub

Es decir, al Aceptar o Cancelar, damos a la variable pública Respuesta del primer formulario el valor que luego tomará Response.

Normalmente, querremos que en el formulario de edición ya se haya insertado el nuevo valor introducido en la lista en su cuadro de texto correspondiente. Para eso, en el último parámetro de la instrucción Docmd.OpenForm, OpenArgs, he pasado el valor de NewData:

DoCmd.OpenForm "Detalles de clientes", , , , acFormAdd, acDialog, NewData

En el formulario para añadir el nuevo dato comprobamos si estamos en un nuevo registro y si hemos pasado algún valor en OpenArgs, en cuyo caso, nos posicionamos en el control correspondiente con SetFocus y ponemos en la propiedad Text el valor que hemos recibido en OpenArgs.

Option Compare Database
Option Explicit
Private Sub Form_Load()
    If Me.NewRecord And Nz(Me.OpenArgs, "") <> "" Then
        Me.Apellidos.SetFocus
        Me.Apellidos.Text = Me.OpenArgs
    End If
End Sub

El Evento NotInlist en Access 2007

En Access 2007, dos nuevas propiedades de los cuadros combinados y listas, "Permitir ediciones de la lista de valores" y "Formulario de edición de la lista", pueden suplir al evento NotInlist.

Propiedad Permitir ediciones de la lista de valores

Si el Tipo de origen de la fila es Lista de valores y el cuadro combinado o lista tiene una sola columna, si establecemos el valor de la propiedad Permitir ediciones de la lista de valores a , podremos modificar sus valores en tiempo de ejecución. Tenemos dos posibilidades:

Editar directamente la lista

Al desplegar un cuadro combinado o lista que tenga Permitir ediciones de la lista de valores, se muestra al final de la lista un icono flotante.

image

Si pulsamos sobre el icono, se despliega un formulario para editar los valores de la lista, incluso podemos editar el valor predeterminado.

image

Al no estar en lista

Funciona de la misma manera que el evento NotInList, de hecho, en primer lugar se dispararía ese evento. Es decir, si la propiedad Limitar a Lista es e introducimos en ella un valor inexistente, Access 2007 nos informará de que no existe el valor y nos preguntará si deseamos modifcar los elementos de la lista, en cuyo caso nos abriría el mismo formulario para editar valores que en el caso anterior.

image

Ambas posibilidades sólo funcionan si la lista o cuadro combinado sólo tiene una columna. Si tiene más de una columna, tendríamos que recurrir a los mismos métodos de versiones anteriores.

Propiedad Formulario de edición de la lista

La propiedad Formulario de edición de la lista indica el nombre del formulario que queremos usar para editar los valores de un cuadro combinado o lista cuando cuando la propiedad "Tipo de origen de la fila" es Tabla o Consulta.

image

Lo mismo que veíamos cuando el tipo de origen de la fila era "Lista de valores", podemos editar los valores en tiempo de ejecución, bien pulsando directamente sobre el icono flotante al final de la lista desplegada, bien al introducir un valor que no existe; la diferencia es que el formulario de edición será uno que nosotros hayamos creado para editar la tabla subyacente al combo o lista.

Nuestro formulario se abrirá en modo diálogo (no necesariamente emergente) deteniendo la ejecución del código de los demás formularios. Al cerrarse, si se han modificado los datos, se actualizará el origen de datos del combo o lista. y si el texto que habíamos introducido coincide con un nuevo valor, se dará por válido y no se producirá error. O sea, más o menos lo que nosotros habríamos hecho editando el evento NotInList.

Añadiendo un poco de código

Pero este formulario se comportará exactamente igual si hemos pulsado el icono flotante para editarlo que si se ha abierto al no estar en la lista, es decir, se abre en modo edición en el primer registro. Seguramente querremos que se comporte como hemos hecho mediante código en versiones anteriores, o sea, que vaya directamente a un registro nuevo y que posicione en el cuadro de texto correspondiente el valor que hemos introducido en la lista ¿Cómo conseguimos esto? Tendremos que usar un mínimo de código.

Si en el formulario de edición de la lista ponemos el siguiente código

Private Sub Form_Load()
Debug.Print Me.OpenArgs
End Sub

Al no estar en lista, en la venta de inmediato del editor de VBA nos encontraremos algo así:

[Detalles de pedidos de compra]![Supplier ID]=Ramirez

Es decir, que al abrirse el formulario el formulario de edición de la lista, sin necesidas de ninguna intervención por nuestra parte, Access 2007 ha pasado un argumento OpenArgs con el nombre del formulario y el del cuadro combinado o de lista y el valor que hemos dado a éste. Podemos utilizar OpenArgs para, si existe, ir a un registro nuevo y rellenar el cuadro de texto correspondiente:

Private Sub Form_Load()
Dim v As Variant
If Nz(Me.OpenArgs, "") <> "" Then
   If InStr(Me.OpenArgs, "=") <> 0 Then
        v = Split(Me.OpenArgs, "=")
        DoCmd.GoToRecord , , acNewRec
        Me.Apellidos.SetFocus
        Me.Apellidos.Text = v(1)
    End If
End If
End Sub

Pero ¿Qué pasa con el evento NotInlist en Access 2007?

Podemos usar el evento NotInList junto con la propiedad Formulario de edición de la lista. En primer lugar se disparará el evento y luego, dependiendo del valor que en éste demos a Response, se abrirá automáticamente, o no, el formulario de edición de la lista.

Publicado por Chea con 6 comment(s)
Archivado en: ,

¿Quién dijo memos?

     Los memos en Access 2007 ya no parecen tan memos. Ahora vienen con un par de características que les hacen más interesantes: Soportan formato de texto enriquecido y la posibilidad de sólo permitir anexar, no modificar. Un año después del lanzamiento de la versión 2007, esto ya no es novedad, pero aún cabe jugar con ellos para explorar posibilidades que quizás se escapen a primera vista.

Este artículo fue publicado en el Rincón del experto del mes de abril.

Formato de texto enriquecido

TextFormat en controles de texto

Ésta, que es la novedad más vistosa, no supone ningún cambio en el tipo de datos, sino que el mérito se lo lleva el nuevo control de texto que es capaz de manejar el "Rich text format". Los campos memos siguen guardando texto plano, pero dependiendo de cómo esté establecida la propiedad "Formato de texto", Textformat, mostrará el formato enriquecido o las etiquetas HTML de éste.

Es decir, si en el cuadro de texto TexFormat = acTextFormatHTMLRichText, podríamos ver algo así:

Muestra

Pero, si en el cuadro de texto TexFormat = acTextFormatPlain, lo que veríamos sería:

<div align=center><font size=5 style="BACKGROUND-COLOR:#FFFF00"><strong><em><u>Muestra</u></em></strong></font></div>

Como la propiedad lo es del cuadro de texto, se aplica no sólo a los memos de 2007, sino también a los de versiones anteriores de Access. Si usamos el formato enriquecido con campos de un archivo en formato MDB desde Access 2007, se comportará igual que un ACCDB, pero, si lo vemos desde una versión anterior de Access, por ejemplo, 2003, se mostrarían las etiquetas HTML.

TextFormat en campos memo

Pero no sólo los controles de texto tienen la propiedad "Formato de texto" o TextFormat, también la tienen los campos memo. A simple vista, da la impresión de que esto afecta de alguna manera a los datos, pero no parece que sea así; sigue siendo texto plano, con o sin etiquetas HTML. Bueno, en cierto modo sí que afecta a los datos: si en un memo con texto enriquecido cambiamos la propiedad TexFormat a acTextFormatPlain, desaparecerán de manera irreversible todas las etiquetas HTML, lo cual puede ser útil para hacerlo legible en versiones anteriores de Access, pero un poco peligroso si andamos jugando con datos reales.

Si mostramos los datos de la tabla y el formato de texto es enriquecido, se muestra como tal, dando la apariencia de que se ha guardado de una forma especial, pero si en una consulta o en un formulario, creamos un campo calculado cuyo origen sea = MiMemo, veremos que el contenido sigue siendo un archivo de texto con etiquetas HTML.

Al añadir un campo memo a un formulario o informe en modo diseño, el cuadro de texto hereda la propiedad TextFormat del campo, pero podemos cambiarle la propiedad a la contraria y, si no hay datos, ésta prevalecerá. Si existen datos, también prevalecerá la propiedad pero el resultado inmediato sobre los datos existentes seguramente será chocante, pues hay que tener en cuenta que las etiquetas HTML no dejan de ser texto.

Resumiendo

  • La propiedad Formato de Texto en un campo memo en el diseño de la tabla sirve para determinar cómo se muestran los datos en la vista Hoja de Datos de la tabla y para ser heredada por los controles que tengan por origen ese campo.
  • La propiedad Formato de Texto en un cuadro de texto determina la forma en que se muestra éste.
  • No tiene por qué coincidir la propiedad TextFormat de un control con la de del campo memo del que dependa, aunque con datos existentes se pueden producir resultados chocantes.

Juguemos un poco

Busquemos usos distintos:

image

 

Una forma muy sencilla de mostrar "etiquetas" en texto enriquecido es crearnos una tabla con un memo con formato enriquecido que editamos a nuestro gusto. Para el equivalente de una etiqueta podemos usar un campo calculado con un dLookUp() que busque el registro que queramos. Para que se comporte como una etiqueta, basta con poner las propiedades Bloqueado a y Activado a No. Sustituir a un msgbox puede ser algo casi tan sencillo como eso o darle toda la complejidad que queramos.

Concantenando variables

Es muy frecuente concatenar campos o variables con cadenas de texto para mostrar los resultados en un informe o formulario. Podemos usar, por ejemplo:

= "Estimado Sr. " & [PrimerApellido] & ":"

Para obtener el resultado:

Estimado Sr. Fernández:

Pero nos faltaba una posibilidad sencilla de poder formatear ese campo calculado, por ejemplo, poner en negrilla el apellido. Cómo hemos visto que se trata de etiquetas HTML, basta con añadir éstas a la cadena para conseguir el resultado:

="Estimado Sr. <strong>" & [PrimerApellido] & "</strong>"

Y el resultado que obtendríamos sería:

Estimado Sr. Fernández
No hace falta saber HTML para hacer esto. Podemos crearnos un formulario auxiliar con dos cuadros de texto, uno con formato enriquecido y otro sin él cuyo origen sea el primero. Cualquier formato que demos en el primer cuadro, se reflejará en código en el segundo. Sólo hay que copiar y pegar, teniendo en cuenta que <div> y </div> son las marcas de inicio y fin de párrafo y que puede que no necesitemos.

 image  image

 

Aún así sigue siendo pesado, de manera que tendremos que ingeniarnos una herramienta distinta. Son sólo tres pasos:

 

  1. Nos creamos una tabla con un campo de Formato, de texto, y otro Muestra, memo, y un formulario para editarla en el que al campo Muestra le ponemos como valor predeterminado, "Muestra" y como Formato de texto,"Texto enriquecido".

image

  1. Le damos a Muestra los formatos que queramos y en Formato ponemos un texto descriptivo para después localizar el formato.
  2. Nos creamos una función que busque Formato, lea el contenido de Muestra y en él sustituya la palabra "Muestra" por el contenido que queremos formatear

Public Function FormatoHtml(Cadena As String, Formato As String) As String
Dim vTmp As Variant, sTmp As String
vTmp = DLookup("Muestra", "LocalFormatos", "Formato = '" & Formato & "'")
If Not IsNull(vTmp) Then
    sTmp = vTmp
    sTmp = Replace(sTmp, "<div>", "")
    sTmp = Replace(sTmp, "</div>", "") 'Quitamos las marcas de párrafo que nos sobran
    sTmp = Replace(sTmp, "Muestra", Cadena) 'Cambiamos el texto Muestra por nuestra cadena
Else
    sTmp = Cadena 'Si no encontramos el formato, devolvemos la cadena sin formato
End If
   
FormatoHtml = sTmp
End Function

Probando en la ventana de inmediato, tendríamos:

?  FormatoHtml ("Hola mundo","negrita")
<strong>Hola mundo</strong>

? FormatoHtml(FormatoHtml("Hola mundo","negrita"),"Cursiva")
<em><strong>Hola mundo</strong></em>

De la misma manera, en el primer ejemplo, podríamos poner algo así:

="Estimado Sr. " & FormatoHtml([PrimerApellido];"negrita") & ":"

y el resultado sería:

Estimado Sr. Fernández:
Ahora le toca jugar a cada uno.

Evidentemente, la función es un apaño que tendríamos que mejorar. Un DLookUp () en cada registro de una consulta, bajaría notablemente el rendimiento; en su lugar podríamos cargar la tabla de formatos en una matriz o en un objeto Dictionary y buscar ahí.

También nos podría interesar una composición más compleja abriendo y cerrando formatos. Nos seguiría valiendo la misma tabla y la misma búsqueda; haciendo un Split() del resultado usando como separador la palabra "Muestra", tendríamos en el primer elemento de la matriz resultante las etiquetas de apertura, y en el segundo, las de cierre.



 

Publicado por Chea con 2 comment(s)
Archivado en: ,

Reunión de usuarios de Access el 13 de junio de 2008

Se ha organizado una reunión de usuarios de Access en Madrid para el próximo 13 de junio. La idea es que podamos conocernos personalmente y ver alguna presentación de temas de interés relacionados con Access. La vocación es que algún puede acabar siendo el inicio de un grupo de usuarios de Access.

Si te interesa el tema, sigue el enlace: http://reunionaccessmadrid20080613.googlepages.com/

 

 

 

Publicado por Chea con no comments

El uso de las Cintas de Opciones (Ribbon) y VBA (Visual Basic for Application). RibbonAndVBA

En este artículo se va a tratar a un nivel básico de las Cintas de Opciones (Ribbon) y su uso con VBA.

Ribbon a nivel de base de datos.

Si uno está acostumbrado a usar Barras de Herramientas Personalizadas deberá de cambiar el “chip” bueno jejeej cambiar no, olvidarse totalmente de ese concepto para entrar a un nuevo mundo del Ribbon que “supera” a las Barras pero que incomoda al tener que aprender varios conceptos nuevos y los siguientes son alguno de ellos,
  • El Ribbon va asociado a un formulario o informe o a la aplicación.
  • El Ribbon que esté asociado a un formulario sólo está activo cuando dicho formulario al estar abierto no sea emergente y esté visible, cualquier cambio de valor de estas dos últimas propiedades hace que el Ribbon desaparezca.
En caso de asociar el Ribbon a la base de datos este estará en cache mientras dure la sesión de la aplicación pudiendo ser sustituido por otra al abrir un formulario o informe volviendo a ser visible al cerrar los objetos comentados.Usando la interface de Access se puede establecer el Ribbon del siguiente modo,
  • Botón Office | Opciones de Access | Base de datos actual | Opciones de barra de herramientas y de la cinta de opciones | Nombre de banda de opciones:
 

 

Con código de VBA usando la propiedad “CustomRibbonID” del objeto Database.

  • CodeDb.Properties("CustomRibbonID") = "rbbInicio"
O para crearla,
  • CodeDb.Properties.Append CodeDb.CreateProperty("CustomRibbonID", dbText, "rbbInicio")
En todos los casos hace falta reiniciar la base de datos para hacer visible el Ribbon.

 

Ribbon a nivel de objetos formulario (form) o informe (report).

Sencillo, sencillo, no hay más que rascar de lo que se indica aquí y de modo parecido a la sección anterior hay un método visual y otro a través de código VBA.Usando el método visual y en modo edición de un form o report,
  • Hacer visible la Hoja de propiedades (Alt + Entrar) | Solapa: Otras | Nombre de banda de opción.

 

Con código de VBA usando la propiedad “RibbonName” del objeto Form o Report.
  • Me.Properties("RibbonName") = "rbbNombreRibbon"

 

Ribbon, planteamiento de uso.

A la conclusión que he llegado trasteando con esta nuevo bicho de Access 2007 es sencilla pero para llegar a ella me he tenido que pelear unas cuantas horas con él, en realidad es como se aprende y ¡¡salen un montón de notas!!.Para obtener una aplicación con Ribbon hace falta los siguiente,
  • Usar un Ribbon (rbbPrincipal) a nivel de base de datos, tal como se ha comentado en la sección anterior Ribbon a nivel de base de datos.
  • Usar Ribbon independientes para los formularios e informes (rbbFormA, rbbFormB, rbbSub1FormA, rbbSub2FormA, rbbReportA, etc.) que se irán activando y desactivando conforme el objeto tome el foco, tal como se comenta en la sección Ribbon a nivel de formulario (form) o informe (report).
Así de sencillo, no hay más.

Si uno es observador y está familiarizado con las convenciones de nombre podrá comprobar en los nombres de ejemplo de las Cintas de Opciones, como también se indica Sub de subformulario. Si dentro de un formulario existen uno o más subformularios estos también tienen (como formulario que es) la propiedad RibbonName para activar un Ribbon, al activar subFormA se dispara el Ribbon rbbSub1FormA, al tomar el foco subFormB el anterior desaparece y queda activo rbbSub1FormB, ¡genial! Como efecto visual es muy bueno y atractivo.

 

Ribbon ejemplo práctico.

Vayamos a visualizar lo comentado hasta ahora, descargar el ejemplo propuesto al final del artículo llamado test.RibbonAndVBA en Attachment.

Al abrir la base de datos se inicia con un formulario inicial de presentación, al pulsar el botón Aceptar se presenta un nuevo form llamado frmTest con dos grandes botones y un tercero para cerrarlo.

Antes de continuar hay que indicar que previo a abrirse los formularios se activa la Cinta de Opciones llamada rbbPrincipal y es la única visible en estos momentos.Volvemos a frmTest y pulsamos el primer botón grande, “Activar Cinta de Opciones …” y se puede apreciar como ha desaparecido rbbPrincipal y se ha hecho visible rbbAyuda.

 

Ribbon y sus particularidades.

Continuando con la base de datos de test nos encontramos con dos formularios el z01_frmEmergente y z02_frmInvisible que sirven para observar dos particularidades imaginables por su nombre.
  • z01_frmEmergente es un formulario con su propiedad emergente a True, al activar la cinta de opciones rbbAyuda y tras clicar el botón se observa que esta cinta aparece y desaparece inmediatamente por lo que no se aconseja usar este tipo de formularios si debe de usarse una cinta.
  • z02_frmInvisible es visible al abrirlo, activamos la cinta rbbAyuda usando el botón y a continuación clicamos Cambiar el estado de este formulario en invisible, voila, desaparece el form y la cinta. Es comprensible ya que el formulario pierde el foco y por tanto vuelve el Ribbon principal.

McPegasus, 30/04/2008

Publicado por McPegasus con 3 comment(s)
Archivado en: ,

Compatibilidad de la Cinta de opciones (Ribbon) hacia atrás, 2007 --> 2003, 2002 (XP), 2000, 97.

Este artículo trata sobre la compatibilidad que puede existir de usar una aplicación que integre Ribbon en versiones anteriores al Access 2007.

No hay compatibilidad, directamente ¡no funciona!, pero se va a tratar de cómo pueden convivir los dos sistemas, Barras de Herramientas Personalizadas y Cinta de Opciones (Ribbon).

Poco más hay que decir sobre el inicio en el Ribbon que no estén en los artículos siguientes,

Aprovecho para felicitar y promocionar estos artículos, ya que nos hacen ganar en semanas el aprendizaje de esta novedad en Access y avanzar a una velocidad de vértigo.

 

Necesidad:

Partiendo desde cero con el Ribbon y con una aplicación acabada del 2003, surge la necesidad de usarla en 2007 pero teniendo usuarios que utilizan 2003. Podría pensarse en instalar el Runtime del 2007 ya que es gratuito, pero tampoco quiero hacerlo ya que de ese modo no habría tenido la oportunidad que expongo aquí.

Esta aplicación en 2003 hace uso de 5 barras personalizadas que se activan/desactivan según necesidad del formulario o informe, incluso se habilitan o deshabilitan comandos según requerimientos del contenido del formulario.

En dicha versión todo funciona como cabe esperar, pero al abrir en 2007 las barras de herramienta personalizadas aparecen en el grupo de Complementos junto al resto de grupos predeterminados.

 

Planteamiento:
  • El primer paso fue conocer cómo funciona el XML con el Ribbon (obviaremos en este artículo).
  • El siguiente conocer qué instrucción se usa para activar una cinta de opciones usando VBA:
me.RibbonName = "NombreRibbon". Está en el segundo artículo comentado de Chea aunque la verdad :( lo releí tarde.
  • El tercero, usar dicha instrucción en Access 2003 y ver qué ocurre.
"Error de compilación: No se encontró el método o el dato miembro". Como era de esperar.

Por el error dado se deduce que es una propiedad del formulario en la versión 2007 y la ayuda dice al respecto:

La propiedad RibbonName con el que se obtiene o establece el nombre de la Cinta de opciones personalizada en un formulario o informe...

La duda que se tenía al principio era si hacía falta tener referenciada la librería de Microsoft 12.0 Object Library (mso.dll) para hacer uso del Ribbon y a este nivel de inicio con el Ribbon no es necesario pero simplemente a este nivel NO sirve para nada ya que sin las Acciones (OnAction) los controles son tan memos como los campos memos.

 

Solución:

Ante este error no queda más que buscar un método que podamos usar en 2003 y 2007 para poder compilar y crear un archivo 2003.mde, así que buscando buscando se llega a la siguiente conclusión: un formulario tiene propiedades intrínsecas y propiedades definidas por el usuario y todas ellas las encontramos en la colección Properties, por lo que, si usamos esa colección para referirnos a RibbonName, Access 2007 la reconocerá como una propiedad intrínsica y funcionará en consecuencia, mientras que Access 2003 no la reconocerá, pero la tomará como una propiedad personalizada y no producirá problemas; resumiendo que con la sintaxis Me.Properties.Item("RibbonName") = "NombreRibbon" no se produce error al compilar en 2003 y funciona en 2007.

     If SysCmd(acSysCmdAccessVer) = "12.0" Then
        Me.Properties.Item("RibbonName") = "NombreRibbon"
    Else
        'Usar procedimiento para establecer las barras de herramientas tradicionales.
    End If

Ahora llega lo más serio y es volver a mi desconocido Lenguaje de Marcado Extensible el lenguaje XML y montar de nuevo los comandos.

Se adjunta el ejemplo test.Ribbon2007vsBHP2003 donde se demuestra lo expuesto en este artículo.

En este ejemplo también puedes encontrar los siguientes ejemplos,
  • Como usar la propiedad Información adicional (Tag) de un control de imagen para cuando, al abrir el formulario, se establezca la imagen según una ruta relativa a la aplicación. Es decir, puedes descargar la aplicación en cualquier ruta que al abrir la imagen que está vincula aparece en el control.
  • Al cerrar el formulario de Inicio cómo conocer si la base de datos es MDE, según el valor de la propiedad la aplicación se cerrará o lo hará sólo el formulario.
  • Como conocer la versión comercial, versión interna y versión de compilación del Access que está ejecutando la aplicación.
  • Como crear una Barra de Herramientas Personalizada para versiones de Access 2003 y anteriores por código, incluso con las imágenes icono que están externas a la aplicación. 
McPegasus, 25/04/2008 
Publicado por McPegasus con 2 comment(s)

Magia potagia y ases en la manga I

Este artículo va a resultar un poco raro porque va a contar cosas algo raras que he estado haciendo con Access 2007 y en el mismo orden en que han vagado mis ideas de un lado para otro: ninguno.

Resulta que ando últimamente hechizado por la magia de las consultas a base de una tabla de números consecutivos que combinamos con otra tabla sin establecer relaciones, de manera que el resultado es un producto cartesiano que luego filtramos. Es una técnica conocida pero, en general poco usada ¿Qué pasa si echamos una pastilla efervescente en la clara de huevo? ¿Y si cocemos un huevo en el microondas? ¿Y si me suturo la herida del dedo con Super Glue? Yo soy de los que tienen que probar, aunque ya lo hayan hecho otros, y estas consultas raras me permiten experimentos sin tener que fregar luego la gaseosa derramada. Esta vez me lo he pasado tan bien que tengo que contarlo, como Dominguín después de lo de Ava Gadner.

Usar memos para crear un calendario sin usar casi código

Ya dije que la cosa era un poco rara y, como seguirá siendo rara, empezamos por el final. Éste es el formulario:

 

image

 

Y éste es todo el código:

Option Compare Database
Option Explicit

Private Sub Comando45_Click()
TempVars!AñoInicial = Nz(TempVars!AñoInicial, Year(Date)) + 1
Me.Anyo.Requery
End Sub  

Private Sub Comando46_Click()
TempVars!AñoInicial = Nz(TempVars!AñoInicial, Year(Date)) - 1
Me.Anyo.Requery
End Sub

 

Pero, para hacer esto no necesitaba usar alguna de las cosas raras que he usado. Para lo que las he necesitado ha sido para conseguir esto otro:

 

image

 

Tabla Calendar:

image

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Se trata de crear un informe que presente tantos calendarios mensuales como sean necesarios para mostrar todos los periodos anotados en un conjunto de registros. Y todo el código VBA que necesita es éste:

Option Compare Database
Option Explicit

Private Sub EncabezadoDelGrupo0_Format(Cancel As Integer, FormatCount As Integer)
TempVars!AñoInicial = Me.Anyo.Value
End Sub

Private Sub Report_Close()
TempVars.Remove ("AñoInicial")
End Sub

Private Sub Report_Open(Cancel As Integer)
TempVars!AñoInicial = Year(DMin("Fecha", "qryFestivosVirtuales"))
End Sub

Números y fechas

Una fecha es un número, por lo que si a una serie de números le sumamos una fecha, tenemos una serie de fechas. Podemos añadir campos calculados para mes, año o día de la semana. Hace falta una tabla, que llamaremos Números (sí, con acento, en español) con un campo que llamaremos Número y que llenamos con números consecutivos y que nos va a servir para muchas más cosas. Con sólo esa tabla podemos hacer una consulta así:

SELECT [número]+DateSerial(Year(Date()),Month(Date()),1)-1 AS Fecha, Format([fecha],"dddd") AS Dsemana, (Month([fecha])) AS Mes, (1+(([fecha]-2)\7)) AS Fila
FROM Números;

El resultado es una cosa así:

 

image

 

Nos sale un campo raro que se llama fila y que usaremos más adelante para unos cálculos. Si guardamos esta consulta como "Fechas Virtuales" y sobre ella hacemos una de referencias cruzadas usando el día de la semana como encabezados de columna.

 

TRANSFORM Min([Fechas virtuales].Fecha) AS MínDeFecha
SELECT [Fechas virtuales].Fila, Month([fecha]) AS mes, Year([fecha]) AS Anyo
FROM [Fechas virtuales]
GROUP BY [Fechas virtuales].Fila, Month([fecha]), Year([fecha])
PIVOT [Fechas virtuales].Dsemana In ("lunes","martes","miércoles","jueves","viernes","sábado","domingo");

Obtenemos el siguiente resultado:

image

¡Juer! ¿Y dónde está eso del producto cartesiano? Tranqui, de momento no hace falta, ya lo usaremos luego. Ahora, de momento, vamos a ponerlo en un formulario para que quede más mono:

image

image

 

 

 

La magia y el producto cartesiano (¿Descartes y magia? :-S)

Muy fácil de hacer el calendario, pero no sirve para nada; para eso es mucho más sencillo utilizar un MonthViewer ActiveX. Le faltan las fechas en colores marcando los distintos periodos que tenemos guardados en nuestra tabla Calendar.

Cogemos nuestra tabla:

image 

Abra Cadabra...

 

SELECT [start Time]+[número]-1 AS Fecha, Calendar.ID
FROM Calendar, Numeros
WHERE ((([start Time]+[número]-1)<=[end time]))
ORDER BY [start Time]+[número]-1;

image

Le Voilá!

image

Hemos sacado todas las fechas correspondientes a los periodos de nuestro calendario. Y todavía no hemos escrito una línea de código.

Pero... Si nos fijamos, se trata de un formulario continuo y, si cambiamos el color del texto en un campo de un registro, se cambiará en todos. Podríamos usar formato condicional, pero falla más que una escopeta de feria y, además, iba a ser lento.

Un memo en la manga

Sabemos que los controles que muestran campos memos tienen una propiedad TextFormat que, usando etiquetas HTML permite mostrar el texto en formato de texto enriquecido. Si al cuadro de texto le ponemos como origen un campo de distinto tipo, no admite el formato de texto enriquecido, pero, si usamos un campo calculado, sí que nos lo va a admitir. Vamos, que como no sabe qué tipo de campo es, se porta como un memo.

O sea, que si en un campo calculado con formato de texto enriquecido añadimos las etiquetas correspondientes, se mostrará en rojo (o como nos de la gana si usamos las etiquetas correctas:

<font color=red>" & Día([fecha]) & " </font>

Sólo tenemos que coger nuestra consulta de Fechas Virtuales, combinarla con la consulta de Festivos Virtuales y, donde coincidan ponerle las etiquetas para que luego se muestre en rojo:

SELECT [Copia de Fechas virtuales].*, IIf(Not IsNull([qryFestivosVirtuales].[Fecha]),"<font color=red>" & Day([Copia de Fechas virtuales.fecha]) & " </font>",Day([Copia de Fechas virtuales].[fecha])) AS Expr1
FROM [Copia de Fechas virtuales] LEFT JOIN qryFestivosVirtuales ON [Copia de Fechas virtuales].Fecha = qryFestivosVirtuales.Fecha
ORDER BY IIf(Not IsNull([qryFestivosVirtuales].[Fecha]),"<font color=red>" & Day([Copia de Fechas virtuales.fecha]) & " </font>",Day([Copia de Fechas virtuales].[fecha]));

El resultado, mostraría registros así:

image

 

Con esa consulta creamos una consulta de referencias cruzadas como la que hicimos antes:

TRANSFORM Min(FechasyFestivosVirtuales.Expr1) AS MínDeExpr1
SELECT FechasyFestivosVirtuales.Mes, FechasyFestivosVirtuales.Anyo, FechasyFestivosVirtuales.Fila
FROM FechasyFestivosVirtuales
GROUP BY FechasyFestivosVirtuales.Mes, FechasyFestivosVirtuales.Anyo, FechasyFestivosVirtuales.Fila
PIVOT [FechasyFestivosVirtuales].Dsemana In ("lunes","martes","miércoles","jueves","viernes","sábado","domingo");

Y hacemos con ella el origen de un formulario calendario como el que teníamos antes, pero los controles originales (en amarillo), los ocultamos y añadimos unos campos calculados que tengan su origen en ellos y cuyo formato de texto sea Texto enriquecido.

image

 

Después de tapar los controles invisibles con los nuevos controles calculados y reajustar los tamaños, nos queda una cosa así:

image

Que, cuando usemos como subformulario, al vincular por meses con el formulario principal, nos mostrará sólo los días de cada mes.

De la misma manera, podríamos haber construido un subinforme. Ya sólo queda insertar suficientes subformularios o subinformes para que cubran todo el periodo.

Pero ¿Hasta qué fecha? ¿Tendremos números suficientes? ¿Cómo seleccionamos las fechas? ¿Dónde co...o están esas líneas de código? ¿A dónde iba Dominguín a las siete de la mañana?

La respuesta en el próximo capítulo.

Publicado por Chea con 7 comment(s)

Plantillas de tablas y plantillas de Sharepoint en Access 2007

Este artículo es continuación del anterior y fue publicado en El rincón del experto en febrero.

En Access 2007 disponemos de una serie de plantillas para crear tablas específicas con todos sus campos con sólo un par clics de ratón. También disponemos de plantillas para crear directamente listas de Sharepoint de la misma manera. Si nos fijamos, comprobamos que ambas listas de plantillas coinciden casi por completo y, como veremos más adelante, no se trata de pura coincidencia; también veremos que usar las plantillas nos proporciona más funcionalidades que la simple creación automática de una tabla

image image

WSSTemplateID y WSSFieldID

Ya nos habíamos fijado en un artículo anterior en que, al crear una tabla usando la plantilla de "Contactos", tenemos la posibilidad de añadir funcionalidades de importar o exportar desde "Contactos" de Outlook utilizando los comandos acCmdAddFromOutlook y acCmdSaveAsOutlookContact o las macros equivalentes. También habíamos visto que la tabla tenía una propiedad WSSTemplateID con valor 105 y que casi cada campo de la tabla tenía una propiedad WSSFieldID indicando con qué campo de la plantilla se corresponde; las tablas creadas con la plantilla tienen esas propiedades pero también se las podemos asignar usando VBA a las tablas que queramos y obtendremos el mismo resultado.

¿Ocurrirá lo mismo con el resto de las plantillas? Podemos probar.

Podemos crear una tabla usando la plantilla "Eventos" y, luego, comprobar sus propiedades WSSTemplateID y WSSFieldID utilizando el siguiente código:

Public Function fPropCampos(Tabla As String) As String
Dim i As Integer
Debug.Print "Plantilla: " & CurrentDb.TableDefs(Tabla).Properties("WSSTemplateID")

For i = 0 To CurrentDb.TableDefs(Tabla).Fields.Count - 1
    On Error Resume Next
    Debug.Print CurrentDb.TableDefs(Tabla).Fields(i).Properties("WSSFieldID")
    Err.Clear
Next i

End Function

Llamando a la función pasando el nombre de la tabla, obtenemos en la ventana de inmediato la siguiente relación:

Plantilla: 106
Title
EventDate
EndDate
Location
Description
Attachments

Es decir, que sí que existen esas propiedades en las demás plantillas de tabla, pero ¿Para qué sirven? El prefijo WSS del nombre de las propiedades nos da una pista: Se refieren a Windows Sharepoint Services; o sea, que son plantillas e ID de campo de Sharepoint. Más adelante probaremos a crear una lista de Sharepoint usando las plantillas y veremos que, al importarla, tiene las mismas propiedades que la tabla que hemos creado en Access más alguna otra específica de Sharepoint, pero, de momento vamos a centrarnos en para qué sirven estas propiedades en la tabla que hemos creado en Access.

Cabe pensar que, lo mismo que pasa con los contactos, podríamos exportar/importar datos de nuestra tabla de eventos o de tareas a su equivalente de Outlook, pero de momento no es así. Esperemos que en futuras versiones lo contemplen.

 

Probar nuestra tabla en Sharepoint

Sin embargo, si disponemos de un servidor Sharepoint, sí que le podemos encontrar alguna utilidad. Exportar nuestra tabla es bastante sencillo

image

Sólo hay que elegir la opción correspondiente en la opción "Lista de Sharepoint", del grupo "Datos externos" de la cinta de opciones, o, aún más sencillo, usando el menú contextual que aparece al pulsar con el botón derecho del ratón sobre la tabla que queremos exportar, como se muestra en la imagen superior. Luego sólo hay que indicarle al asistente en que sitio de Sharepoint queremos ubicar la lista.

image

 

Al abrir la lista que hemos creado al exportar nuestra tabla, vemos que Sharepoint la ha tratado de una manera especial: Ha reconocido que se trata de un calendario y nos la muestra en una vista que recuerda mucho al calendario de Outlook.

 image

 

Conectar con Outlook

¿De Outlook hemos dicho? Vaya, si parece que se pone interesante... Vemos que entre las posibles acciones tenemos la de conectar con Outlook. Pues probemos:

image

Al seleccionar la opción, el asistente nos abre Outlook y nos pregunta si queremos conectar el calendario

image

Naturalemente, decimos que sí y !Eureka! ya tenemos nuestro calendario añadido en Outook, y vamos a probarlo ahora mismo añadiendo una cita

image

Después de refrescar nuestra ventana de Sharepoint, comprobamos que la cita que acabamos de escribir en Outlook ya es visible desde Sharepoint

 

image

Es decir, que podemos tener sincronizado nuestro calendario de Outlook con el de Sharepoint. Pero estábamos hablando de Access ¿Está sincronizado el calendario con nuestra tabla de Access? Evidentemente, no, puesto que hemos exportado la tabla, de manera que nuestra BD no guarda ninguna relación con la lista de Sharepoint, pero podemos probar a vincularla y es lo que vamos a hacer.

 

Vincular la lista de Sharepoint a Access 2007

Borramos la tabla Eventos de nuestra de BD de Access y vinculamos la lista de Sharepoint que estamos manejando. Con los asistentes es muy fácil.

image

 

 

image 

 

Al abrir la tabla vinculada, vemos que ya está nuestra anotación y, además, vamos a probar a meter otra

image

En Sharepoint los cambios se reflejan en cuanto refrescamos la ventana

image

¿Y en Outlook? ¡También! Le voilá!

image

Aún hay más. En Outlook, podemos, por ejemplo, poner alarmas y en Sharepoint hacer que se nos notifique por correo electrónico cada vez que nuestra lista cambie y, como la tenemos vinculadas desde Access, significa que modificando la tabla eventos desde Access, se generarán alarmas en Outlook y se enviará un correo avisando desde Sharepoint.

 image

Otras plantillas

De manera parecida ocurre si en, vez de Eventos, hubiéramos exportado Tareas. Sharepoint la habría tratado de una forma especial, con una vista específica, y podríamos haberla conectado con las tareas de Outlook. Con otras plantillas, aunque no tengan conectividad con Outlook, siguen teniendo un tratamiento específico en Sharepoint, puesto que precisamente se trata de eso, de plantillas de Sharepoint, para las que esta aplicación tiene preparadas vistas específicas.

Más plantillas de Sharepoint

Las plantillas de Sharepoint no se limitan a las que se muestran en los desplegables de Access 2007. Cuando creamos una lista desde el sitio de Sharepoint tenemos bastante más posibilidades y, si las exportamos a Access 2007 y comprobamos sus propiedades como hacíamos al principio, vemos que todas ellas tienen sus propiedades WSSTemplateID y WSSFieldID. He aquí unas cuantas plantillas de Sharepoint con el valor de su WSSTemplateID

WSSTemplateID Template
100 Custom List
101 Document Library
102 Survey
103 Links
104 Announcements
105 Contacts
106 Events
107 Tasks
108 Discussion Boards
109 Picture Library
112 User Information
115 Form Library
119 Wiki Page Library
120 Custom List in DataSheet View
150 Project Tasks
1100 Issue Tracking

Algunas de ellas coinciden con nuestras plantillas de Access, pero si las creamos en Sharepoint y probamos a importarlas, podemos comprobar que tienen algunos campos más.

La mayoría de esos campos adicionales son de uso interno de Sharepoint y no son necesarios en Access; es más, si comprobamos la lista de "Eventos" que antes hemos creado en Access, exportado a Sharepoint y luego vuelta a vincular a Access, vemos que tiene más campos que los originales, sin que hayamos tenido que intervenir, lo cual nos tranquiliza: Aunque nuestras tablas en Access no incluyan esos campos, ya los creará Sharepoint cuando los necesite.

Si, desde una tabla importado de una lista, creamos un formulario automáticamente, veremos que la mayoría de esos campos adicionales no se muestran en el formulario. La explicación está en que tienen otra propiedad, más: ColumnHidden = True.

Hay otros campos que no coinciden y que sí que se muestran al crear el formulario. Se trata de campos que no son de uso interno pero que en Access tienen menos funcionalidad, por ejemplo, porque no existe una herramienta para mostrar el calendario de eventos.

 

Conclusiones

Las plantillas de tablas de Access son algo más que simples asistentes para crear unas pocas tablas: añaden a estas tablas una serie de propiedades que serán útiles para integrarlas con otras aplicaciones y nos dan pistas para una mayor integración en el futuro.

Hay que empezar a conocer Sharepoint. Por un lado, se está convirtiendo en eje de la integración entre las distintas aplicaciones de Office, por otro, como back end de Access añade a esta aplicación posibilidades antes impensables.

Publicado por Chea con 2 comment(s)

Contactos de Outlook en Access 2007

Para que la Evas no tenga razón cuando nos achaca que nos prodigamos poco, copio aquí el artículo que publique en El Rincón del experto en enero.

En Access 2007 es muy fácil añadir un botón a un formulario para que se puedan agregar contactos desde Outlook o guardar el registro de nuestro formulario como un contacto de Outlook. Basta con sólo seguir unos pasos.

Generar la tabla

La tabla que usemos para los contactos tiene que tener unas características concretas.

Sin entrar ahora en detalle de cuáles son éstas, la forma más sencilla de conseguirlo es crear la tabla usando la plantilla “Contactos” en “Plantillas de tabla”, en la pestaña “Crear”, grupo “Tablas” de la cinta de opciones.

clip_image002

Generar el formulario

La tabla se genera automáticamente con todos los campos necesarios.  Guardamos la tabla como “Contactos” y, pulsando directamente en la opción “Formulario”,  también de la pestaña “Crear”, se genera, sin más, un formulario de “Contactos” completo

clip_image004

clip_image006

Generar el código

Ahora debemos crear el código para interactuar con Outlook. De momento, nos centraremos en “Agregar contacto desde Outlook” y luego no habrá más que repetir el proceso para “Guardar como contacto de Outlook”

clip_image008

Pasamos el formulario a la vista “Diseño” y añadimos un botón. Se abrirá la ventana del asistente, pero en esta ocasión no nos sirve de mucho; mejor establecemos las propiedades manualmente.

clip_image010

Le cambiamos el nombre, las propiedades “Título”, “Organización de pies de imagen”, “Imagen” y estilo del fondo para que quede más bonito.

El código irá en el evento clic del botón.

Usar un procedimiento de evento

clip_image012

En la propiedad del botón “Al hacer clic” podemos poner [Procedimiento de evento] y luego en el editor de VBA,  crear un procedimiento como éste:

Private Sub btnAgregarOutlook_Click()

    DoCmd.RunCommand acCmdAddFromOutlook

End Sub

Usar una macro

El código es tan sencillo, una única línea de código, que parece que no merece la pena usar una macro en su lugar. Sin embargo, una macro incrustada es una buena alternativa, pues en lo sucesivo, al copiar y pegar nuestro botón, también se copia y pega la macro que lleva inrustada.

Si, en vez de seleccionar [procedimiento de evento] en la propiedad “Al hacer clic”, pulsamos sobre el botón con los tres puntos que aparece a la derecha y elegimos el Generador de macros”, sólo tenemos que elegir la acción “Agregar comando” y el comando “Agregar desde Outlook” para crear una macro incrustada que consiga el mismo efecto que con el código DoCmd.RunCommand acCmdAddFromOutlook

Es decir, que para agregar un contacto desde Outlook podemos utilizar el código

·        DoCmd.RunCommand acCmdAddFromOutlook

O la macro

  • EjecutarComando AgregarDesdeOutlook

Probar la aplicación

Ya sólo nos queda probar. Pasamos a vista formulario, presionamos el botón y Voilá!

clip_image014

Podemos repetir los mismos pasos para el botón “Guardar como contacto de Outlook”, sabiendo que en este caso el código sería:     

  • DoCmd.RunCommand acCmdSaveAsOutlookContact

Y la macro:

  • EjecutarComando GuardarComoContactoDeOutlook

Probar con una tabla distinta

Quizás queramos usar como contactos una tabla que no hayamos generado con la plantilla, por ejemplo, porque estamos aprovechando una aplicación o unos datos antiguos. Si hemos usado una macro, no tenemos más que copiar y pegar los botones en el viejo formulario y, si lo hemos hecho con código, tendremos además que crear el código de los eventos.

Es muy sencillo y en un instante ya lo estamos probando, y… ¡No funciona!

¿Qué está ocurriendo?

Ya habíamos comentado que la tabla debe tener una características concretas que la plantilla nos las daba hechas.

De alguna forma debemos decirle a Outlook qué campos de nuestra tabla se corresponde con cada uno de su plantilla. La forma de hacerlo es creando o modificando para esa tabla la propiedad WSSTemplateID de manera que tenga el valor 105 y, para cada uno de los campos que lo precisen,  la propiedad WSSFieldID de manera que indique con qué campo de la plantilla se corresponde.

En el Access Team Blog explican cómo modificar esas propiedades y en mi página hay un complemento para hacerlo fácilmente.

Estas propiedades sirven para más tipos de plantillas que la de contactos. Si su nombre empieza por WSS es porque hacen referencia a plantillas de SharePoint y les vamos a encontrar especial utilidad en este entorno, pero todo eso es ya materia suficiente para tratar en un artículo aparte.

Publicado por Chea con 2 comment(s)
Archivado en:

¡Por fin la Runtime de Access 2007 en español!

Se ve que las figuras del Access Team Blog, que son los que suelen hacer estos anuncios, se ha ido de fin de semana antes que el currito encargado de poner las actualizaciones en la web de descargas, pero un avispado usuario de los grupos de noticias de Access en español, "Ceac", ha observado que ya está disponible la versión en español y nos ha dado el aviso.

Podemos descargarla en https://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=d9ae78d9-9dc6-4b38-9fa6-2c745a175aed

Publicado por Chea con no comments
Más artículos Página siguiente >