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.

Tras pensarlo un poco, he probado a convertir el valor del campo pasado a la instrucción MAX a un tipo Nullable, que acepta valores nulos. En mi caso, como era valores enteros, esa parte de la consulta LINQ quedaría tal que así:

Into Max(Ctype(Fila.Campo, Integer?))

La consulta ya no da error, y sólo nos queda controlar si hay valor devuelto (propiedad HasValue), convertirlo al tipo que queramos (Integer, en el ejemplo) y seguir adelante. Más sencillo se me hace que otras ideas que he visto por ahí, y más rápido.

Como siempre, si a alguien le resulta de utilidad, pues mejor.

Cada ComboBox del UserControl muestra el contenido de otra tabla (sí, son unas cuantas). Podría haber dejado los combos sólo para altas y modificaciones y haber usado una consulta más específica en lugar de traerme la tabla releases a capón, pero aquí no me gustó la idea (en otra aplicación con un problema parecido es lo que hice; claro, que también usaba SQL Server y pude crear una vista). En lugar de eso, aprovechando que todas esas tablas tienen (y tendrán) un pequeño número de registros (menos de veinte), decidí cargar todos esos datos en memoria. Bueno, no todos, sólo la clave primaria y el campo a mostrar en el ComboBox. Para ello hice una clase sencilla y una BindingList personalizada con métodos de ordenación específicos. También una enumeración con todas las tablas.

Junté todo en una colección tipo Dictionary. Sus pares de valores eran el valor de la enumeración (que identifica la tabla) y la BindingList personalizada con el conjunto de datos de la tabla. Ahora sólo queda pasar ese Dictionary a cada UserControl y que éste enlace cada ComboBox a la BindingList correspondiente. ¿Cómo? Pues, por ejemplo, creando otro Dictionary que para cada tabla (valor de la enumeración) tenga el ComboBox correspondiente. Así:

Private _MisCombos As New Dictionary(Of enTablas, ComboBox)

Y en el constructor del UserControl:

With _MisCombos
    .Add(enTablas.Fansub, cboFansub)
    .Add(enTablas.Subtitulos, cboSubtitulos)
    .Add(enTablas.Archivador, cboArchivador)
    .Add(enTablas.Video, cboCodecVideo)
    .Add(enTablas.Audio, cboCodecAudio)
    .Add(enTablas.Valoracion, cboRValoracion)
    .Add(enTablas.TipoArchivo, cboContenedor)
    .Add(enTablas.Soporte, cboSoporte)
    .Add(enTablas.Calidad, cboCalidad)
    .Add(enTablas.Resolucion, cboResolucion)
End With

Lo siguiente es pasarle al UserControl el Dictionary con el contenido de las tablas, ya sea mediante una propiedad, un método o un constructor con parámetros. Supongamos que a ese Dictionary lo llamamos _LoQueHayEnLosCombos. Recordemos: ese Dictionary está formado por la enumeración de las tablas, enTablas, y por la BindingList personalizada, lista de una clase con dos propiedades, Id y Descripcion. Ya con todo eso junto, el enlace de cada combo con su tabla correspondiente se puede hacer así:

'Y, ahora, la magia:
For Each Combo As KeyValuePair(Of enTablas, ComboBox) In _MisCombos
    Combo.Value.DataSource = _LoQueHayEnLosCombos(Combo.Key)
    Combo.Value.DisplayMember = "Descripcion"
    Combo.Value.ValueMember = "Id"
Next

En fin, un ejemplo un poco tonto de cómo relacionar colecciones mediante Dictionary que compartan la misma Key. Si a alguien le sirve de algo, como siempre, me alegro.

Un TableAdapterManager es un componente que se genera al crear un dataset tipado. Por lo tanto, si no usamos un dataset tipado ni necesitamos saber que tal cosa existe. Un TableAdapterManager automatiza el proceso de actualizar varias tablas relacionadas, manteniendo (o intentándolo) la integridad de los datos al hacer los update, insert y deletes en el orden apropiado. Hemos dicho que el TableAdapterManager se crea con un dataset tipado, por lo que sólo tendrá utilidad si este dataset tipado tiene varias tablas relacionadas.

Veamos el siguiente ejemplo, un dataset tipado, SeriesDataSet, con tres tablas: Series, Género y GeneroSerie. GeneroSerie es la tabla que permite la relación n:m entre géneros y series (una serie puede tener varios géneros, puede ser un drama romántico de ciencia ficción, por ejemplo).

