Que empiezan a marear la perdiz. Lo suficiente como para que la promoción caduque y se retire dicha opción del programa. Dado lo que sé del programa, me imagino una subcontrata con becarios y picacódigos con poca experiencia, mal pagados y echando horas a manta, con una motivación por los suelos y una productividad e interés por hacer bien su trabajo en consonancia (modificada a la baja por la falta de respeto que puedan recibir de sus jefes). Ante la queja del usuario y para dos días que faltan del tema, que le den a él y a su cliente. Y luego, todos, así te las apañes con tu cliente, que no es problema nuestro.

Da gusto ver el trabajo de uno en funcionamiento y que los usuarios lo acepten y usen.

—Ya lo haré yo el lunes.

Los viernes son terroríficos. Siempre pasa algo. Que además de viernes sea el día en que sensei empieza vacaciones es tentar al diablo, así que senpai y yo estábamos con la mosca detrás de la oreja y esperando… Esperando…

A media mañana, el caos: los usuarios avisan de que no pueden entrar en SAP. Donde-sale-el-sol ha desaparecido del mapa. Y bien desaparecido: no responde ni por MPLS ni por ADSL. ¡Ni siquiera por teléfono! ¡Un meteorito ha arrasado la fábrica! ¡Nos invaden los extraterrestres!

La cara de sensei, al móvil, mientras le van dando partes, es todo un poema. Un lumbreras de mantenimiento, sin avisar, se ha puesto a hacer pruebas con las líneas eléctricas. Como resultado, ha tumbado la luz en la fábrica.

—No lo entiendo. No debería haber pasado.

Y la línea de los SAIs. Y con ella, los routers, los switches, el MPLS, la centralita… y todos y cada uno de los servidores.

—Pero si no debería haber pasado nada.

Y mientras intentábamos arrancar todo y lo chequeábamos, yo iba haciendo mentalmente la lista de cosas que necesitaba para un fin de semana de trabajo no planeado, por si las moscas. E incluía una escopeta.

Ya, claro.

Pero había cuatro vistas de esas tablas. Y luego procedimientos almacenados sobre esas vistas y esas tablas. Que eran llamados por los tableadapters de cinco datasets tipados, que los usaban para trabajar con esas vistas y esas tablas. Una docena de tableadapters, más o menos. Muchos métodos llamados (por fortuna) desde unos pocos sitios bien controlados.

Un horror de día.

Resumiendo: si buscamos ayuda sobre cómo hacer un enlace de datos simple en nuestro control personalizado, nos dicen que usemos <BindableAttribute(True)>:

<BindableAttribute(True)>
Public Property IdAccion As Integer

Pero resulta que, con sólo eso, el BindingSource supone que siempre cambian los valores enlazados y actualiza el origen de datos. Resulta que además debemos implementar la interface INotifyPropertyChanged y notificar cuándo cambia el valor, tal que de esta forma:

<BindableAttribute(True)>
Public Property IdAccion As Integer
    Get
        Return Me._IdAccion
    End Get
    Set(value As Integer)
        If _IdAccion <> value Then
            Me._IdAccion = value
            RaiseEvent PropertyChanged(Me, _
                    New PropertyChangedEventArgs("IdAccion"))
            Me._IdAccion = value
        End If
    End Set
End Property

Sigo, eso sí, sin haberlo visto tan bien explicado en la documentación. Menos mal que existen los foros y los blogs.

Pero, ajá, no es la panacea. Ahora me encuentro con que, a veces, el valor no cambia aunque debería. Por ejemplo, al añadir un nuevo registro que tiene (o tendrá) el mismo valor de la propiedad que el anterior. Hay que revisar estos casos con cuidado para, o bien asegurarnos de que cambia el valor de la propiedad o bien provocar a mano el evento cuando lo creamos necesario. En fin, problemas del enlace a datos.

Supongo que la idea de usar datasets tipados con VB2010 teniendo Entity Framework puede parecer rara o anacrónica, pero llevo usando datasets desde 2005 y tirar de ellos me ahorraba un tiempo de aprendizaje que no tenía. Ahora, con 17 datasets tipados (y creciendo) no sé hasta qué punto fue buena idea.

