Archivo de la categoría: Programacion

SAP Business One B1WS: editar oferta de ventas II

Hace poco tuve que modificar unos documentos de márketing (ofertas y pedidos de ventas) vía B1WS/Di Server. Hasta el momento, sólo había creado documentos de SAP y supuse que la edición seguiría el mismo proceso que con los UDO, con los que tengo bastante más manejo. Básicamente, el proceso con un UDO es:

  • Obtengo el objeto sin modificar vía B1WS.
  • Modifico los campos de la cabecera con los datos nuevos.
  • Con el array de líneas, agrego las nuevas, elimino las que hay que borrar y modifico los campos de las que hay que modificar.
  • Le vuelvo a enviar todo a SAP.

Con las líneas, que es lo que me importa aquí, el proceso es como éste, siendo Origen el objeto con los cambios que envía la capa de lógica de negocio y Destino, el objeto sin modificar recuperado de SAP. Como pueden observar, hay una propiedad en las filas origen que me indica qué debo hacer con ellas:

Sigue leyendo

Microsoft da la espalda a VB.Net

El 11 de marzo se publicó una entrada en el blog de Visual Basic de Microsoft, la primera entrada desde noviembre de 2018 en un blog que había estado bastante surtido hasta octubre de 2017. El título de la entrada es Visual Basic support planned for .NET 5.0. Es una entrada sin firma (aparece .NET Team como autor, mientras que las anteriores, salvo pocas excepciones, iban firmadas por sus autores) y viene a ser la sentencia de muerte de Visual Basic por parte de Microsoft. La entrada dice que van a hacer Visual Basic compatible con .NET 5.0 (la siguiente versión de la rama de .NET Core que va ahora por la 3.1). Ésa es la zanahoria que nos dan, después de meses (por no decir años) de sentirnos ninguneados y olvidados frente a C#.

El palo viene luego: Going forward, we do not plan to evolve Visual Basic as a language. No van a seguir desarrollando Visual Basic. No van a incluir las futuras mejoras de .NET Core. No es que me sorprenda. Llevábamos bastante tiempo con Visual Basic desaparecido del mapa y no tenemos la suerte de que haya un pequeño grupo de desarrollo que pueda ir a lo suyo, como pasa con F#. Tampoco es novedad que Microsoft deje en la estacada a sus clientes. Pasó con VisualFox Pro, por ejemplo. O con Windows Phone. O con las aplicaciones de tienda de Windows 8. Otrora una de las joyas de la corona de Microsoft, hoy Visual Basic es considerado aburrido, viejo y obsoleto por el equipo de desarrollo de .NET y el mensaje es claro: migrad a C#, dinosaurios.

Leí la noticia con resignación. Ya bastante me cuesta tener que dar explicaciones por usar Visual Basic cada vez que lo menciono. Hasta mis compañeros de departamento se han pasado a C# en el último proyecto. El día que tenga que pasarme a C# para ganarme los garbanzos, pues lo haré. O a lo que sea. Programar es mi trabajo. No tiene por qué ser mi afición.

Sin embargo, ayer leí también la contestación de Anthony D. Green, 5 entradas donde se explaya a gusto que ustedes pueden leer aquí: la primera, la segunda, la tercera, la cuarta y la quinta, y que agradezco de corazón. Me ha recordado que Visual Basic es un lenguaje de código abierto desde 2014 que irá donde su comunidad decida que vaya. Me ha explicado algo que debía ser totalmente evidente, que desarrolladores ajenos a un lenguaje de programación no deberían condicionar el futuro de ese lenguaje; que no tengo por qué dar explicaciones ni disculparme por usar las herramientas que uso y porque me guste el lenguaje de programación que me gusta. Cuenta anécdotas y experiencias vividas en su tiempo trabajando en Microsoft y termina con una carta abierta a Nadella.

La lectura ha cambiado mi resignación por cabreo y rebeldía. Quiero seguir programando en VB.Net. Quiero que mi trabajo siga siendo una afición. Quiero disfrutar mucho más de su sintaxis, de imprimirme el código y leerlo en voz alta y del placer de programar, en definitiva. Y si tengo que dejarlo, quizás pueda aprovechar y quitarme esa espinita clavada que es mi otro amor, Pascal, y aprender de una vez Delphi.

EF: usando campos no mapeados en consultas

Tengo un vicio confesable (creo) en programación: las enumeraciones. Siempre que puedo, las uso. Cuando, aprovechando unas semanas de verano con poca carga de trabajo, intenté mapear parte de la base de datos de SAP Business One con Entity Framework (lo que tuvo su complicación, que no es lo que se dice muy relacional), me pregunté si podía utilizar enumeraciones para los campos de estado de documentos, que tan pronto pueden ser O/C como P/R/L/C o cualquier otra forma super-intuitiva.