SeriesDataSet

Vamos a suponer que tenemos un formulario donde el usuario podrá dar de alta, modificar y eliminar series y sus géneros. Es decir, variarán los datos de las datatables Series y GeneroSerie. A la hora de pasar esos cambios de datos a la base de datos debemos tener presente la relación de las tablas. Así, a la hora de insertar nuevas filas deberemos insertar primero las series y luego sus géneros, pero a la hora de borrar deberemos borrar primero los géneros de la serie y luego la serie. Esto significa que no podemos hacer un procedimiento genérico llamando alegremente a los métodos Update de los respectivos tableadapters. Pero podemos usar el método UpdateAll del TableAdapterManager y que sea él quien se coma el marrón. Algo así:

Public Function GuardaDatos(ByVal dsSeries As SeriesDataSet) As Integer
    Dim Result As Integer
    Dim tamSeries As New SeriesDataSetTableAdapters.TableAdapterManager
    Dim taSeries As New SeriesDataSetTableAdapters.SeriesTableAdapter
    Dim taGeneroSerie As New SeriesDataSetTableAdapters.GeneroSerieTableAdapter
    Using cnConexion As New SqlServerCe.SqlCeConnection( _
                                My.Settings.DefaultConnectionString)
        Try
            'Le pasamos los TableAdapters al TableAdapterManager
            tamSeries.SeriesTableAdapter = taSeries
            tamSeries.GeneroSerieTableAdapter = taGeneroSerie
            'Le pasamos la conexión que vamos a usar
            '(De no hacerlo, se crearía la suya propia)
            tamSeries.Connection = cnConexion
            'Abrimos la conexión. En VB2008 sin SP1 daría error
            cnConexion.Open()
            Result = tamSeries.UpdateAll(dsSeries)
        Catch ex As Exception
            Throw ex
        Finally
            cnConexion.Close()
        End Try
    End Using
    Return Result
End Function

Resumiendo: hemos creado una instancia del TableAdapterManager que VB2008 ha creado junto con los tableadapters del dataset tipado SeriesDataSet. El TableAdapterManager necesita que le pasemos los tableadapters con los que va a trabajar, y eso es lo que hemos hecho. Como está tan tipado como el dataset, las datatables y los tableadapters, tiene tres propiedades distintas, cada una esperando su tableadapter. Habíamos dicho que sólo íbamos a modificar valores en la tabla SeriesDataTable y en la tabla GeneroSerieDataTable, por lo que sólo necesitamos sus dos tableadapters correspondientes. De GeneroTableAdapter aquí nos olvidamos.

Ya sólo nos queda llamar al método UpdateAll pasándole el dataset de Series y listo. El TableAdapterManager no tiene mucho más misterio. Básicamente trabajaremos únicamente con las propiedades de los respectivos tableadapters, el objeto Connection, el método UpdateAll y la propiedad UpdateOrder. UpdateOrder tiene dos valores posibles (y autoexplicativos): UpdateInsertDelete
(primero hace los update, luego los insert y por último los delete) e InsertUpdateDelete, que hace lo obvio. Podemos ver lo que hace el método UpdateAll, en todo caso, con el habitual “Ir a definición”.

Y no hay más. Está bien para situaciones sencillitas, y se queda corto en otras. No lo he usado mucho, pero las veces que lo he metido me ha permitido ahorrarme un tiempecito que me ha venido bien para otras cosas.

Partíamos, recuerdo, de una clase muy sencilla, IdMasDescripcion, con dos propiedades, Id de tipo Integer que se corresponde a la clave primaria, y Descripcion de tipo String. La clase, además, implementa la interfaz IComparable(Of T), y el método CompareTo lo que hace es comparar las descripciones. Lo que voy a hacer, entonces, es una BindingList(Of IdMasDescripcion) personalizada que sea capaz de ordenarse. Pero no siempre va a estar ordenada (depende de qué tabla muestre) y la ordenación puede ser alfabética o por resoluciones (de momento; en un futuro puede que me haga falta un tercer tipo). Voy a necesitar un método para ordenar (Sort), y dos campos que me indiquen si la colección está ordenada (IsSorted) y si hay que ordenarla (ToSort):