Entendámonos, me gustan porque el asistente es cómodo y puedo personalizarlos rápida y fácilmente. Se han convertido en poderosas (y pesadas, me temo) entidades que se mueven entre la aplicación tanto con los datos como con las órdenes de qué hacer con ellos.

El problema viene cuando tengo que reconfigurar alguno, porque se ha añadido algún campo a la base de datos o, como está pasando estos días, ha habido que hacer cirugía mayor y donde antes tiraban de una tabla ahora lo hacen de una vista. Esa forma de machacarse la configuración de los campos existentes, esos problemas con el AllowDBNull y con los NullValue…

A veces odio los datasets tipados.

Como el proceso era algo largo (mínimo unos diez segundos, pero podía llegar superar el minuto en la versión 2, que admitía de entrada una serie de valores), se me ocurrió usar una barra de progreso para mantener informado al usuario.

Entonces empezaron los problemas.

Todos los ejemplos que he visto que usan el evento ProgressChanged del BackGroundWorker para alimentar una barra de progreso presentan una serie de operaciones en secuencia con llamadas a ProgressChanged entre ellas, es decir: hago paso 1; progreso cambiado; hago paso 2; progreso cambiado… Sin embargo, mi problema era otro: tengo una instancia de mi clase de trabajo, cojo los valores del usuario (a través de DoWorkEventArgs.Argument), se los paso, y le digo “ea, majo. Tú puedes” llamando al método MiClase.HacerCurro. Ahí dentro se harán las n operaciones (recursivas), número desconocido hasta que se hagan.

Vale, pensé. Puedo provocar un evento OperaciónCompletada cada vez que complete una operación. Pero la instancia de MiClase está declarada dentro del DoWork del BackGroundWorker. No tengo acceso desde fuera. ¿Cómo lo hago?

¿Y si meto alguien que escuche en el DoWork? De esta forma tendría mi “escuchador” de eventos en el mismo hilo. Es decir, una clase, digamos Escuchante, a la que le paso mi instancia de MiClase y la del BackGroundWorker. Escuchante gestiona el evento OperacionCompletada provocando a su vez el ProgressChanged, que actualiza la barra de progreso.

No sé si será una solución muy limpia, pero funcionó.

En resumen, algo así:

Public Class Escuchante

Private WithEvents _MiClase as MiClase

Private _MiBGW as BackGroundWorker

Public Sub New(mc as MiClase, bw as BackGroundWorker)

_MiClase=mc

_MiBGW=bw

End Sub

Private Sub OpCompletada(sender as Object, e as OperacionCompletadaEventArgs) _

        Handles _MiClase.OperacionCompletada

_MiBGW.ReportProgress=e.NumOp

End Sub

End Class

El título de la entrada de hoy es una frase lapidaria de mi jefe de departamento cuyo origen hay que buscarlo en un problema de licencias que nos encontramos a principios de año: los puestos de trabajo crecían y faltaban licencias de Microsoft Office (el 2000 teníamos). Teníamos entonces una gran dependencia de Outlook, Excel y Access, pero el precio de las licencias de Office resultaba prohibitivo para todos los puestos que teníamos, así que estudiamos alternativas.

Outlook fue sustituido sin más problemas por Thunderbird + Lightning. Necesitábamos un cliente de correo con calendario y tareas y el pájaro de trueno cumplió con creces. Con Access el problema desapareció por sí solo: había muchos aplicativos en Access que atacaban la base de datos del ERP. Pero este iba a ser sustituido por SAP B1, así que muerto el perro…

El tercer problema era Excel. Probamos tanto OpenOffice.org como LibreOffice como Lotus Symphony. Elegimos finalmente LibreOffice confiando en su futuro frente a OpenOffice.org y tras tener graves problemas de estabilidad con Lotus Symphony. Migramos con ilusión intentando contagiar nuestro entusiasmo para cortar las quejas tontas (tal opción se llama distinta, los botones no son iguales, el desplegable de colores es peor porque es distinto…).

