miércoles, 20 de mayo de 2009

ASP.NET MVC y Custom Http Handlers

Hola! ¿Como va todo?

Un post rapidito… Imaginad que creais un Custom Handler para procesar determinadas peticiones en vuestra aplicación ASP.NET MVC:

    public class CardImagesHandler : IHttpHandler
    {
        #region IHttpHandler Members
        public bool IsReusable
        {
            get { return false; }
        }
        public void ProcessRequest(HttpContext context)
        {
            // ...
        }
        #endregion
    }


Luego, lo añadís en el web.config, para que os procese todas las URLs con extensión .portrait:



<add verb="GET" path="*.portrait" 
type="WofWeb.Code.CardImagesHandler"/>


Finalmente probáis alguna URL con extensión portrait, tal y como http://localhost:8080/prueba.portrait i veis que vuestro Custom Http Handler es vilmente ignorado…



¿Por qué? Pues porque ASP.NET MVC toma control de todas las URLs, por lo que intentará procesar esta URL aunque hayamos definido un Custom Http Handler para ella. ¿La solución? En la tabla de enrutamiento indicar que queremos que se ignoren las URL con .potrait, de esta manera serán procesadas por nuestro Custom Http Handler…



… tan sencillo como añadir:



routes.IgnoreRoute("{resource}.portrait/{*pathInfo}");


en global.asax donde configuremos la tabla de enrutamiento!



Saludos!



PD: Este post es un crosspost desde mi blog de geeks.ms!

jueves, 14 de mayo de 2009

Surface en raona...

Hola! En raona tenemos desde hace algún tiempecillo la Surface... Lo que os quiero mostrar no es nada más que un pequeño vídeo de una aplicación que hemos desarrollado para ella: el Surface Shooter.

¿Y que es? Pues como bien se encarga de explicar mi compañero Juan Carlos Viñas permite navegar por los documentos de un portal de sharepoint usando la Surface.

Os dejo el enlace al youtube donde está el video:

Video Raona Surface Shooter (youtube)

En raona pensamos que la Surface ofrece grandes oportunidades, tanto a clientes como a proveedores, aunque es cierto que es necesario que nos olvidemos de todos los conceptos que tenemos preconcebidos en cuanto a como debe ser presentada una interfaz gráfica (os recomiendo que os leais este enorme post del no menos grande Miguel: Microsoft Surface: Developing NUI Touch Experiences).

Un saludo a todos!!! :)

PD: Este post es crossposting desde mi blog en geeks.ms!

miércoles, 15 de abril de 2009

Mostrar un formulario modal con ASP.NET MVC y Ajax (ii)

En el post anterior (Mostrar un formulario modal con ASP.NET MVC y Ajax) comenté como había usado SimpleModal en una aplicación ASP.NET MVC para mostrar un formulario modal al usuario.

En este post voy a comentar como podemos comunicar nuestro formulario modal con nuestros controladores, para así poder validar (parcialmente o totalmente) el formulario desde servidor, sin necesidad de hacer un submit, usando Ajax.

En mi caso p.ej. a medida que el usuario va entrando un posible nickname, se le indica si dicho nickname ya está ocupado o no (aunqué en la versión final probablemente sea un boton “comprobar nick”, ya que una llamada Ajax cada vez que se entre un carácter en un textbox quizá es demasiado… pero eso no afecta al sentido del post). Para realizar las llamadas Ajax cada vez que el usuario pulse una tecla en el campo “nick” del formulario modal vamos a usar jQuery.

Lo primero que debemos cambiar respecto al post anterior es la forma en como abrimos el formulario modal: el método modal de SimpleModal, admite varios parámetros, uno de los cuales es una función de callback que SimpleModal llamará. A través de esta función vamos a registrar una función gestora del evento KeyPress usando jQuery. Recordáis la función show_popup() que teníamos en la vista Index.aspx? Su código ahora queda así:

function show_popup() {
$("#popup").modal( { onOpen: popup_open});
}