Imports System.ComponentModel
Imports CdA.Comun

Public Class ReleasesCombosBinding
    Inherits System.ComponentModel.BindingList(Of IdMasDescripcion)
    Public Enum TipoOrden As Integer
        Alfabetico
        Resolucion
    End Enum
    Private _IsSorted As Boolean = False
    Private _ToSort As Boolean = False
    Private _TipoSort As TipoOrden = TipoOrden.Alfabetico

    Protected Overrides Sub ClearItems()
        Me.IsSorted = False
        MyBase.ClearItems()
    End Sub

    ''' <summary>
    ''' Ordena la lista subyacente de forma ascendente
    ''' </summary>
    Public Sub Sort()
        Dim items As List(Of IdMasDescripcion) = TryCast(Me.Items,  _
                                            List(Of IdMasDescripcion))
        If items IsNot Nothing Then
            Select Case Me._TipoSort
                Case TipoOrden.Alfabetico
                    items.Sort()
                Case TipoOrden.Resolucion
                    '(...)
            End Select
            Me.IsSorted = True
        Else

        End If
        Me.OnListChanged(New ListChangedEventArgs(ListChangedType.Reset, -1))
    End Sub

#Region " Propiedades públicas "
    ''' <summary>
    ''' Devuelve si la lista está ordenada o no
    ''' </summary>
    Public Property IsSorted() As Boolean
        Get
            Return Me._IsSorted
        End Get
        Protected Set(ByVal value As Boolean)
            Me._IsSorted = value
        End Set
    End Property

    ''' <summary>
    ''' Devuelve o establece si la lista ha de ser ordenada.
    ''' </summary>
    ''' <value></value>
    ''' <returns></returns>
    ''' <remarks></remarks>
    Public Property ToSort() As Boolean
        Get
            Return Me._ToSort
        End Get
        Set(ByVal value As Boolean)
            Me._ToSort = value
        End Set
    End Property

    Public Property TipoSort() As TipoOrden
        Get
            Return Me._TipoSort
        End Get
        Set(ByVal value As TipoOrden)
            Me._TipoSort = value
        End Set
    End Property
#End Region

#Region " Métodos privados "
    Private Function ValorNumL(ByVal Resolucion As String) As Integer
    End Function
    Private Function ValorNumA(ByVal Resolucion As String) As Integer

    End Function
#End Region

End Class

El código que falta, marcado con (…) en el método Sort y las dos funciones en blanco, se corresponden con la ordenación por resoluciones.  De la clase en sí, tenemos que la propiedad IsSorted sólo puede cambiar su valor desde dentro de la clase: al ordenar la colección o al vaciarla. Por otra parte, el método Sort termina provocando el evento ListChanged, necesario para que todo el mundo que trabaje con esta colección se entere de que ha cambiado.

Vayamos al formulario de Series, que es para el que nos hace falta esta clase. Vamos a tener una ReleasesCombosBinding por cada combo que hay en una pestaña, y que se corresponde con una tabla de la base de datos. Para tenerlo más ordenado, voy a aprovechar una enumeración con toda la lista de tablas de la base de datos, llamada enTablas y definir lo siguiente:

Private CombosReleases As New Dictionary(Of enTablas, ReleasesCombosBinding)

El primer “llenado” lo hago en la capa inferior. El método recibe el diccionario y se ocupa de llenarlo para cada tabla. Como la aplicación no es muy grande, en su día la diseñé en dos capas y el método en cuestión queda embutido en la clase de acceso a datos de una forma un poco extraña pero (ojo, no está todo el código):