Después de varios desesperantes meses, hubo que claudicar, re-evaluar y adquirir cierto número de licencias para algunos puestos claves. Simplemente, Calc no está a la altura. Tuvimos unos meses de horror, plagados de archivos corruptos al guardar y de pérdida de información (hiperenlaces y vínculos externos). A la hora de buscar cómo migrar ciertos libros de Excel complejos a Calc nos topamos con la falta de documentación, falta de movimiento en los foros oficiales… Cuando llegamos a las tablas dinámicas y las conexiones a SQL Server, tiramos la toalla. Salía más caro intentar usar Calc (tiempo perdido en varios departamentos, falta de información en el momento clave o inconsistencia de la misma) que volver a Excel.

A fin de cuentas, Excel es Dios.

PD: como yo no ocupo un puesto clave, uso Calc. Total, para lo que sé y necesito hacer me basta. Voy más lento de lo que podría ir con Excel 2007-2010 (falta de herramientas, están más ocultas), pero para una vez al mes que lo uso me vale.

Tras una larga búsqueda en internet, casi todo en inglés, averigüé dos cosas: que era un problema común y muy molesto y que no tenía solución fácil. También hallé unas pistas que me indicaron el camino. Un trabajo no muy limpio, pero que funciona, dividido en dos partes: el enlace al control y la datatable correspondiente.

En enlace, usando el diseñador (DataBindings, Avanzado) para asignar un formato de fecha corta, queda así:

Me.txtFecha.DataBindings.Add(New Binding(“Text”, Me.bsDatos, “Fecha”, True, DataSourceUpdateMode.OnValidation, Nothing, “d”))

Donde Nothing representa cómo se van a mostrar los valores nulos de la base de datos, la propiedad NullValue del Binding. Ésa sabemos que funciona bien, nos interesa gestionar el otro sentido de la actualización, hacia el origen de datos. Para ello tenemos la propiedad DataSourceNullValue. Sacamos el enlace del designer y lo gestionamos a mano, creándonos el Binding:

Dim mBinding As New Binding(“Text”, Me.bsDatos, “Fecha”, True, DataSourceUpdateMode.OnValidation, “”, “d”)
mBinding.DataSourceNullValue = Date.MinValue
Me.txtFecha.DataBindings.Add(mBinding)

Primer punto: indicamos que el NullValue para el origen de datos no va a ser DBNull (por defecto y causa de los errores), sino un valor de fecha válido, en este caso el menor valor posible (Date.MinValue).

Segundo punto: cambiamos el Nothing del NullValue por String.Empty o “”. La razón es muy sencilla: NullValue nos indica dos cosas. Por una parte, si (en este caso) la fecha en la DataTable es DBNull, lo representa por lo que le indiquemos ahí. Lo segundo, si el valor de la propiedad del control (Text, en este caso) coincide con el NullValue en un cambio de datos (altas, modificaciones), le pasa al origen de datos (la DataTable) lo que le tengamos dicho en DataSourceNullValue. Y el Nothing ahí no nos vale: si no hay nada en Text, obtenemos una cadena vacía, String.Empty o “”, no un valor Nothing.

Con esto, pues, si dejamos el textbox txtFecha vacío, obtendremos en el campo Fecha de la fila correspondiente un valor fecha igual a Date.MinValue. Que no es lo que queremos: buscamos un DBNull.

Eso lo hacemos en otra parte: gestionando el evento ColumChanging del DataTable. Modo rápido: en el diseñador del dataset tipado hacemos doble click sobre la columna en cuestión y nos genera el código automáticamente. En la gestión del evento incluimos el código para que nos filtre la fecha y si es igual a Date.MinValue, cambie el valor propuesto del campo a DBNull.value:

If (e.Column.ColumnName = Me.FechaColumn.ColumnName) Then

If IsDate(e.ProposedValue) AndAlso
CDate(e.ProposedValue) = Date.MinValue Then
e.ProposedValue = DBNull.Value

End If
End If

Con esto, ya tenemos nuestro campo fecha que acepta valores nulos. No es muy elegante, quizás, pero no se me ha ocurrido ninguna otra forma.

El problema, apuntaban en varios sitios, se daba en formularios o controles de usuario heredados y estaba causado al gestionar eventos de objetos de alguna de las clases padre con la cláusula Handles en la clase hija. Tras investigar con calma mi usercontrol, encontré que el causante del desaguisado era, efectivamente, una cláusula handles que apuntaba a un evento de un BindingSource del abuelo del usercontrol. Quité el Handles y lo sustituí por un AddHandler en el constructor y todo funciona con suavidad.