29 June, 2009

Api gxt rc1: cierre y ocultamiento de ventanas

Pasamos a probar la nueva rc1 de gxt2.0.

Sorpresón, las ventanas ya no se cierran, solo se ocultan, y claro esto ya ha provocado debate. Explican que ellos las eliminarán completamente en cuanto se pierda la referencia. Hasta aquí (aunque no acabo de entender el porqué del cambio, bien podrían haber mantenido el close por si la quiero destruir yo mismo! e implementar igualmente el mecanismo de liberación de memoria de los objetos no usados) tampoco voy a reprocharles nada.

Ahora, tengo una ventana, con los 3 típicos botones: minimiza, maximiza, cierra. Necesito de alguna forma distinguir el evento de cierre del de minimizar. Hasta ahora simplemente se implementaban 2 listeners diferentes: windowHide, windowClose. Pero como decimos windowClose desaparece, hemos de buscar otra forma alternativa de diferenciar entre un cierre y un hide, y por defecto el evento generado por botón close de las ventanas no nos da el botón que hemos pulsado, supongo que se les ha escapado.

Finalmente veo 2 opciones:

La primera y mas sencilla es pasar algún parámetro a la ventana en el momento del ocultamiento/mimización (navegando a los fuentes del sistema MDI que implementa gxt veo que esta es la opción que utilizan), por ejemplo:

  1. setData("minimize", true);

y ya en el evento hide comprobar si la ventana ha sido mimizada o por el contrario está cerrada.

  1. public void windowHide(WindowEvent we) {
  2.    boolean minimize = getData("minimize");
  3.    if(!minimize)
  4.    {// Si minimize es false es que la hemos cerrado =>
  5.      // hacemos lo que necesitemos, por ejemplo eliminar un boton de la barra de tareas
  6.    }
  7. }

Y la segunda:
Ya que como deciamos el evento generado por el botón close de la ventana no nos ofrece el botón pulsado, vamos a ocultar los botones por defecto de la ventana y añadir los nuestros.

Primero ocultamos los botones "por defecto":

  1. setMinimizable(false);
  2. setMaximizable(false);
  3. setClosable(false);

Ahora añadimos nuestros propios botones, y para close nuestro propio evento pasando un botón (creado exclusivamente con este fin) al método hide, ya que hide solo puede recibir Button y no ToolButton:

  1. final ToolButton closeBtn = new ToolButton("x-tool-close");
  2. closeBtn.addListener(Events.Select, new Listener<ComponentEvent>() {
  3.    public void handleEvent(ComponentEvent ce) {
  4.       // Buff, el hide solo recibe un Button no un ToolButton, q coñazo!! =>
  5.       // creamos un botón simplemente para pasarlo como argumento
  6.       // y saber que estamos cerrando la ventana
  7.       Button buttonCloseTmp = new Button("close-window");
  8.       buttonCloseTmp.setId("close-window");
  9.       hide(buttonCloseTmp);
  10.    }
  11. });
  12.  
  13. window.getHeader().addTool(closeBtn);

Y ahora si, en el evento generado por el ocultamiento de una ventana podemos diferenciar cuando la estamos cerrando o cuando la estamos enviando por ejemplo, a la barra de tareas:

  1. @Override
  2. public void windowHide(WindowEvent we) {
  3.    if (we.getButtonClicked() != null) {
  4.       if (we.getButtonClicked().getId().equals("close-window")) {
  5.          // sabemos que hemos pulsado el botón de cierre de la ventana =>
  6.          // hacemos lo que necesitemos, por ejemplo eliminar un boton de la barra de tareas
  7.       }
  8.    }
  9. }

En fin, que no acabo de entender porque eliminan la funcionalidad del close, como decía sería mejor mantenerla e implementar además el mecanismo de liberación de memoria. Se mantendría la compatibilidad y podríamos diferenciar de una forma mas lógica y fiable cuando se produce el cierre, ya que son dos operaciones claramente diferenciadas.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

Para proteger este sitio del dichoso spam responde a esta pregunta y antes de enviar tu comentario

Powered by WordPress
Bajo licencia Creative Commons
Contacto sanroman.javier at gmail.com