Categoría: cosas técnicas

Posts relacionados con la programación o manejo o configuración de los oredenadores (computadores)

  • En ocasiones Visual Studio no avisa de los errores en XAML

     

    Pues eso… aunque al leer el título: "en ocasiones…" parece lo del niño ese de la peli Sexto Sentido (no del disco de Melendi), pero la realidad es que es así… y lo de "en ocasiones" lo he puesto como quien dice "presunto" asesino, por aquello de no pillarse los dedos…

    Te cuento… como últimamente estoy aburrío (jeje), pues me puse a trastear en los estilos de una de las páginas incluidas en los proyectos de tipo Windows Store, ya que en la ayuda vi que puedes modificar un estilo existente y agregarlo a varios sitios: la propia página en la que está el estilo original, en App.xaml y en otra página (del tipo resource dictionary) que tengas en tu proyecto.

    Todo esto es porque no daba con la tecla de cómo usar mi propio fichero de estilos que define estilos que usan otros estilos que están definidos en otra página… ¡QUIETOOOORRRR!
    ¡No te vayas!, que no es que te esté intentando liar… es que es así… sí, además, si estás leyendo esto lo mismo ya has leído lo que he publicado hace unos minutos y que precisamente soluciona el problema ese que te comento en este mismo párrafo:

    Crear un fichero de estilos XAML y acceder a estilos definidos en otro fichero

     

    Sigamos, pero veamos "gráficamente" lo que te comento, por ejemplo, abrimos (en modo diseño) la página SplitPage.xaml de un proyecto del tipo SplitApp (vale cualquier otra que tenga el botón para ir atrás), si seleccionas el botón de ir atrás y vas a las propiedades para acceder a la propiedad Styles (que está en el grupo Miscellaneous) verás que el estilo actual está indicado con un puntito verde a la derecha (ver figura 1), si pulsas en ese "punto" te mostrará un menú con varias opciones (ver figura 2)

    propiedades 1propiedades 2
    Figuras 1 y 2. Propiedades del estilo y convertir a nuevo recurso

     

    Si seleccionas Convert to New Resource te permitirá hacer una copia de ese recurso en el fichero que indiques, en mi caso (tal como vemos en la figura 3) lo quiero incluir en mi fichero de estilos.

     

    propiedades 3
    Figura 3. El cuadro de diálogo para indicar dónde estará el nuevo recurso

     

    Nota:
    Los ficheros mostrados en esa lista desplegable del cuadro de diálogo de crear un nuevo recurso de estilos, deben estar previamente agregados a MergedDictionary de App.xaml.
    Para saber cómo hacer esto que te comento, mira el enlace que te puse más arriba.

     

    Pues bien, eso hice yo. Agregué el nuevo recurso a mi fichero, e hice todo lo que te comenté en el post anterior. Ahora voy a probar los cambios (que no había sido nada, sólo lo de crear el recurso en otro fichero) y no funciona la aplicación.
    Bueno, funcionar si que funciona, de hecho me mostraba la página principal (ItemsPage) pero al pulsar en una de las opciones mostradas no me mostraba la otra página con los detalles… ¿adivinas cómo se llama la otra página! ¡BINGO! SplitPage.
    Pero claro, yo como iba a pensar que "yo" era el culpable (¿he sido yo? que diría Steve Urkel), así que… me puse a "debuguear" y nada, se quedaba en la llamada a esa página, pero no mostraba nada, ni daba error, ni ná de ná.
    Así que… aburrido (esta vez de probar y probar y no saber qué pasaba) quité ese proyecto y volví a crear otro del mismo tipo, pero sin cambiar nada del recurso… La pruebo y, claro, como es de esperar: ¡funciona!
    Eso sí, se paró en el mismo punto de interrupción que puse en la aplicación anterior ¿por qué? ni idea, lo que si te digo es que las dos aplicaciones se llamaban igual (sólo renombre el directorio para que no me diese error).

    Volví a probar sin el breakpoint y seguía funcionando. Así que… descargue ese proyecto y volví a cargar el anterior (el que estuve trasteando). Y me fije en cómo se llamaba el recurso que utilizaba el botón ese de la página SplitPage, y como era de esperar al hacer la copia del recurso se había cambiado el nombre y como resulta que yo había eliminado (en realidad quitado del proyecto) el fichero en el que se creó dicho recurso de estilos, pues… ¡no existía!

    Resumen, que ya es noche y me estoy alargando más de lo necesario:
    Si usas un estilo que no existe en un control XAML, "es posible" que Visual Studio no te alerte de ese "pequeño detalle".

    Y lo de es posible lo digo porque a mi otras veces si me ha avisado de que no existe, pero no avisando con un mensaje de alerta, si no , detallándolo en la ventana de errores, ya que si compilas y ejecutas si que funciona… es decir, no se para porque haya un error en el código XAML.

    Aunque también está la contrapartida, la de que te muestre cuadro de diálogo con un error (o que se pare la aplicación en el código oculto de la clase App) pero no veas el error en ningún sitio (ni en la ventana de errores), eso sí, con suerte puedes ver que el mensaje de error es:
    DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
    como ya te comenté en su día: Error al usar inadecuadamente el XAML.

     

    Pues nada, creo que ya está bien por hoy… y si esto te sirve para no tener los quebraderos de cabeza que he tenido por "no saber", pues… mejor, eso es de lo que se trata algunas veces: que los demás solucionen antes los errores que yo ya tuve… 😉

     

    Nos vemos.
    Guillermo

  • Crear un fichero de estilos XAML y acceder a estilos definidos en otro fichero

     

    Pues eso… que estaba yo haciendo modificaciones en los estilos que vienen en el fichero StandardStyles.xaml (incluido en las plantillas de aplicaciones para Windows Store), y como no tenía muy claro cómo definir esas modificaciones en otro fichero diferente del que se incluye en las plantillas de los proyectos para Windows Store, al final acabé dejándolos en ese mismo fichero.

    Pero hoy (o ayer, ya no llevo la cuenta de los días y las noches) me puse a hacerlo (de nuevo), es decir, me fui a agregar un nuevo fichero del tipo ResourceDictionary (Dictionary1.xaml) y ahí pegué los estilos que yo definí para usar en otra aplicación y que lo mismo me podrán ser de utilidad en esta nueva.

    Una vez que has creado un nuevo "diccionario de recursos", debes añadirlo al elemento ResourceDictionary de App.xaml, concretamente en ResourceDictionary.MergedDictionaries, que uno sabe esto, entre otras cosas porque ahí es donde está indicado el fichero de estilos estándar.

    Como mis nuevos estilos (algunos de ellos) están basados en los que se incluyen en StandardStyles.xaml, lo que hice es agregarlo después del StandardStyles (por aquello de que así referencie primero el estándar y después el mío). Pero no… así no vale.

    El problema es que además el Visual Studio no te dice nada de que eso está mal, la cuestión es que la aplicación no funciona y, lo más frustrante es que no sabes por qué.
    Ahora sé que es porque estaba haciendo referencia a estilos que no estaban definidos (al menos en mi fichero).
    Pero el problema es que yo "sabía" que sí, que esos estilos estaban definidos, pero en otro fichero.
    Y ese era el problema, que estaban en otro fichero.

    Busqué en la ayuda a ver… y curiosamente vi que en uno de los ejemplos había dos ficheros definidos en MergedDictionaries de App.xaml. Y en realidad eso hay que hacerlo así:

     

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
    
                <!-- 
                    Styles that define common aspects of the platform look and feel
                    Required by Visual Studio project and item templates
                 -->
                <ResourceDictionary Source="Common/StandardStyles.xaml"/>
                <ResourceDictionary Source="Dictionary1.xaml"/>
                
            </ResourceDictionary.MergedDictionaries>
    
            <!-- Application-specific resources -->
    
            <x:String x:Key="AppName">Libros SplitApp</x:String>
        </ResourceDictionary>
    </Application.Resources>
    
    

     

    Pero lo que debes saber (todo este rollo para contarte esto) es que si tu fichero va a usar estilos definidos en otro fichero (al menos si tu intención es crear nuevos estilos que se basen en algunos de los definidos en ese fichero) debes indicarlo de forma explícita en tu fichero, y sería incluyéndolo en un elemento del tipo MergedDictionaries, pero en tu fichero.

    Por ejemplo, si desde mi fichero Dictionary1.xaml quiero utilizar estilos definidos en StandardStyles debo añadir este código al principio del fichero (o en la parte superior, después de las definiciones de ResourceDictionary):

     

    <ResourceDictionary
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="using:Libros_SplitApp">
    
        <ResourceDictionary.MergedDictionaries>
            <!-- 
                        Styles that define common aspects of the platform look and feel
                        Required by Visual Studio project and item templates
                     -->
            <ResourceDictionary Source="Common/StandardStyles.xaml"/>
        </ResourceDictionary.MergedDictionaries>
    
        <!-- Mis estilos basados en otros existentes en StandardStyles.xaml -->
      
    

     

    Para que nos entendamos:

    1.- Si quiero que en mi aplicación los recursos definidos en mi fichero estén accesibles, debo indicarlo en MergedDictionary de App.xaml.

    2.- Si quiero que mi fichero utilice estilos definidos en otro fichero de estilos XAML debo crear un elemento MergedDictionary y añadirlo de la misma forma que el mío está indicado en App.xaml.

     

    Y eso es todo…

    Pero habrá más, ya que el XAML no se lleva muy bien que digamos con el "depurador" de Visual Studio y hay más cosas que pueden pasar sin que sepas por qué pasan… aunque para eso estoy yo aquí, par contártelo 😉

     

    Nos vemos.

    Guillermo

  • 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.