No me refiero sólo a tener una propiedad de sólo lectura no mapeada para obtener un valor comprensible con los datos ya cargados, o sea, esto:

    <Column("Status")>
    Public Property EstadoSAP As String
    <NotMapped>
    Public ReadOnly Property EstadoEnumerado As EWORSAPStatus
        Get
            Return Convierteme(Me.EstadoSAP)
        End Get
    End Property

Sigue leyendo

ASP MVC: autenticación por formularios

Este año pasado he dado mis primeros pasitos con ASP MVC, siendo también mi primera incursión en programación web. Lo primero que a lo que tuve que enfrentarme (tras pasar por varios tutoriales y leerme un par de libros) fue la gestión del usuario. La aplicación MVC compartía componentes con otras (WCF y Windows Forms) y la gestión del usuario y sus permisos se hacía ya con una implementación de IPrincipal. Una búsqueda por Internet me llevó a que debía usar para esto la vieja autenticación por formularios.

Para ello, primero debía crear mi nuevo proyecto MVC sin autenticación. Creé, a continuación, otro con autenticación para coger todo lo que pudiera del código y ahorrarme trabajo: casi todo el diseño e la vista de login, la vista parcial de _LoginPartial, su implementación en la cabecera… Todo lo que me pudiera suponer un ahorro de trabajo.

Sigue leyendo

Operador Update

El otro día necesitaba actualizar valores en una colección de DataRows tipadas y echaba de menos no poder hacerlo con LINQ, así que me puse a buscar. Y buscando, buscando, encontré el código para un método de extensión Update que soluciona la papeleta. El código está aquí en C# y en Visual Basic quedaría así:

Public Delegate Sub Func(Of TArg0)(element As TArg0)

