[Gvsig_desarrolladores] Visibilidad frames layout

Fernando González fergonco en gmail.com
Lun Dic 5 08:33:17 CET 2011


Hola Jorge, gracias por la respuesta. Te contesto:

2011/12/5 Jorge Piera Llodrá <jpiera en gvsig.com>:
> Hola Fernando.
>
> Cuando dices que tienes que poder ocultar un IFFrame entiendo que te
> refieres a poder hacer que cualquier IFFrame pueda ser visible o no, una
> vez que ya ha sido añadido al Layout. Para ello habría que añadir algo
> de UI para poder modificar esa propiedad.

Sí, enlazo la visibilidad del IFFrame con la visibilidad de una capa.
Tengo dos entradas en el menú contextual (enlazar y quitar enlace).

>
> Los 4 métodos que comentas:
>
> - print: se utiliza para imprimir a PDF o PS.
> - draw: se utiliza para imprimir el componente en el mapa
> - drawDraft: simplemente dibuja un rectángulo gris con el tamaño del IFFrame
> - drawHandlers: dibuja los cuadrados negros que están en los bordes del
> componente y que sirven para cambiar su tamaño.
>
> Si modificas los 4 métodos de la clase FFrame para que en función de una
> variable dibuje algo o no, una vez que hayas puesto el componente en
> "invisible" ya no lo vas a poder ver y no se me ocurre cómo lo vas a
> poder volver a poner en "visible" (podrías hacer una ventana que te
> muestre los componentes del mapa).
>
> Yo creo que el drawHandlers y el drawDraft los deberías dejar tal y como
> están, y simplemente modificar el draw y el print. Así siempre vas a
> poder ver dónde están los componentes. Podrías meter en el menú
> contextual del mapa una nueva opción "Hacer visible".

Vale, sólo draw y print. Ya hay un menú contextual para eliminar el
enlace y así que el fframe vuelva a ser visible.

Ojo, no estoy implementando la funcionalidad para que el usuario pueda
mostrar u ocultar un fframe a voluntad (como en otros programas de
diseño vectorial). Mis necesidades se limitan a que esto se pueda
hacer por código, que es un paso en esa dirección pero no llega del
todo.

Si en un futuro se quiere hacer lo anterior, simplemente hay que
añadirle los menús correspondientes y hacer la propiedad visible
persistente.

En cualquier caso, me han comentado que había una extensión de arcview
que lo hacía, así que imagino que también tendrá su utilidad.

>
> La solución que propones me parece razonable pero vas a tener que tocar
> todas las implementaciones de IFFrame para meter los nuevos métodos.
> Otra opción con menos impacto podría ser modificar las llamadas a los
> métodos print y draw (en principio deberían ser muy pocas, pero habría
> que mirarlo) para que el que llame a estos métodos tenga en cuenta en
> "isVisible" del IFFrame para dibujarlos o no.

De tu manera se modifican menos clases, pero se "copypastea" código en
varios sitios, al menos en el layout y el fframegroup. Mi
implementación minimiza el código repetido. Me da igual. Si no me
decís nada, me decanto por la tuya.

>
> Un saludo,
> Jorge.

Un saludo.

P.S.: Quería comentarte cosas de netcdf, con el que me estoy dando de
guantazos últimamente, pero fue sacar el jamón e írseme totalmente de
la cabeza xD. En fin, para girona igual tenemos la oportunidad...



>
> On 12/04/2011 11:21 AM, Fernando González wrote:
>> Hola, me han encargado realizar un desarrollo sobre la 1.11 en el que
>> tengo que poder ocultar un IFFrame pero me parece que esto no es
>> posible, por lo que voy a tener que modificar código de gvSIG. No es
>> necesario que sea persistente en disco.
>>
>> ¿Alguna sugerencia de cómo sería mejor afrontar esto?
>>
>> Por lo que he podido ver, en IFFrame hay 4 métodos para "dibujar":
>> - print
>> - draw
>> - drawDraft
>> - drawHandlers
>>
>> El objetivo puede ser meter un método setVisible(boolean) tal que si
>> se le pasa un "false" ninguna de las llamadas de dibujado anteriores
>> tenga efecto.
>>
>> La idea que llevo es la siguiente:
>>
>> - Crear 4 métodos abstractos en FFrame:
>>    - doPrint
>>    - doDraw
>>    - doDrawDraft
>>    - doDrawHandlers
>> - Hacer que todas las implementaciones de FFrame implementen estos 4
>> métodos en lugar de los 4 originales.
>> - Implementar los 4 métodos originales en la clase padre (FFrame)
>> teniendo la visibilidad en cuenta y delegando en caso de ser visible
>> en los 4 métodos abstractos doXXX.
>>
>> ¿A alguien se le ocurre una manera mejor?
>>
>> ¿Qué posibilidades hay de incluir esto en el código de gvSIG?
>>
>>
>> Saludos.
>> _______________________________________________
>> gvSIG_desarrolladores mailing list
>> gvSIG_desarrolladores en listserv.gva.es
>> Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>>
>
>
> --
> Jorge Piera Llodrá
> gvSIG software architect
> PRODEVELOP
> e-mail: jpiera en gvsig.com
> http://www.prodevelop.es
> http://www.gvsig.org
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores


Más información sobre la lista de distribución gvSIG_desarrolladores