Hemos añadido el parámetro onOpen con el nombre de una función javascript que SimpleModal nos llamará cuando deba abrir el formulario modal.


Una particularidad de SimpleModal es que si usamos la función de callback onOpen, debemos encargarnos nosotros de abrir el formulario modal. Así el código de la función popup_open queda así:

function popup_open(dialog) {
dialog.overlay.show(1);
dialog.container.show(1);
dialog.data.show(1);
}

Debemos llamar al método show (un método estándar definido en jQuery) con los tres elementos que componen el formulario modal de SimpleModal: Overlay (que lo que hace es inhabilitar el resto de la pantalla), Container (que muestra el borde del formulario) y Data (que muestra el contenido del formulario).


Otra forma “más jQuery” de realizar lo mismo es encadenar las llamadas: Generalmente todos los métodos jQuery aceptan un parámetro callback con código a realizar cuando se termine el método. Así también podríamos escribir la función popup_open como:

function popup_open(dialog) {
dialog.overlay.show(1,function() {
dialog.container.show(1,function() {
dialog.data.show(1);
});
});
}

El siguiente paso es añadir el código para suscribirnos al evento onKeyPress del textbox cuyo id era “nick”. jQuery unifica todos los eventos de los distintos browsers en un conjunto de eventos propio, lo que permite más fácilmente desarrollar aplicaciones cross-browser. El método keypress de un objeto jQuery permite suscribir un callback al evento de pulsación de una tecla. Un objeto jQuery es un objeto javascript que se obtiene generalmente usando la función selector (comúnmente llamada $) de jQuery. Así la llamada:

$("#popup")

Me devuelve el objeto jQuery asociado al elemento DOM cuyo ID sea “popup”. Esto no es equivalente a document.getElementById(“popup”) que me devuelve el objeto DOM directamente… es mucho mejor, ya que sobre el objeto jQuery puedo usar todas las propiedades de jQuery (como el método show() que hemos visto antes o el método modal() que define SimpleModal)!


Así pues, para suscribirnos al keypress del textbox cuyo ID es “nick” usando jQuery, el código de popup_open queda:

function popup_open(dialog) {
dialog.overlay.show(1, function() {
dialog.container.show(1, function() {
dialog.data.show(1, function() {
$("#nick").keypress(function(e) { });
});
});
});
}

Ahora sólo nos rellenar la función anónima que pasamos como parámetro a la llamada a keypress con el código que realice una petición Ajax a un controlador para que compruebe si el nick que se ha entrado está libre o no. Para ello vamos a usar la función getJSON de jQuery, que lo que hace es realizar una petición Ajax a la URL especificada, esperar la respuesta en formato JSON, deserializar la respuesta en un objeto Javascript y ejecutar el método de callback que nosotros le indiquemos.


Así, pues usando getJSON el código de popup_open queda así:

function popup_open(dialog) {
dialog.overlay.show(1, function() {
dialog.container.show(1, function() {
dialog.data.show(1, function() {
$("#nick").keypress(function(e) {
if (e.which != 13 && e.which != 8
&& e.which != 0) {
var str = this.value +
String.fromCharCode(e.which);
var url = "/Account/Check";
$.getJSON(url, { nick: escape(str) },
function(data) {
if (data.existeix) {
$("#invalid_nick").show();
}
else {
$("#invalid_nick").hide();
}
});
}
});
});
});
});
}

Dentro de la función gestora del evento keypress:



  1. Miramos que la tecla pulsada NO sea enter, backspace o tabulador
  2. Llamamos a getJSON con la URL /Account/Check (parámetro 1), con el valor del textbox codificado como parámetro (parámetro 2) y la función de callback que queremos ejecutar cuando recibamos la respuesta del servidor (parámetro 3 que es un método anónimo).

    1. Dentro del método anónimo, miramos si el valor del campo “existeix” del objeto recibido como parámetro es true para mostrar u ocultar un objeto cuyo ID es “invalid_nick”.