''' <summary>
''' Executes an Update statement block on all elements in an IEnumerable(T) sequence.
''' </summary>
''' <typeparam name=TSource">The source element type.</typeparam>"
''' <param name=source">The source sequence.</param>"
''' <param name=Updater">The update statement to execute for each element.</param>"
''' <returns>The numer of records affected.</returns>
<System.Runtime.CompilerServices.Extension> _
Public Function Update(Of TSource)(source As IEnumerable(Of TSource), Updater As Func(Of TSource)) As Integer
    If source Is Nothing Then
        Throw New ArgumentNullException("source")
    End If
    If Updater Is Nothing Then
        Throw New ArgumentNullException("update")
    End If
    If GetType(TSource).IsValueType Then
        Throw New NotSupportedException("value type elements are not supported by update.")
    End If

    Dim count As Integer = 0
    For Each element As TSource In source
        Updater(element)
        count += 1
    Next
    Return count
End Function

Su uso sería algo así:

TareasParaArticulo.Where(Function(x) x.IdUsuario = 0).Update(Function(x) x.IdUsuario = JefeProyecto)

Donde TareasParaArticulo es un conjunto de datarows tipadas (un list, un datatable…, tanto da). Lo que hace esta parte de la aplicación, para ponernos en situación, es crear una serie de tareas (tomadas de una plantilla de tareas) cuando un artículo es añadido a un proyecto. El uso del Update permite asignar aquellas tareas que en la plantilla tienen como IdUsuario el 0 al jefe del proyecto de una forma sencilla.

Relación maestro-detalle entre dos ComboBox

Me encontré el otro día con la necesidad de establecer una relación maestro-detalle entre dos combobox. Básicamente, tenía que mostrar en un combobox una lista de procesos y, en el otro, las tipologías de cada proceso. Ahí donde lo ven ustedes, no es algo difícil de hacer, pero sí de encontrar cómo hacerlo. Quizás la solución más elegante sea usar un dataset con las dos tablas en cuestión (Procesos y Tipologías) y la relación entre ambas. De este modo, yo puedo asignar la tabla Procesos como DataSource del combobox de la forma habitual:

            cboProceso.DataSource = dsProcesos.Procesos
            cboProceso.DisplayMember = «Descripcion»
            cboProceso.ValueMember = «Id»

Donde cboProceso es el combobox en cuestión y dsProcesos, el dataset tipado. Para la parte detalle de nuestro sistema, esto es, el combo de Tipologías, usamos el mismo DataSource que para el maestro, es decir, la tabla Procesos. La magia la hacemos en el DisplayMember (en el ValueMember no funciona), que lo expresaremos de la formarelación_entre_tablas.campo_a_mostrar. Es decir, el nombre de la DataRelation que une las tablas de nuestro dataset y el nombre del campo de la tabla detalles (Tipologías en nuestro caso) que mostrará el combobox:

cboTipologia.DataSource = dsProcesos.Procesos
‘ Nótese la forma del displaymember para que muestre sólo las tipologías
‘ del proceso seleccionado en el combo de procesos:
cboTipologia.DisplayMember = «FK_Tipologias_Procesos.Descripcion»
cboTipologia.ValueMember = «IdTipologia»

Muy intuitivo, como pueden observar.

El sistema funciona incluso si queremos hacer un filtrado del maestro. Siguiendo con el ejemplo, puedo crear un dataview de Procesos, usar ese dataview como DataSource de ambos combobox y el invento funcionará sin más.

Donde ya no he conseguido que funcione es con un filtrado en la parte detalles. Digamos que necesito mostrar las tipologías que cumplen cierto requisito. Paso 1: filtrar los procesos, sólo necesito aquellos que tengan tipologías que cumplan el requisito pedido. No es una consulta simple que se pueda hacer en el Filter del DataView, pero puedo tirar de LINQ o de métodos de extensión y hacer algo como esto:

dvProcesos = dsProcesos.Procesos.Where( _
                 Function(Proceso) Proceso.GetTipologiasRows.Any( _
                 Function (Tipologia) (Tipologia.OpcionesTipologia _
                              And EOpcionesTipologia.TareaAutomática) _
                              = EOpcionesTipologia.TareaAutomática)).AsDataView
 

Ya tenemos un dataview (dvProcesos) con los procesos que tienen alguna (any) tipología que cumple los requisitos pedidos. Si yo uso este dataview como DataSource de los combobox, obtengo los procesos que busco, pero todas las tipologías de esos procesos. ¿Cómo filtro ahora las tipologías?

Pues ni idea. El objeto DataRelation no me permite «meter» nada en la relación que no sea equivalencia entre columnas y no he encontrado ninguna forma de filtrar el lado «detalle» de nuestra relación. Al final, he tenido que recurrir a dos bindingsources auxiliares, uno ligado al dataview de procesos y el segundo al bindingsource anterior, especificando en su DataMemeber el nombre de la DataRelation:

mbsProcesos.DataSource = dvProcesos
mbsTipologias.DataSource = mbsProcesos
mbsTipologias.DataMember = «FK_Tipologias_Procesos» 

Ahora uso estos bindingsources para «alimentar» los dos combobox y listo. Aunque me hubiera gustado una solución más elegante.

Y ahora, ¿qué?

Me encuentro dando los últimos retoques a la v3 del SOSNext, un programa de gestión de incidencias que ha crecido tanto que vamos a tener que cambiarle el nombre, porque el módulo de incidencias es ya sólo una pequeña parte del total.

En fin, que estos últimos tres meses le he hecho la cirugía mayor al programa, pasándolo de VB2010 Express a VS2012 (la versión Express ya no daba más), haciéndolo más modular (aumentando la complejidad un montón, de paso), adaptando algunos controles bajados de internet, cambiando algunas cosas de la BDD, metiéndolo todo en Team Foundation Server (Express) para coordinarme con un compañero… Un jaleo enorme.

Y ahora, cuando estoy dando los últimos retoques, un usercontrol que no ha sufrido modificaciones (ni una), que no lo he tocado ni abierto ni cambiado de proyecto o espacio de nombres, que ha pasado desapercibido y no ha recibido ni una mirada de atención, ese cabronazo, digo, ha decidido:

1) Cambiar el alto de las etiquetas y cajas de texto, cortando las letras tipo p, q…

2) Un ListBox con funciones de búsqueda de cadenas (que funciona bien en el resto de controles donde se usa) decide, de paso, funcionar como un ListBox normal (sólo primera letra).

Creo que le he contagiado la gripe, porque otra explicación no se me ocurre.

Validación de filas en DataGridView

Entrada muy rápida y sin código explicativo, pero que quizás sirva a alguien como me ha servido a mí.

El problema es la necesidad de validar los datos que el usuario introduce en un DataGridView. Si controlo el evento RowValidating sólo muestro aviso del error cuando el usuario ha rellenado toda la fila, con el consiguiente problema visual (la celda afectada puede estar fuera de la pantalla visible en ese momento). Si lo que hago es controlar el evento CellValidating, impido que el usuario pueda salir de la celda sin meter un valor válido, lo que puede no interesarme.

Sin embargo, puedo controlar el evento CellEndEdit para ir evaluando los datos introducidos por el usuario y, para aquellos no válidos, usar el ErrorText de la celda en cuestión para avisar del valor no válido. Esto es meramente informativo y usaríamos el evento RowValidating para hacer la validación real de los datos (evitando evaluar nada si IsNewRow es True).

VS2012, la dictadura de los diseñadores y la resistencia de los usuarios

Me he instalado la versión de prueba de Visual Studio 2012 para cacharrear con ella y ver qué tiene de interesante. Con un poco de suerte, pasaré de VB Express a VS Pro en el curro y estoy evaluando tanto VS2010 como VS2012. La verdad es que, si por mi fuera, me quedaba con VS2010. La interfaz de la versión 2012 es un horror de proporciones bíblicas, un canto al ego exacerbado de los diseñadores de interfaces, con un diseño esclavo del minimalismo total de Windows 8 (si Windows Vista y 7 compartían aire y filosofía con KDE, el nuevo Windows es la rendición al estilo Gnome) y sin la más mínima concesión a los pobres currantes que debemos pasarnos horas delante suya.

Resumiendo mucho, la interfaz de VS2012 es como retroceder 20 años al pasado: un entorno monocromo. Iconos en blanco y negro, fondos en grises claros, ninguna concesión al color. Bueno, miento: la Beta era total y absolutamente en blanco y negro, pero ante las quejas los diseñadores han dado unas pequeñas concesiones al color. Por ejemplo, resaltar en un azul plano la pestaña seleccionada o indicar en azul o verde las clases de VB o de C#. Pero todo lo demás (los iconos de controles para el diseñador de formularios, los iconos de todos los demás objetos del explorador de soluciones, como formularios, controles de usuario, carpetas, datasets…), todo lo demás, digo, en blanco y negro.

Menos mal que la comunidad resiste por el bien de nuestra salud visual y mental y nos ofrece herramientas para convertir VS2012 en algo aceptable (aunque no para las versiones Express, me temo).

Para empezar, Visual Studio 2012 Color Theme Editor es una extensión que nos permite crear y editar temas de escritorio: colores de menús, barras de herramientas y tal. Trae varios creados y uno de ellos, Blue, es muy similar al cómodo tema azul de Visual Studio 2010.

Para seguir, la herramienta Visual Studio Icon Patcher nos permite extraer los iconos de VS2010 y metérselo a VS2012. No reemplaza a todos los iconos, pero volveremos a tener los coloristas y fácilmente identificables iconos del Explorador de soluciones y del Cuadro de herramientas. Con eso, me vale. También nos permite dejar la barra de menús en formato normal (primera letra en mayúsculas, resto en minúsculas), no con todo en MAYÚSCULAS, QUE QUEDA HORROROSO DE VERDAD.

Con estas dos herramientas la cosa cambia y podemos centrarnos en descubrir qué trae VS2012.

Oh, cielos

Acabo de instalar en el curro la versión de prueba de VS2012. He conseguido convencerles de que VB Express no da más de sí y necesito algo más «tocho» (es totalmente cierto) y la duda está entre VS2010 y la nueva versión que sale estos días. La primera intención sería tirar por VS2012 si no da problemas con la conversión y compilación de las aplicaciones que estoy desarrollando. Desde VB2005 he ido cambiando de versión tan pronto me era posible. Pero esta vez…

En Visual Studio 2010 teníamos un esquema de colores que delimitaba muy bien las áreas de trabajo y la ventana o pestaña activa. Los iconos eran fácilmente reconocibles por su color antes incluso que por su forma (por ejemplo, amarillo para datos o carpetas… cosas así).

En VS2012, no. Toda el área de trabajo es gris sucio o gris oscuro. Todos los iconos son en blanco y negro, con pequeñas (pequeñísimas) notas de color plano. Si no fuera por esas notas de color disperso y la nitidez del texto y grises, me parecería estar frente al viejo Mac de mi tío, allá cuando mi padre y yo tirábamos de MS-DOS 4.01 y lo de la Multimedia sonaba a cosa futurista.

Menos mal que el código mantiene sus colores. Imagino que eso ha sido una exigencia de los desarrolladores frente al bello monocromo minimalista que proponían los diseñadores. Un poco en plan «si trabajamos con VB4 y 5, a esto sobrevivimos».

No entiendo ni entenderé ese minimalismo conceptual que nos ha caído encima con Windows 8 (y que sufrí en tiempos con Gnome, antes de huir corriendo a KDE). El sufrir con un entorno espartano y retro, como si fuera pecado que nuestras máquinas puedan mostrar millones de colores, texturas, bordes redondeados, sombras…

Visualmente, VS2012 es una rendición a los diseñadores. Sin la ayuda de contrastes, de iconos identificables y agrupables de un vistazo es cansado para la vista y para el cerebro trabajar con él.