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 problema, como digo, no es complicado. Por una parte, acceder al portapapeles es muy sencillo, mediante My.Computer.Clipboard y hay varios métodos para extraer su contenido según lo que contenga. En este caso (la copia de texto) usaremos el método GetText, que nos devuelve un String. El dónde gestionar esto ya queda a gusto del consumidor pero, para mí, lo más fácil es añadir un menú contextual con el habitual atajo de teclado (Ctrl + V).

El siguiente paso es tratar ese texto. Cualquier colección de celdas de Excel es copiada al portapapeles como un conjunto de valores separados por tabulación. El otro día mostraba el uso de la clase TextFieldParser para procesar ficheros de texto que nos viene como anillo al dedo. Bueno, casi, porque al TextFieldParser no le podemos pasar un String, está pensado para procesar ficheros. Si vemos sus constructores, a uno se le pasa la ruta de un fichero, a otro un Stream, precisamente para tratar con un fichero, y a la tercera sobrecarga, un TextReader.

¿Qué es un TextReader (era la primera vez que lo veía)? Según la biblioteca de MSDN, TextReader es la clase abstracta de StreamReader (éste si lo conocía) y StringReader. Éste último tiene en su nombre la palabra mágica, String, así que merece la pena echar un ojo. Me da igual los tutoriales que nos puedan aparecer ni los mil usos que tenga StringReader. Para el caso que nos ocupa, todo se reduce a crear un StringReader a partir del texto contenido en el portapapeles:

Dim miTexto As StringReader

miTexto = New StringReader(My.Computer.Clipboard.GetText)

Y pasarle ese StringReader a un TextFieldParser, con lo que estamos casi, casi, en el mismo caso del ejemplo de TextFieldParser. Ya podemos trabajar de forma simple con el texto del portapapeles. Sólo hay que añadir los controles de errores necesarios y decidir qué vamos a hacer con cada fila válida devuelta por el TextFieldParser. Siguiendo la lógica del título de esta entrada, pasárselas al DataGridView, pero tengo que confesar que no lo hice así. La razón es muy simple: me interesaba más pasárselo directamente al origen de datos del DataGridView.

Para mi caso concreto (Origen de datos + BindingSource + DataGridView), antes de iniciar el proceso de lectura de TextFieldParser, llamé al CancelEdit del BindingSource para evitar la posibilidad de que se generase una fila en blanco o no válida (si se da el caso, se saltaría la validación de datos) y le quité también la referencia al DataSource:

Me.bsArticulos.CancelEdit()

Me.bsArticulos.DataSource = “”

Después de añadir los valores del portapapeles al origen de datos, se vuelve a enlazar el BindingSource con éste y listo. Bueno, vale, no he pegado realmente en el DataGridView. Espero que nadie se sienta estafado.

Nos vemos en el Forlon.

Y fíjese usted por donde, encontré una forma más simple de hacer las cosas que no conocía: usando la clase TextFieldParser.

En la forma más fácil, le pasamos en el constructor la ruta del archivo a tratar. Le indicamos luego qué es, si de ancho fijo (FixedWith) o separado por carácter (Delimited) con la propiedad TextFieldType. Si es el segundo caso, con el método SetDelimiters indicamos el delimitador (por ejemplo, MiTfp.SetDelimiters(vbTab) para indicar campos separados por una tabulación).

En el primero, indicaríamos el ancho de los campos mediante una lista de enteros que le pasamos al método SetFieldWiths: MiTfp.SetFieldWiths(2, 3, 12, 85, 5).

Para leer cada línea tenemos el método ReadFields, que nos devuelve un array de cadenas con cada campo de la línea del fichero en la posición correspondiente del array. Se tarda más en explicar que en hacer.

Hay un pequeño problema adicional: la codificación de caracteres. Por defecto, se usa UTF8. Ahora mismo no recuerdo si Vista y 7 usan UTF8 por defecto, pero XP y versiones anteriores de Windows, no, y podemos encontrarnos con problemas con algunos caracteres, como ñ, tildes, etc. En ese caso, seguramente estemos usando Windows occidental (Windows 1252) o, más raramente, ISO-8859-1. Podemos indicarle esto al TextFieldParser en el constructor, pasándole el código de la página de códigos a emplear:

Dim MiTfp as New TextFieldParser(MiRuta, System.Text.Encoding.GetEncoding(1252))

Lo más largo, como siempre, es el control de errores, o el propio tratamiento de los valores que hayamos leído, pero el hecho de leer en sí más simple no puede ser.

Si nosotros queremos usar este sistema con controles que estén dentro de un DataRepeater… En fin, probadlo si queréis, pero ya os digo que la aplicación se quedará muerta si mandáis el foco a un control que esté fuera del DataRepeater. ¿Entonces?