¿Que nos queda por hacer? Pues por un lado modificar la vista parcial que es el formulario modal (en mi caso era SignupPopup.ascx), para añadir un <DIV> con un id “invalid_nick” con un mensaje que ponga “NICK INCORRECTO” (o algo así). P.ej:

<div id="invalid_nick" style="display:none">
NICK IS INVALID
</div>

Inicialmente lo tenemos oculto (evidentemente usaríamos CSS y alguna imágen para hacerlo más “bonito”), puesto que lo mostramos via jQuery.


Por último lo que nos queda es hacer la función correspondiente en el controlador. En mi caso el controlador es AccountController y la acción es “Check” (como se puede deducir de la URL /Account/Check):

public ActionResult Check(string nick)
{
return new JsonResult() {
Data = new {existeix = nick.Length % 2 == 0 }
};
}

Esta acción en lugar de devolver una vista, devuelve un objeto serializado en JSON, usando JsonResult. Básicamente cuando queráis devolver un objeto codificado en JSON usando ASP.NET MVC:



  1. Creais un JsonResult.
  2. A la propiedad Data la asignais el objeto a serializar.

Esta función devuelve un objeto con una propiedad “existeix” que vale true si el nick tiene un número par de carácteres.


¡Ya lo tenemos todo listo! Ahora si vais tecleando carácteres en el formulario, se ve como se muestra o se oculta la etiqueta “NICK IS INVALID”.


¿Fácil, verdad?


Saludos!


PD: Recordais lo que os dije, que cuando usabamos el callback onOpen de SimpleModal debíamos “abrir” manualmente el overlay, el container y la data y que eso nos daba capacidades interesantes? Este “interesantes” viene por la API de animación de jQuery. P.ej. si podríamos cambiar los show() por llamadas a fadeIn para que la aparición del formulario sea más espectacular:

function popup_open(dialog) {
dialog.overlay.fadeIn('slow', function() {
dialog.container.fadeIn('slow', function() {
dialog.data.fadeIn('slow', function() {
// A partir de aquí todo igual...
});
});
});
}

¡Y observad como se despliega suavemente el formulario! ;-)


PD: Crossposting desde mi blog de geeks.ms!

martes, 14 de abril de 2009

Mostrar un formulario modal con ASP.NET MVC y Ajax

¿Os gusta ASP.NET MVC? A mi personalmente me encanta… aunque está un poco verde, en el sentido que comparándolo con webforms hay varias cosas que debes hacerte tu mismo, el modelo de programación es simple y elegante… Gran parte del mérito lo tiene (además del uso del patrón MVC evidentemente), jQuery genial librería de Javascript donde las haya.

Hay mucha gente desarrollando en jQuery (al margen de que usen o no ASP.NET MVC) y dado lo bien que se entienden ASP.NET MVC y jQuery es muy fácil realizar tareas que antes eran un poco… complejas.

Yo me he encontrado con la necesidad de mostrar un pop-up (modal) en una aplicación ASP.NET MVC. Un par de búsquedas por google me han llevado a SimpleModal, un genial plugin para jQuery que precisamente hace esto: mostrar formularios modales. En su página web hay varios ejemplos (en su caso él usa PHP).

Os cuento como he integrado SimpleModal en mi aplicación ASP.NET MVC por si a alguien le interesa… Esta ha sido mi manera de hacerlo, no pretendo sentar cátedra porque hay muuuuuuucha gente que sabe más que yo (especialmente de jQuery).

En concreto la necesidad era mostrar un link, que al pulsarse desplegase un pop-up modal para que la gente pudiera darse de alta en la página.

La página que muestra el enlace (en mi caso Index.aspx) tiene el siguiente código ASP.NET:

<%= Ajax.PopupLink ("Join the game", "Signup","Account", "popup") %>
and start playing!
<div id="popup" />

El método PopupLink es un método extensor de AjaxHelper:

