#VS2017 ‚Äď Xaml Converter to display local UTC date times

Hi !

Visual Studio Live at Austin will start soon, so I’ll pick up some of my drafts for a quick post.

How to create an XAML Converter to display a DateTime value in the local current format of the machine running the App

The converter code is very simple

And the way to use it is also very easy

So I’ll leave it here so I’ll save some search time ! ūüėÄ

Greetings @ Austin VSLive

El Bruno

Advertisements

#VS2017 – Xaml Converter para mostrar fechas UTC en el formato local

Hola !

Hoy toca post r√°pido que ya empieza Visual Studio 2017 en Austin y mejor sacar los posts que tengo en modo “backUp”. El primero es uno simple:

Cómo crear un XAML Converter que muestre un valor de tipo DateTime en el formato local donde se esté ejecutando la aplicación.

En estos d√≠as he tenido que volver a buscar est√© c√≥digo, ya que una App que durante todo el proceso de desarrollo “funcionaba bien”, de repente al desplegarla a producci√≥n comenz√≥ a mostrar las fechas con un defasaje de un par de horas. Resulta que uno de los entornos de producci√≥n se hab√≠a creado en Europa y claro, desde Norte Am√©rica las horas se ve√≠an mal.

El código del converter es simple

 

Y la utilización con un binding es también bastante simple

Asi que lo dejo por aqu√≠, para no tner que irme aun Git – TFs la pr√≥xima vez a buscar donde lo utilizaba ! ūüėÄ

Saludos @ Austin VSLive

El Bruno

#VS2017 ‚Äď About C# regions and now #Xaml regions also (What?!)

Hi !

If you are a C# Developer, for sure at some time you were part of the following conversation

Regions YES / Regions NO

There are plenty of different opinions on this (check references). If you need to group some parts of your code using regions, you maybe have a “big class”, so probably it’s time for some refactoring.

However, it’s also true that using region may improve the way we read code. There are some scenarios where big classes are required and regions make sense to have a better understanding of the code.

Back in the old days, we face some other projects like CodeMap which are basically focusing the same topic: help a developer to read large pieces of code. We don’t have CodeMap anymore today, it’s evolved to SuperCharger (which I may say, I never use it).

So, I think is a personal choice to use or not use regions. If your goal is to read code and the use of regions helps you, go for it. If you don¬īt like to use regions, don’t use them :D.

And this is mostly for C# code, but if we switch to XAML, this is a complete different story. Edit XAML code in text mode, is a pain. It’s one of the worst developer experiences ever. And if you think about this, using regions in XAML seems to be a good idea. XAML files are usually large, so regions make sense.

Today I find an extension which add this feature to Visual Studio:

XAML Regions (link)

It’s very easy to use. However after reading a while I find that the use of regions on XAML was implemented in Visual Studio since Visual Studio 2015 (what!?). The format to define regions in XAML is similar to this one:

Using only 2 lines of code I can switch from this ugly view :

Clipboard03

To this much more easier to read view:

Clipboard05

My new learning of the day !

Greetings @ Toronto (-42)

El Bruno

References

#VS2017 – Sobre Regiones en C# y ahora en #Xaml (What?!)

Hola !

Si eres un C# Developer, seguramente en alg√ļn momento has participado de la discussi√≥n

Regions SI / Regions NO

Hay much√≠simas opiniones al respecto (ver referencias). Es cierto que si tienes que agrupar alg√ļn tipo de elemento en regiones en una clase, es muy probable que la misma sea “demasiado grande”. O sea, que es momento de refactorizar.

Tambi√©n es cierto, que en determinadas secciones de una app, las clases “grandes” son una necesidad, y utilizar regiones puede ayudarnos a leer una cl√°se m√°s f√°cilmente.

En el camino quedaron proyectos como CodeMap que intentaban darnos una ayuda para mejorar la lectura de código. Hoy por hoy CodeMap ha evolucionado en SuperCharger, debo confesar que no lo he probado.

Para resumir, el uso correcto (o no) de regiones suele tener como objetivo mejorar la lectura y comprensión de código C#. Sobre esta premisa que cada uno escoja la mejor forma de utilizarlas (o no utilizarlas).

Editar código XAML en modo texto, ha sido, es y será lo más parecido a tener un dolor de un cálculo renal. Yo me he pasado horas, colapsando y expandiendo elementos XAML para poder tener una mejor visión del contenido Xaml. Y ahora que lo pienso, la posibilidad de tener regiones en XAML me parece una muy buena idea. Hoy me encuentro con una extensión que nos permite crear regiones en código Xaml:

XAML Regions (link)

La implementación además es muy simple. No hay que ser un experto para comprender como funciona. Sin embargo me llama más la atención que esta funcionalidad viene de fábrica en Visual Studio 2015 y Visual Studio 2017 ! El formato de definición de regiones es el siguiente

Vamos que con solo 2 líneas de código, puedo pasar de

Clipboard03

A esto

Clipboard05

Todos los días se aprender algo nuevo!

Saludos @ Toronto (-42)

El Bruno

References