Pues no salgamos. Pasemos el foco al ítem del DataRepeater al que pertenezca el control y listo:

MiDataRepeater.CurrentItem.Select()

El control DataRepeater es más versátil que el habitual DataGridView, pero es caprichoso como él solo.

Lo primero ha sido elegir el algoritmo de ordenación. Como van a ser pocos elementos, me he tirado a los sencillitos y, de estos, al de inserción, que es el único que soy capaz de desarrollar sin mirar la chuleta (el de la burbuja lo tengo atravesado). El proceso es muy simple: vamos ordenando por el primer valor. Si este es igual, pasamos a ordenar por el segundo valor. En este caso concreto, ordenamos por largo (primer valor) y si son iguales, por ancho. Para ello, lo primero que he hecho ha sido crearme dos funciones que me devuelvan el largo o el ancho a partir de la cadena:

Private Function ValorNumL(ByVal Resolucion As String) As Integer
    Dim pos As Integer
    pos = Resolucion.ToLower.IndexOf("x"c)
    If pos = -1 Then
        ValorNumL = 0
    Else
        Try
            ValorNumL = CInt(Strings.Left(Resolucion, pos))
        Catch ex As Exception
            ValorNumL = 0
        End Try
    End If
    Return ValorNumL
End Function
Private Function ValorNumA(ByVal Resolucion As String) As Integer
    Dim pos As Integer
    pos = Resolucion.ToLower.IndexOf("x"c)
    If pos = -1 Then
        ValorNumA = 0
    Else
        Try
            ValorNumA = CInt(Strings.Right(Resolucion, _
                            Resolucion.Length - (pos + 1)))
        Catch ex As Exception
            ValorNumA = 0
        End Try
    End If
    Return ValorNumA
End Function

Lo siguiente, implementar la búsqueda. Parto de una List(of IdMasDescripcion) de nombre Resoluciones, donde IdMasDescripcion es una clase que tiene una propiedad, Descripcion, de tipo String, que es por la que vamos a ordenar.

Dim i, j, ElementoLargo, ElementoAncho, jLargo, jAncho As Integer
Dim Elemento As IdMasDescripcion
Dim Menor As Boolean = False
For i = 1 To Resoluciones.Count - 1
    Elemento = Resoluciones(i)
    ElementoLargo = ValorNumL(Elemento.Descripcion)
    ElementoAncho = ValorNumA(Elemento.Descripcion)
    j = i - 1
    Do
        '1) Comparamos primero el largo(lado izdo):
        jLargo = ValorNumL(Resoluciones(j).Descripcion)
        If jLargo > ElementoLargo Then
            Resoluciones(j + 1) = Resoluciones(j)
            j = j - 1
            Menor = False
        ElseIf jLargo = ElementoLargo Then
            'Si son iguales, ordenamos por el ancho
            jAncho = ValorNumA(Resoluciones(j).Descripcion)
            If jancho > ElementoAncho Then
                Resoluciones(j + 1) = Resoluciones(j)
                j = j - 1
                Menor = False
            Else
                Menor = True
            End If
        Else
            Menor = True
        End If
    Loop Until j < 0 OrElse Menor
    Resoluciones(j + 1) = Elemento
Next

Una de estas funciones, o funcionalidades, si lo preferís para no confundirlo con functions, es la de mantener actualizados una serie de comboboxes que hay en el formulario principal de las series. Estos comboboxes contienen los datos de una serie de tablas de la base de datos que se caracterizan por tener pocos datos: el formato de archivo, la resolución, el códec de vídeo… En otras circunstancias, los rellenaría usando mi clase RellenarCombo, pero aquí se me presenta un problema curioso: como podéis ver en la imagen, hay una buena cantidad de comboboxes (una docena o así) que se corresponden a una serie de campos de las Releases (versiones) de una serie. El formulario muestra conjuntamente las series y sus releases, estando en la parte superior los datos de la serie y en la inferior, en cero o más pestañas los datos de las releases. O sea, tengo una docena de combos por cada pestaña.

Aquí empezaron mis problemas: ¿cómo rellenar esos combos y mantenerlos actualizados?

Lo primero que pensé fue no utilizar combos. En lugar de traerme los datos de las Releases (tabla) y ligarlos al ValueMember de cada combo, podía crearme una consulta que englobara la tabla de Releases y las tablas relacionadas. A la hora de modificar datos sí tendría que mostrar los combos y trabajar con la tabla de Releases, lo que me añadiría bastante complicación al código. Este sistema, más o menos, es el que estoy siguiendo en una aplicación para fábrica donde la modificación de los datos será mínima.