public static string PopupLink(this AjaxHelper helper, string linkText, 
string actionName, string controllerName, string popupId)
{
AjaxOptions options = new AjaxOptions()
{
UpdateTargetId = popupId,
OnComplete = "show_popup",
HttpMethod = "GET"
};
string link = helper.ActionLink(linkText, actionName,
controllerName, options);
return link;
}

Ok… no es un método muy configurable, pero a mi me va bien :) Lo que hace es mostrar un enlace con el texto especificado y le establece unas opciones por defecto: Que la llamada sea via Ajax usando GET, que se llame a una función javascript “show_popup” al terminar y que se actualice el elemento DOM especificado (en este caso el último parámetro llamado ‘popup’). Los parámetros “actionName” y “controllerName” del método sirven para especificar que acción de que controlador debe devolver la vista parcial que contiene el popup. En mi caso la acción “Signup” del controllador “AccountController” que está definida tal y como sigue:

public ActionResult Signup()
{
if (Request.IsAjaxRequest())
{
return PartialView("SignupPopup");
}
else return RedirectToAction("Index", "Home");
}

Como podeis ver me limito a devolver la vista parcial SignupPopup que es la que contiene el código HTML del popup. Cuando el usuario haga click en el enlace “Join the game” se llamará via Ajax a la acción Signup que devolverá la vista parcial “SignupPopup”, el código de la cual se incrustará dentro del div “popup”.


El código de la vista parcial en mi caso es muy simple:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

<div>
<
h1>Join the Game!</h1>
<% using (Html.BeginForm("Signup", "Account", FormMethod.Post)) { %>
<label for="nick">*Nick Name:</label>
<
input type="text" id="nick" name="nick" tabindex="1001" />
<
br />
<
label for="email">*Email:</label>
<
input type="text" id="email" name="email" tabindex="1002" />
<
br />
<
label>A email for validate your account will be sent at
email address you specified.</label>
<
br />
<
button type="submit" tabindex="1006">Send</button>
<
button type="reset" tabindex="1007">Cancel</button>
<
br/>
<% } %>
</div>

Basicamente tenemos un formulario con dos campos: nick y email. Cuando hagamos un submit del formulario (via POST) se llamará a la acción Signup del controlador AccountController, acción que está definida como sigue:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Signup(string nick, string email)
{
// Codigo para dar de alta el nuevo usuario...
// Mostramos la vista de Bienvenida
return View();
}

No mucha cosa… El controlador da de alta el usuario y finalmente muestra una vista de bienvenida.


Finalmente en la página Index.aspx, debemos tener el método javascript show_popup, que será el encargado de mostrar el popup usando SimpleModal:

<script type="text/javascript">
function
show_popup() {
$("#popup").modal();
}
</script>

El código es muy simple: accedemos al elemento div con id=”popup” que hemos rellenado con el contenido de la vista parcial, y usamos el método modal() que define SimpleModal para mostrar este div como un formulario modal…


… y listos!


Simple y sencillo… en otro post mostraré como comunicar nuestro formulario via Ajax con nuestros controladores (p.ej. para poder validar datos en servidor sin necesidad de hacer submit del formulario).


PD: Como siempre, este post es un crosspost desde mi blog en geeks!

jueves, 2 de abril de 2009

ASP.NET MVC, Controles Chart y Ajax…