Public Function LeerDatosCombosReleases() As Dictionary(Of enTablas,  _
                                                 ReleasesCombosBinding)
    Dim dicCombos As New Dictionary(Of enTablas, ReleasesCombosBinding)
    Dim HeConectado As Boolean = False
    Try
        If Me.Conexion.State = ConnectionState.Closed Then
            HeConectado = Me.Conectar()
        End If
        'Y ahora el lío padre. Necesitamos una variante de LlenarCombo 
        'a la que, pasándole el nombre de la tabla, nos devuelva un 
        'ReleasesComboBinding de esos con todos los valores. Llamaremos 
        'a esa función para cada puñetera tabla para rellenar el dictionary.
        'Las tablas:
        'Archivador
        dicCombos.Add(enTablas.Archivador, _
                      Me.LlenarLista(enTablas.Archivador.ToString, True))
        'Audio
        dicCombos.Add(enTablas.Audio, Me.LlenarLista(enTablas.Audio.ToString, _
                                                     True))
        'Calidad
        dicCombos.Add(enTablas.Calidad, Me.LlenarLista(enTablas.Calidad.ToString))
        'Fansub
        dicCombos.Add(enTablas.Fansub, Me.LlenarLista(enTablas.Fansub.ToString, _
                                                      True))
        'Resolucion
        dicCombos.Add(enTablas.Resolucion, _
                      Me.LlenarLista(enTablas.Resolucion.ToString, _
                      True, ReleasesCombosBinding.TipoOrden.Resolucion))
        'Soporte
        dicCombos.Add(enTablas.Soporte, Me.LlenarLista(enTablas.Soporte.ToString))
        '(...)
    Finally
        If HeConectado Then
            Me.Desconectar()
        End If
    End Try
    Return dicCombos
End Function

Donde LlenarLista lo que hace es crear el nuevo ReleasesComboBinding y rellenarla, ordenando o no según se le indique. El método recibe el nombre de las tablas como parámetro, que, casualmente, coincide con el nombre dado a cada elemento de la enumeración de tablas. Realmente hay dos métodos LlenarLista, una función y un procedimiento. La función crea la colección y la devuelve en su nombre, mientras que el procedimiento recibe la colección como parámetro, lo limpia, rellena y ordena si debe. Este procedimiento será al que llame a la hora de actualizar cada ReleasesComboBinding.

Aquí tenemos la función:

''' <summary>
''' Vuelca el contenido de la tabla indicada en el parámetro
''' a una lista que guarda el campo identificador y el descriptor
''' (los dos primeros) de esa tabla, creando una nueva lista.
''' </summary>
''' <param name=Tabla">Nombre de la tabla</param>"
Public Function LlenarLista(ByVal Tabla As String, _
            Optional ByVal Ordenar As Boolean = False, _
            Optional ByVal Como As ReleasesCombosBinding.TipoOrden = _
            ReleasesCombosBinding.TipoOrden.Alfabetico) As ReleasesCombosBinding
    Dim MisDatos As New ReleasesCombosBinding
    MisDatos.ToSort = Ordenar
    MisDatos.TipoSort = Como
    Try
        Me.LlenarLista(Tabla, MisDatos)
    Catch ex As Exception
        Throw ex
    End Try
    Return MisDatos
End Function

Y aquí el procedimiento:

Public Sub LlenarLista(ByVal Tabla As String, _
                       ByVal MisDatos As ReleasesCombosBinding)
    Dim drDatos As SqlServerCe.SqlCeDataReader
    Dim Comando As SqlServerCe.SqlCeCommand
    Dim tbTabla As DataTable
    Dim HeConectado As Boolean = False
    If MisDatos Is Nothing Then
        Exit Sub
    End If
    Comando = New SqlServerCe.SqlCeCommand("SELECT * FROM " & Tabla, _
                                           Me.Conexion)
    tbTabla = New DataTable
    MisDatos.Clear()
    Try
        If Me.Conexion.State = ConnectionState.Closed Then
            HeConectado = Me.Conectar()
        End If
        drDatos = Comando.ExecuteReader()
        tbTabla.Load(drDatos, LoadOption.OverwriteChanges)
        For Each Fila As DataRow In tbTabla.Rows
            MisDatos.Add(New IdMasDescripcion(CInt(Fila(0)), CStr(Fila(1))))
        Next
        drDatos.Close()
        If MisDatos.ToSort Then
            MisDatos.Sort()
        End If
    Catch NoConexion As InvalidOperationException
        Throw NoConexion
    Catch NoConexion As Exception
        Throw NoConexion
    Finally
        Comando = Nothing
        tbTabla = Nothing
        If HeConectado Then
            Me.Desconectar()
        End If
    End Try
End Sub

Y por hoy, ya me he cansado. La próxima cuento cómo trabajan el formulario y los combos de las pestañas con el diccionario. Lo que me recuerda que los chavales a los que di clase en primavera andaban algo liados con los arrays de estructuras. ¡y yo tengo aquí, básicamente, un array de arrays! La verdad es que cuando pienso en ello empieza a dolerme la cabeza.

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.