Otra opción era rellenar cada combo por su cuenta. En principio, lo normal sería tener sólo una release por serie, esto es, una pestaña, siendo tres o cuatro el número máximo. Así pues, podría hacer la carga del combo, digamos, de Tipo de archivo, una vez para cada pestaña. Esto no me gustaba por varias razones: la primera es la redundancia de datos en memoria. Si tengo tres veces el mismo ComboBox en el formulario (en tres pestañas) he cargado tres datatables para ligarlas a estos combos. La segunda es que a la hora de mantener esos datos actualizados (por ejemplo, si añado un nuevo tipo de archivo) tendría que comprobar cuántas pestañas hay y volver a cargar cada tabla ligada a cada combobox. Si tengo tres pestañas, el trabajo por tres. Y la tercera y más importante: no me parecía elegante.

Así que opté por cargar todos esos datos en memoria y que los combos de las distintas pestañas, independientemente de cuántas pestañas hubiera, se sirvieran de ellos. Como mucho, unos doscientos registros formados por dos campos: un valor numérico (clave primaria, a ligar al ValueMember) y una cadena de caracteres (el campo descriptor que se mostrará en el combo). Para trabajar con ello creé una clase muy sencilla que contuviera esos valores. En su forma más simple:

Public Class IdMasDescripcion
    Private _Id As Integer
    Private _Descripcion As String
    Public Sub New(ByVal Id As Integer, _
                   ByVal Descripcion As String)
        _Id = Id
        _Descripcion = Descripcion
    End Sub
    Public Sub New()

    End Sub
    Public Property Id() As Integer
        Get
            Return _Id
        End Get
        Set(ByVal value As Integer)
            _Id = value
        End Set
    End Property
    Public Property Descripcion() As String
        Get
            Return _Descripcion
        End Get
        Set(ByVal value As String)
            _Descripcion = value
        End Set
    End Property
End Class

Luego me declaré una serie de colecciones de IdMasDescripcion, digamos que unas List (of IdMasDescripcion). Al arrancar la aplicación y realizar la carga de datos, rellenos estas colecciones con los datos de las tablas respectivas. Luego, en el procedimiento que controla las pestañas, cuando se crea una, ligo cada colección a su ComboBox correspondiente (mediante su DataSource, etc.) y listo.

Bueno, listo, no. Ahora viene controlar que se muestren los datos actualizados en esos combos. Si, digamos, yo añado un nuevo tipo de archivo, la aplicación lo detecta y vuelve a rellenar la List(of T) correspondiente a esta tabla, los combos ya existentes no muestran los cambios. Oh, vaya.

La solución es muy simple: la colección elegida no es la adecuada para esto. Si cambiamos la List(of T) por una BindingList(of T), problema solucionado.

En resumen: vuelco los datos que necesito de una tabla de la base de datos a una BindingList. Enlazo todos los comboboxes que vayan a mostrar esos datos (uno por pestaña, vaya) a la BindingList y puedo mantenerlos todos actualizados para cuando vaya a modificar una release. Ahora que lo veo así, resulta evidente, pero en su momento me llevó bastante caer en ello.

No me da tiempo a más. Si alguien quiere que ponga el código completo (aunque no es nada del otro mundo, la verdad), pues me lo pide y lo subo en cuanto pueda.

Nos vemos en el Forlon.

Respecto a las clases, no estoy contento. Sólo he tenido un mes, el peor del curso (2º de un FP superior son dos trimestres, así que los finales han sido ahora), así que ha tocado jugar a la defensiva, a verlas venir. Me hubiera gustado tener más tiempo para darle un buen tute a lo básico, pero hubo que entrar directamente con arrays de estructuras. La verdad es que los puñeteros arrays son un fastidio; ya me había acostumbrado a otras colecciones y volver a lo básico duele. Y más si no se puede tirar de ICompare para ordenar, o propiedades para enlazar a los controles me ha exigido pensar mucho. No poder usar el ValueMember y el DisplayMember de un ComboBox o ListBox por no poder definir unas Property en la estructura, para mí, que abuso de eso precisamente, ha sido definitivamente exasperante.

Al final, un mes a carajo sacado, mucho array y mucha base de datos y sin tiempo para explicar las cosas como me gustaría. Sólo espero que las horas les hayan sido de provecho y tengan suerte.

Por otra parte, he empezado con WPF y no me entero de ná. Mi reino por un buen libro al respecto, pero no encuentro ninguno. En fin, con paciencia.

La situación es la siguiente: tengo un formulario base, a modo de plantilla, que lo uso cuando tengo acceso a datos. Tiene una serie de controles y métodos entre los que se encuentra un MenuStrip con varios ToolStripMenuItem. Es un control (él y sus ítems) que da problemas con el diseñador de formularios de Visual Studio cuando es un control heredado. Aparece como de sólo lectura y no nos deja trabajar con él y lo digo en serio: no podemos añadir elementos al menú en vista diseño, ni cambiar ninguna propiedad (ni siquiera el texto mostrado) de los ítems que ya tenga. Tenemos que hacerlo directamente en código. Lo que es más incómodo: no podemos controlar un evento de un elemento ya existente.