Supongo que la gran mayoría de vosotros, conoceréis los controles de gráficos de ASP.NET. José M. Aguilar hizo un excelente post sobre ellos aquí (http://geeks.ms/blogs/jmaguilar/archive/2008/12/14/microsoft-chart-control-para-asp-net-3-5-sp1.aspx).

Utilizarlos es realmente simple… basta con que os los descargueis de la web de Microsoft y después de instalarlos agregueis las siguiente líneas en el web.config:

<add path="ChartImg.axd" verb="GET,HEAD" 
type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler,
System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
" validate="false"/>

En la sección <httpHandlers> y la siguiente:

<add tagPrefix="asp" 
namespace="System.Web.UI.DataVisualization.Charting"
assembly="System.Web.DataVisualization, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35
"/>

En la sección <controls>.


Despues ya podeis arrastrar un Chart control desde la toolbox a vuestra página ASP.NET y empezar a trabajar con él.


Si, como yo, os encanta ASP.NET MVC sabed que podeis usar este control sin ningún problema (http://code-inside.de/blog-in/2008/11/27/howto-use-the-new-aspnet-chart-controls-with-aspnet-mvc/).


El único temilla a tener en cuenta es si se quiere actualizar sólo el gráfico mediante Ajax (usando ASP.NET MVC).


Suponed una vista parcial (Chart.ascx) con el siguiente código que muestra un gráfico con contenido random:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<asp:Chart ID="chart" runat="server" Palette="Fire" >
<
Series>
<
asp:Series Name="D1" ChartType="StackedColumn" />
<asp:Series Name="D2" ChartType="StackedColumn" />
</Series>
<
ChartAreas>
<
asp:ChartArea Name="ChartArea1">
</
asp:ChartArea>
</
ChartAreas>
</
asp:Chart>
<
script runat="server">
protected void
Page_Load(object sender, EventArgs e)
{
Random r = new Random();
this.chart.Series["D1"].Points.Add(r.Next(100));
this.chart.Series["D2"].Points.Add(r.Next(100));
}
</script>

Y otra vista (Victories.aspx) que contiene el siguiente código (entre otro):

    <%=Ajax.ActionLink("Actualizar", "Victories", 
new RouteValueDictionary(new { Days = 7, Interval = 1 }),
new AjaxOptions() { UpdateTargetId = "chart" }) %>
<div id="chart" />

El enlace “Actualizar” envia una petición Ajax al controlador actual para que invoque la acción “Victories” y con el resultado actualice el div “chart”.


La acción “Victories” está implementada en el controlador tal como sigue:

public ActionResult Victories(int? days, int? interval)
{
return PartialView("Chart");
}

De este modo a cada click del enlace se genera un nuevo gráfico aleatorio y se actualiza via Ajax la página…


… en teoria, porque en la práctica no se ve nada. Analizando con firebug lo que ha sucedido se puede observar que se lanza una excepción:

[HttpException (0x80004005): Error executing child request for ChartImg.axd.]

La solución? Caer en la cuenta de que las peticiones Ajax usan POST por defecto, así que o bien cambiamos la línea que añadimos en el web.config para que soporte POST:

<add path="ChartImg.axd" verb="GET,HEAD, POST" 
type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler,
System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
" validate="false"/>

o bien le indicamos  a la petición Ajax que sea usando “GET”:

<%=Ajax.ActionLink("Last Week", "Victories", 
new RouteValueDictionary(new { Days = 7, Interval = 1 }),
new AjaxOptions() { HttpMethod="GET", UpdateTargetId = "chart" }) %>

Saludos!

miércoles, 11 de marzo de 2009

PRISM y Winforms: Mostrar vistas en nuevos formularios

En un post anterior (PRISM y Winforms), comentaba como usar PRISM para realizar aplicaciones Winforms.

Un comentario de Jose en esta entrada, me ha motivado a escribir el siguiente post, para mostrar como podríamos mostrar vistas en regiones que estén incrustadas no en un UserControl (típicamente un Panel) de la ventana principal, sino incrustadas en un nuevo formulario.

Para poder usar regiones en Winforms era necesario definirnos un RegionAdapter para la clase “Control” que era básicamente el objetivo del post anterior. En el método Adapt() teníamos el código que “incrustaba” la vista dentro del control. Dicho método recibía (de PRISM) la región y el target, o control donde colocar dicha región.

Antes que nada recordad tres conceptos que a veces se confunden:

  1. Region: En PRISM una región es un conjunto de vistas (algunas activas, otras no activas) que se muestran en algún sitio determinado.
  2. Target: El target de una región es el lugar donde se muestran. P.ej. un TableLayout podría ser el target de una región y cada vista de la región podría mostrarse en distintas celdas.
  3. Vista: Una vista muestra una determinada información. P.ej. si tenemos una aplicación que nos muestra la cotización de varias acciones, podríamos tener varias instancias de una vista, donde cada instancia nos mostraría la cotización de una acción. En winforms generalmente es un UserControl.

En PRISM las vistas se colocan en regiones y las regiones se incrustan en los targets… recordad que una región puede tener varias vistas.

En el RegionAdapter que vimos en el post anterior, siempre recibíamos la región y el target. El target ya estaba creado porque era un control ya existente en la ventana principal.

Esto no nos sirve si queremos mostrar una vista en un formulario nuevo ya que ahora debemos crear el formulario cada vez que queramos mostrar la región… ¿como podemos hacerlo?

Además del método Adapt() que usamos en el post anterior, los RegionAdapter pueden redefinir otro método llamado AttachBehaviors. En este método podemos añadir la lógica que queramos para personalizar el comportamiento de la región… en este caso podremos aprovechar para crear el target.

Un vistazo al código…

El código que sigue a continuación es una adaptación de la clase WindowRegionAdapter de Composite WPF Contrib, que he adaptado para que funcione con Windows Forms.

El método AttachBehaviors lo redefinimos de la siguiente manera:

protected override void AttachBehaviors(IRegion region, 
Form regionTarget)
{
base.AttachBehaviors(region, regionTarget);
FormRegionBehavior behavior =
new FormRegionBehavior
(regionTarget, region, FormBorderStyle.FixedSingle);
behavior.Attach();
}

Los parámetros que recibe son los mismos que Adapt: la región y el target (en este caso un Form) ya que derivamos de RegionAdapterBase<Form>. En este método creamos un objeto FormRegionBehavior que será el que tendrá todo el código para gestionar regiones que estén dentro de un formulario. En concreto dicha clase será la responsable de:



  1. Crear un formulario por cada nueva vista añadida a la región y incrustar dicha vista en el formulario
  2. Cerrar el formulario que contiene una vista si esta se elimina de la región.
  3. Eliminar una vista de la región si se cierra el formulario que la contiene.
  4. Activar o desactivar la vista cuando su formulario es activado o desactivado.

A continuación pongo el código más relevante de dicha clase. Al final del post adjunto una aplicación de demo.


1 y 2. Crear un formulario por cada nueva vista y eliminar el formulario de una vista eliminada


El método Attach() de la clase FormRegionBehavior de suscribe a los dos eventos CollectionChanged de las colecciones Views y ActiveViews de la región:

internal void Attach()
{
IRegion region = _regionWeakReference.Target as IRegion;
if (region != null)
{
region.Views.CollectionChanged +=
new NotifyCollectionChangedEventHandler
(Views_CollectionChanged);
region.ActiveViews.CollectionChanged +=
new NotifyCollectionChangedEventHandler
(ActiveViews_CollectionChanged);
}
}

En el método Views_CollectionChanged es donde sabemos si se ha añadido una vista a la región o se ha eliminado, y así podemos crear o destruir el formulario asociado:

private void Views_CollectionChanged(object sender,
NotifyCollectionChangedEventArgs e)
{
Form owner = _ownerWeakReference.Target as Form;
if (owner == null)
{
Detach();
return;
}
if (e.Action == NotifyCollectionChangedAction.Add)
{
foreach (object view in e.NewItems)
{
// Creamos un formulario por cada vista y lo mostramos...
}
}
else if (e.Action == NotifyCollectionChangedAction.Remove)
{
foreach (object view in e.OldItems)
{
// Buscamos el formulario que contiene cada vista
// para cerrarlo y "disposarlo" :)
}
}
}

3. Eliminar la vista de la región si se cierra el formulario


Para ello, cuando creamos un formulario, nos suscribimos al evento Closed para poder eliminar la vista asociada a la región:

private void Form_Closed(object sender, EventArgs e)
{
Form frm = sender as Form;
IRegion region = _regionWeakReference.Target
as IRegion;
if (frm != null && frm.Controls.Count > 0
&& region != null)
if (region.Views.Contains(frm.Controls[0]))
region.Remove(frm.Controls[0]);
}

4. Activar o desactivar la vista cuando su formulario es activado o desactivado


Para ello, cuando creamos un formulario nos suscribimos a los eventos Activated y Deactivate, para desactivar o activar la vista correspondiente:

private void Form_Activated(object sender, EventArgs e)
{
IRegion region = _regionWeakReference.Target
as IRegion;
Form frm = sender as Form;
if (frm != null && frm.Controls.Count > 0 &&
!region.ActiveViews.Contains(frm.Controls[0]))
region.Activate(frm.Controls[0]);
}

5. Algunas consideraciones finales


Para PRISM toda región tiene un solo contenedor (o target) que es aquel que se usa cuando se llama a AttachNewRegion. Aunque este RegionAdapter va creando distintos formularios, para PRISM la región debe estar vinculada a un único target… que debe existir cuando llamemos a  AttachNewRegion y cuyo tipo debe ser Form puesto que nuestro RegionAdapter trabaja con targets de tipo Form.


Esto nos deja en una situación curiosa, puesto que necesitamos tener un Form creado para poder crear la región. Aunque luego este formulario no contendrà ninguna de las vistas de la región. Consideraremos a este formulario el formulario padre, y cuando el formulario padre muera el RegionAdapter dejarà de tratar a la región (digamos que la región habrá muerto).


Otra cosa que también debemos solucionar es dado una vista, encontrar que formulario la contiene. El RegionAdapter no se guarda una lista de los formularios creados, en su lugar solo tiene una WeakReference al formulario padre (el usado para llamar a AttachNewRegion y que nunca contendrá vistas de esta región) y usa el formulario padre para encontrar a los formularios que contiene la vista. Esto es posible porque al crear un formulario que contiene una vista se indica que su padre es el formulario padre:

Form owner = _ownerWeakReference.Target as Form;
// Creamos un formulario por cada vista y lo mostramos...

frm.Owner = owner;

De este modo se puede usar la propiedad OwnedForms del formulario padre para iterar sobre todos los formularios creados y ver cual contiene la vista en cuestión.


Finalmente, el hecho de tener que pasar un formulario ya existente a AttachNewRegion, no es excesivamente problemático: lo más fácil es usar el formulario principal del programa!


Adjunto el programa de demostración. El RegionAdapter DialogRegionAdapter es el que muestra vistas en nuevos formularios, mientras que el RegionAdapter ControlRegionAdapter las muestra en paneles (de hecho en cualquier control).


Descargar el código de demostración.


Espero que os sea útil! :)


pd: Crossposting desde mi blog en geeks.ms :)

martes, 24 de febrero de 2009

Evento ALM: Como Team System cambió mi (ciclo de) vida

Hola a todos!

Aprovecho la ocasión para comunicaros un evento que organizamos en raona, en colaboración con Microsoft, sobre ALM en general y Team System en particular.

Lo hemos llamado “Como Team System cambió mi (ciclo de) vida”. Durante unas 4 horas y pico, Magda, Enric y yo mismo (sí, nada es perfecto y yo voy a estar… pero no sufrais, ya dejaré hablar a los que saben :p) vamos a comentar distintos aspectos de Team System. Empezaremos con una introducción y luego iremos viendo aspectos concretos (personalización, distintos clientes de foundation server, team build,…).

El evento será en Madrid el 18 de marzo y en Barcelona al dia siguiente (o sea el 19).

Enlace de la página del evento en raona

Enlace del registro para Madrid

Enlace del registro para Barcelona

Esperamos veros por allí!!! ;-)

Saludos!

Crossposting desde mi blog de geeks (como no :p)