J'ai un étrange problème. J'utilise la disposition null pour une fenêtre (= JFrame et sur windows) et si j'utilise setResizable (false), la taille de la fenêtre devient plus grande (à droite et en bas, environ 10 pixels, je dirais). Je ne sais pas pourquoi.
Les deux imprimantes retournent les mêmes tailles, ce qui est étrange, aussi ...
mainWnd.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
mainWnd.setTitle(wndTitle);
mainWnd.setBounds(wndPosX, wndPosY, wndWidth, wndHeight);
System.out.println(mainWnd.getHeight() + mainWnd.getWidth());
mainWnd.setResizable(false);
System.out.println(mainWnd.getHeight() + mainWnd.getWidth());
Est-ce que quelqu'un a une idée? Pourquoi la fenêtre est-elle redimensionnée?
UPDATE: Même chose ici (compilez-le avec et sans le setResizable et que vous pouvez le voir, si vous chevauchez les fenêtres):
import javax.swing.JFrame;
import javax.swing.JPanel;
public class Main
{
private static JFrame mainWnd = null;
public static void main(String[] args)
{
mainWnd = new JFrame();
mainWnd.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
mainWnd.setTitle("asda");
mainWnd.setBounds(50, 50, 300, 300);
mainWnd.setResizable(false);
mainWnd.setVisible(true);
}
}
Cela ne change pas sur mon exemple, vous devez donc avoir autre chose qui cause votre problème:
import javax.swing.JFrame;
import javax.swing.SwingUtilities;
public class Test4 {
protected static void initUI() {
JFrame frame = new JFrame("test");
frame.setBounds(0, 0, 300, 200);
frame.setVisible(true);
System.err.println(frame.getSize());
frame.setResizable(false);
System.err.println(frame.getSize());
}
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
initUI();
}
});
}
}
EDIT/UPDATE:
Les encarts sont en quelque sorte incorrects lorsque vous définissez la valeur redimensionnable sur false (au moins sous Windows 7 et JDK 6). Ils changent en quelque sorte de 30,8,8,8 à 25,3,3,3 bien que la frontière (peinte par le système d’exploitation) reste en réalité la même. Comme les incrustations font partie des limites du cadre, celui-ci est trop grand (visuellement) lorsqu'il n'est pas redimensionnable. Pour moi, il semble y avoir un bogue dans les encarts calculés lorsque le cadre n’est pas redimensionnable.
Si vous définissez setResizable false avant de définir les limites, le problème ne se pose pas. Comme Gergely Szilagyi l’a déjà déclaré, vous vous débarrassez des barres de défilement, mais la taille de la fenêtre est verrouillée et vous obtenez donc 9 ou 10 pixels d’espace supplémentaire dans le cadre. Je viens d'avoir le même problème. Merci pour l'aide.
En fonction du paramètre L & F, le redimensionnable (false/true) peut changer les décorations des bordures de fenêtre. Pas de maximisation, pas de flèche de redimensionnement. Cela même peut changer la taille.
Remplacer:
frame.setResizable(false);
à:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
frame.setResizable(false);
}
});
Eh bien, j'ai rencontré ce problème et c'est un problème de Look & Feel ...
Pourquoi le cadre redimensionnable a-t-il des incrustations de (5, 5, 5, 5)? Cela me porte à penser que le redimensionner ajoute un composant supplémentaire autour du cadre, comme ... une sorte de "gestionnaire" à faire glisser pour redimensionner ?
Et puis, j’ai trouvé que si nous utilisons les valeurs par défaut de Java Metal l & f et que nous définissons setDefaultLookAndFeelDecorated(true)
, le gestionnaire sera peint et, par conséquent, le cadre ne changera pas de taille. Mais dans Nimbus, Motif et Windows L & F, ce point n’est pas implémenté, c’est donc un bug. Je vais le signaler.
Ma propre question et ma réponse avec GIF sont ici:
Swing - setResizable (true) augmente la barre de titre JFrame et réduit la taille de la fenêtre
J'ai 2 sous-classes JFrame définies. Si j'exécute le cadre problématique dans une application autonome, la taille du cadre est correcte. Si je lance les deux cadres dans une application autonome, le problème est encore plus grand. J'ai mis setResizable (false) avant pack, et j'ai toujours le problème. Ma solution de contournement consistait à modifier la mise en page en BorderLayout et à placer le panneau (image) au centre, puis à définir setResizable.
Jusqu'ici, le meilleur correctif pour ce problème ennuyeux est le suivant. Peu importe où vous appelez la méthode setResizable(false)
. Ajoutez simplement ce morceau de code après votre setVisible(true)
.
private void sizeBugPatch() {
while (frame.getWidth() > yourWidth) {
frame.pack();
}
}
Où yourWidth
est le width que vous avez défini de différentes manières, soit manuellement, soit en surchargeant les méthodes setPreferredSize
. L'explication est assez simple, frame.pack()
semble réinitialiser frame.setResizable(boolean b)
en quelque sorte. Vous pouvez utiliser une variable if
au lieu de la boucle while
mais je préfère while
pour exclure le cas où la fenêtre serait encore plus grande, même après une seconde pack()
.