Me explico: tenemos un ToolStripMenuItem llamado mnuNuevo y declarado como Protected en el formulario plantilla y tengo mi formulario heredado (HijoMioForm). Si en HijoMioForm se me ocurre hacer algo como:

Private Sub mnuNuevo_Click() Handles mnuNuevo.Click

El programa compilará y funcionará, pero nos podemos olvidar del diseñador de formularios: cascará irremediablemente. Después de buscar soluciones a este problema por ahí (he leído bastantes quejas sobre este caso y otros similares), lo que hice fue declarar el dichoso método en la plantilla como Overridable y luego redefinirlo en HijoMioForm:

Protected Overridable Sub mnuNuevo_Click() Handles mnuNuevo.Click

Y

Protected Overrides Sub mnuNuevo_Click()

Vale, que no cunda el pánico. Pensemos. O cubro bien todas las posibilidades o me curo en salud y no le dejo tocar al usuario donde no deba. Como soy alumno de mi profe, he optado por lo segundo. Así que quiero que cuando el luser quiera modificar o dar de alta “algo” en uno de los formularios, todos los demás se hagan los suecos (disabled). Pregunta: ¿cómo lo hago?

Bien, resulta que, ¡oh, casualidad!, casi todos los formularios derivan de un formulario plantilla (cuestión de vagancia), así que se me ocurrió usar un evento compartido en la clase base. El evento se provocará cada vez que cambie el “estado” del formulario, por ejemplo, al pulsar el botón de Nuevo o el de Aceptar. Necesito también saber, cuando salte el evento, si ha sido porque he entrado en un modo “modificar datos” o en un modo “ver datos”, así que necesito un argumento booleano que me lo controle. Vale, al trabajo.

Empezamos definiendo el tipo de argumentos para el evento. He dicho que necesito un booleano, pero para hacerlo “según las normas” he definido una clase ModificandoEventArgs que hereda de EventArgs y que, de momento, lo único que tiene importante es una propiedad booleana.

Public Class ModificandoEventArgs
    Inherits EventArgs
    Private _EstoyModificando As Boolean

    Public Sub New(ByVal estamosModificando As Boolean)
        Me._EstoyModificando = estamosModificando
    End Sub

    Public ReadOnly Property EstamosModificando() As Boolean
        Get
            Return Me._EstoyModificando
        End Get
    End Property
End Class

Luego declaramos el delegado:

Public Delegate Sub ModificandoEventHandler(ByVal sender As Object, _
    ByVal e As ModificandoEventArgs)

Y, ya por fin, el evento y el método que lo lanza:

Public Shared Event Modificando As ModificandoEventHandler

Protected Overridable Sub OnModificando(ByVal e As ModificandoEventArgs)
    RaiseEvent Modificando(Me, e)
End Sub

Ya de paso me creo un método para gestionar este evento dentro de la clase base, a ver qué pasa.

Protected Overridable Sub EstamosModificando(ByVal sender As Object, _
    ByVal e As ModificandoEventArgs) Handles Me.Modificando
    If sender IsNot Me Then
        Me.Enabled = Not e.EstamosModificando
    End If
End Sub

Ya está. ¡Ah, no! Falta lanzar el evento. Pues nada, llamadita a OnModificando desde el lugar apropiado, concretamente desde el método PrepararForm que se ejecuta en cada cambio de estado del formulario. Y funciona. A la primera. Ya no me acuerdo cuándo fue la última vez que me funcionó algo a la primera.

Pues tiene su aquél. Bueno, vale, no tiene mucho “aquél” pero me ha costado un buen rato dar con la tecla. O sea, sacar el elemento, borrarlo, insertarlo en su nueva posición. Ahora mismo no estoy seguro, pero creo haber hecho algo parecido en VB6 sin necesidad de dar tantos pasos. Por ejemplo, el código del click del botón de subir quedaría más o menos así:

Dim MiMecanizado As MecanizadoPieza Dim i As Integer = Me.lstOrdenMecanizado.SelectedIndex If i > 0 Then MiMecanizado = TryCast(Me.lstOrdenMecanizado.SelectedItem, _ MecanizadoPieza) If MiMecanizado Is Nothing Then Exit Sub Me.lstOrdenMecanizado.Items.RemoveAt(i) Me.lstOrdenMecanizado.Items.Insert(i - 1, MiMecanizado) Me.lstOrdenMecanizado.SelectedIndex = i - 1 End If

Donde MecanizadoPieza es una clase que incluye un campo Descripción (DisplayMember) y un campo Id (ValueMember) y lstOrdenMecanizado es el listbox de marras.

Si alguien lo encuentra útil, pues mejor.