Las plantillas de Windows Store o la dejadez para con Visual Basic

 

Pues eso… que "trasteando" con las plantillas (tipos de aplicaciones) para Windows Store usando Visual Basic como lenguaje de programación, me he topado con un par de "chorradas" que aunque no son importantes creo que son muestra de, siendo benévolo (por aquello de las fechas en que estamos), un poco de dejadez por parte de "a quién corresponda".

Nota del 29/Dic/12:
He agregado un extra…

Me estoy refiriendo a las plantillas de proyectos para Windows Store de más de una página es decir: GridApp y SplitApp (ver la figura 1).

 

proyectos_appstore
Figura 1. Crear un nuevo proyecto para Windows Store con Visual Basic

 

Si tienes Option Strict On, es decir: ser estricto con las declaraciones y sobre todo con las asignaciones, lo primero que te encuentras es con esta asignación en App.xaml.vb:

Dim rootFrame As Frame = Window.Current.Content

Y la comprobación estricta te indica que esa conversión implícita no es correcta, por suerte, Visual Basic nos ofrece una solución a ese error, tal como vemos en la figura 2, en la que propone que hagamos la conversión con CType.

 

error de conversion implicita

Figura 2. Error de conversión implícita y la solución

Como vemos, la conversión de tipos propuesta es usando CType aunque yo prefiero usar TryCast que es más liviano sobre todo si sabemos que esa conversión es correcta y no producirá un error en tiempo de ejecución.

 

TryCast devuelve un valor nulo si no puede hacer la conversión, mientras que CType producirá una excepción.

 

Otra de esas "chorradillas" que te comento que me he encontrado es en el método ItemsCollectionChanged de la clase SampleDataGroup que está en la carpeta DataNodel de estos dos proyectos.

En dos de los "Case" que realiza al hacer una doble comprobación, es decir, comprueba si esto y aquello está ocurriendo, utilizar And en lugar de AndAlso.

¡¡¡ En este código vemos las dos líneas que contienen los operadores And fatídicos !!!

 

If e.NewStartingIndex < 12 And e.OldStartingIndex < 12 Then


While TopItems.Count < Items.Count And TopItems.Count < 12

 

Puede que creas que no es para tanto, pero si de verdad conoces lo que hace cada uno de esos dos operadores… La cuestión es que yo no utilizo And para una comparación desde que salió la primera versión de Visual Basic para .NET, de hecho antes casi tampoco la usaba y prefería hacer una doble comprobación: usar dos Ifs en lugar de usar And.

Además la documentación de Visual Studio sobre el operador And te indica la diferencia entre And y AndAlso:

En una comparación booleana, el operador And evalúa siempre las dos expresiones, lo que podría incluir llamadas a procedimientos. AndAlso realiza un cortocircuito, lo que significa que si expression1 es False, no se evalúa expression2.

 

Lo curioso de esos And es que si el código está convertido de C# es extraño que no conviertan adecuadamente el operador usado en C#: &&, pero bueno… como And también puede ser un solo ampersand: & pues… es fácil que el conversor de código se equivoque.

 

Ya te dije que eran cosas triviales, pero en ocasiones ver que no se cuidan esos pequeños detalles te pueden hacer pensar si habrá algo más que también pueda fallar… ¡esperemos que no! 😉

 

Nos vemos.

Guillermo

 

Más de lo mismo (addendum del 29 de diciembre de 2012):

Efectivamente, tiene toda la pinta de ser una traducción de C# a Visual Basic, pero "presuntamente" sin mucho cuidado en el resultado final (o casi), ya que en la clase SampleDataSource, concretamente en el constructor se asignan ciertos valores de prueba y una cadena con el contenido, que no es más que la misma cadena repetida varias veces, pero en C# usan \n\n para crear cambios de líneas y en VB lo han dejado con esos mismos "retornos de línea" que no hacen más que mostrar esos caracteres en la cadena en lugar de hacer los cambios de línea.

La posible solución a esta "chorradilla" de fallo sería algo así:

Dim ITEM_CONTENT As String = String.Format("Item Content: {0}{1}{0}{1}{0}{1}{0}{1}{0}{1}{0}{1}{0}",
            "Curabitur class aliquam vestibulum nam curae maecen ..."
            vbCrLf)

 

Pues eso… en fin… es que me hierve la sangre… si no quieren que usemos el Visual Basic, ¡que lo quiten! pero si lo dejan que esté donde tiene que estar: en lugar preferente.

Esta entrada fue publicada en cosas técnicas, mis cosas y etiquetada , , , , , . Guarda el enlace permanente.