Como comenté el otro día he estado jugueteando con el desarrollo .NET para Smartphone y lo cierto es que me he encontrado con cosas, al parecer básicas, pero de las que no sabía nada. Por ejemplo de algo tan tonto como los menús.
La aplicación de ejemplo que quería hacer era un pequeño editor de texto que guardara el contenido cifrado (primera sorpresa: nada de System.Security.Criptography en Smartphones, hubo que buscarsela vida). Añadí un formulario, un campo de texto multilínea, código para ajustar su tamaño (nada de docking tampoco) y un menú de Abrir, Guardar, Salir y este tipo de cosas...
El entorno no se quejaba pero en cuanto ejecutaba la "aplicación" recibía una excepción del tipo NotSupportedException. Para más "INRI", la línea en la que lo indicaba era una tontería (asignaba el título del formulario sin más). ¡Misterio!
Bueno, el caso es que al final el error estaba en otro lugar (error de VS2003 marcando su ubicación, pasa bastante a menudo) y tenía que ver con la forma de construir los menús.
Los menús en aplicaciones Smartphone deben cumplir unas ciertas normas o seproduce una excepción en tiempo de ejecución. Estas normas, a saber, son las siguientes:
- No puede haber más de dos menús de primer nivel aunque VS te permita más. Lógico pues sólo tenemos dos botones de acción disponibles.
- El primer menú de estos dos no puede tener submenús. ¿¿¿Por qué??? Ni idea. En otros lenguajes de Smartphone no existe esta limitación. Es decir, sólo puede haber submenús (o menús hijo) en el segundo menú de primer nivel, o sea, en el botón de la derecha del teléfono.
Fue cambiar el menú de sitio y todo comenzó a funcionar de maravilla. La verdad es que es de coña el asunto...
Por cierto, hay otra restricción tonta: no puedes quitar submenús del menú de la derecha desde código en tiempo de ejecución o tendrás otra excepción. Así que no queda otra que desactivarlos (propiedad Enabled = false) y, como mucho, para que no aparezcan asigar una cadena vacía a su propiedad Text. Esto es lo que recomienda Microsoft pero desde mi punto de vista queda horroroso (aparece el numerito con un espacio vacío al lado)
¿Tan dificil era hacer esto mismo con una propiedad Visible que hiciese lo mismo y guardase internamente el valor del texto para restaurarlo? Yo creo que no, así que he hecho una clase MenuOcultable que lo implementa. Es muy sencillita y un experimento, pero puede ahorrar trabajo...
Este es el aspecto de la aplicación antes de ocultar el menú:
y después de ocultarlo (¿es feo o no?):
Tiene una pega y es que si sustituyes el menú original por el que yo he hecho heredado de la clase MenuItem y luego cambias algo en el formulario, Visual Studio se carga el menú ocultable, así que lo mejor es tener una copia del código en un "Snippet" para estos casos.
En el archivo MenuOcultable.zip (50 KB) tienes el código completo. Necesitarás el SDK de Smartphone para ejecutarlo, claro aunque puedes copiar el '.exe' a tu teléfono para probarlo.
Cuando tenga un rato intentaré hacer lo mismo pero usando la API para tratar de ocultar el menú del todo, a ver si es posible. Imagino que no será posible o los chicos de Microsoft lo habrían hecho, pero intentarlo seguro que es divertido.
💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor
