El orden de los factores, en efecto, altera el producto

[NekroByte]

El asunto es así: una clase extends Frame:

Si pongo esto:

Código (java) [Seleccionar] Expandir

public Prueva(String title){

super(title);

wndListener Eventos = new wndListener();
addWindowListener(Eventos);

button = new Button("Heisann!");
button.setBackground(Color.MAGENTA);
  add(button);
button.setLocation(64, 64);
button.setSize(64, 64);

setBackground(Color.CYAN);
setSize(256, 256);
setVisible(true);

}

Me aparece una ventana de 256 * 256 con un botón de comando de 256 * 256 (cubriendo toda el área), pero si pongo esto que es el mismo código pero con los dos últimos párrafos permutados:

Código (java) [Seleccionar] Expandir

public Prueva(String title){

super(title);

wndListener Eventos = new wndListener();
addWindowListener(Eventos);

setBackground(Color.CYAN);
setSize(256, 256);
setVisible(true);

button = new Button("Heisann!");
button.setBackground(Color.MAGENTA);
  add(button);
button.setLocation(64, 64);
button.setSize(64, 64);

}

Me aparece una ventana de 256 * 256 con un botón de 64 * 64 en su respectivo lugar.

Me he dado cuenta que es el método setVisible(boolean) que mi clase ha heredado de Frame, si llamo a ese método como lo hago en los dos casos para hacer visible mi ventana, se me redimensiona el botón dependiendo de dónde esté el código, si no lo llamo simplemente no aparece nada.

Mi pregunta, ¿por qué ese setVisible(boolean) redimensiona el componente de mi Frame? Se supone que eso es trabajo mío y no debe ser la máquina quien decide que se hace.

De ser así imaginen si tengo que crear un Frame con muchos objetos dentro: tendría que hacer visible la ventana y luego ir creando los objetos y acomodándolos y Java no es muy rápido que digamos.

[Yshua]

lo más seguro es q el frame esté usando un layout, el BorderLayout es el defecto. los Layouts, generalmente redimensionan los componentes para mantener el orden. todo depende. y el setVisible, en varias ocasiones cambian los resultados segun la posicion, cuestion de paint y repaint.

Pd:Prueba es con B no con V, se ve feo 

Pd2: en la programacion el orden de los factores si altera el producto es parte de ella

[NekroByte]

Pd:Prueba es con B no con V, se ve feo

No, desde la última asamblea del 2006 en Madrid se escribe con "V".

Pd2: en la programacion el orden de los factores si altera el producto es parte de ella

Sí, se me pasó que aquí así eran las cosas.

Voy a ver eso de los layouts porque algo leí sobre ellos pero es casi nulo, y lo de la RAE era una broma.

Gracias por tu respuesta.

[NekroByte]

Gracias, Yshua, ya le agarré la onda a esto de los Layouts y pude solucionar mi problema, aunque tú dices que BorderLayout es por defecto resulta que yo lo he compuesto asignándole un BorderLayout. He aquí la sustitución (no lo pongo en [ code] por las negritas):

setBackground(Color.CYAN);
      setSize(256, 256);
      setVisible(true);

setBackground(Color.CYAN);
      setSize(256, 256);
      setLayout(new BorderLayout());
      setVisible(true);

Estuve probando con otras clases que implementaron la interfase LayoutManager que encontré en la documentación de Sun y mientras algunos me lo dejaban igual y otros diferente, este fue el único que se apegó a lo que especifiqué en el código; es por ello que me extraña si dices que BorderLayout es el organizador por defecto.

Aclaro que probé también asignando el layout después de setVisible() seguido de un repaint() pero me lo dejó igual del tamaño de la ventana, osea mal (bueno, mal para mí, porque para el compilador pues no).

Saludos.

[Yshua]

si hay errores de compilacion de ejecucion o simplemente errores de programacion q nos dan resultados indeseados sin lanzar excepcion alguna. lo de los layouts bueno si estaba mal en cual es el defecto de realmente es el flowlayout el defecto. y en este el tamaño depende del tamaño del frame y del prefered size del elemento basicamente, ademas de algunas propiedades q se le pueden dar como center o algo por el estilo. todo es cuestion de estudiar cada layout.