To align my JFrame from righ-to-left, I use:
setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
but this works only if I use the following style (decoration) of the JFrame:
public class RightToLeft {
public static void main(String []args){
javax.swing.SwingUtilities.invokeLater(new Runnable(){
public void run() {
try { UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); }
catch (Exception e) { e.printStackTrace(); }
JFrame.setDefaultLookAndFeelDecorated(true);
JFrame frame = new JFrame("العنوان بالعربي");
frame.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
frame.setSize(300,300);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.setVisible(true);
}
});
}
}
but I want it to work without this decoration. How to solve this issue?
EDIT:
#mre I want a JFrame like this one:
EDIT2:
I really really need this issue to be fixed, so I offer 500+ to who will give a JFrame like this (with WindowsLookAndFeel):
The following explains what you observe through your code snippet:
ComponentOrientation is applicable only to Swing (and AWT actually) components.
When using JFrame.setDefaultLookAndFeelDecorated(true);, then the whole frame decoration is performed by Swing (the LookAndFeel itself in fact), so this works as expected.
If you don't set this option though, that means that the OS is in charge of the frame decoration, however the OS cannot be aware of the ComponentOrientation used by your Swing components!
I expect the OS (did you mention what OS you use exactly? It seems to be Windows 7 right?) to perform the correct decoration based on the currently selected Locale. Hence if you have an Arabic locale setup and selected on your OS, I guess all windows decorations are right to left. Did you try changing that Locale (through the "Region and Language" control panel)? Did it work?
Note: I don't think that you can change these OS settings directly from Java, but you can read them with Locale.getDefault().
To sum up:
first of all, you have to ensure that your OS is properly configured in terms of text orientation; sorry I can't help much here because I don't have any right-to-left languages installed on my Windows machine.
then, use the system look and feel and ensure that JFrame.setDefaultLookAndFeelDecorated(false);
if that doesn't work, then you may consider posting your code snippet, along with your system configuration to Oracle Java bugs list
What follows are extra notes on how to improve this part of your code (but this is not a fix for your issue)
By the way, if you let the user define its OS language preferences, then you shouldn't explicitly hard-code frame.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT); but rather use something like:
frame.applyComponentOrientation(
ComponentOrientation.getOrientation(Locale.getDefault()));
Where Locale.getDefault(), unless explicitly changed within your application, will return the OS-level currently selected Locale.
Also note that it is preferable to use applyComponentOrientation() rather than setComponentOrientation(), because the former recursively sets the given orientation to the whole hierarchy of components.
Finally, you will have to ensure in your windows that the LayoutManager used is right-to-left aware; this is normally OK with all standard Swing layouts, but not for all 3rd-party layout managers, if you use some.
#Eng.Fouad
just joke and this one ???...
code:
import java.awt.ComponentOrientation;
import javax.swing.JFrame;
import javax.swing.UIManager;
import org.pushingpixels.substance.api.skin.SubstanceOfficeSilver2007LookAndFeel;
public class RightToLeft {
public static void main(String[] args) {
javax.swing.SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
try {
//UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
UIManager.setLookAndFeel(new SubstanceOfficeSilver2007LookAndFeel());
} catch (Exception e) {
e.printStackTrace();
}
JFrame.setDefaultLookAndFeelDecorated(true);
JFrame frame = new JFrame("العنوان بالعربي");
frame.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
frame.setSize(300, 300);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.setVisible(true);
}
});
}
private RightToLeft() {
}
}
I suspect it has to do more with the OS. Normally (if you don't call setDefaultLookAndFeelDecorated) it is the OS that provides the frame decoration, not the LAF.
You should try changing your preferences in the OS to say you want right to left orientation.
Sorry, I don't know where those settings would be.
Once you do this, then you should be able to remove the call to setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
as the LAF will pick up the OS settings from the Locale.
EDIT
This Link describes how to enable right-to-left text on Windows 7. Then I think you would also need to change your locale.
It looks like the Component Orientation feature is not supported with the Windows LookAndFeel (at least not for the title bar)
Here is one posibility. This utility is designed for Mac users who have switched to Windows and want the window buttons on the left, but it should serve the same needs as yours.
This solution has nothing to do with Java (so I don't know if it's even acceptable for your needs) and sounds like it would be external to your application. I have not been able to try it out myself (I'm not running Windows), so I can't vouch for it, but it might be worth a try.
You only need to add this line of code and I am sure it works 100%.
frame.applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
Related
When vertically maximizing a window on my win7 64 bit machine by dragging the top or bottom edge of the window to the top or bottom portion of the screen respectively, the application becomes unresponsive and displays a black section or some other visual distortion. Does not happen when vertically maximizing by double clicking on the edge, or regular maximizing.
Since its happening with the Java Tutorial programs (I selected a few at random, and they all do it), is this some kind of bug in Swing - or is there something I can do?
This SSCCE shows the problem under Windows 7 (both 64-bit and 32-bit versions), compiled with JDK 1.7.0_07, running JRE 1.7.0_07:
public class Expander extends javax.swing.JFrame
{
public Expander()
{
this.setBounds(0, 0, 300, 300);
}
public static void main(String args[])
{
java.awt.EventQueue.invokeLater(new Runnable()
{
public void run()
{
new Expander().setVisible(true);
}
});
}
}
Problem appears to be that no resize event is passed to the content pane of the JFrame. The JFrame's paint method does get the new size, but nothing inside it does. Problem does not appear under version 1.6 (can't test it under Linux as, apparently, the auto-resize behavior is unique to Windows).
See http://www.coderanch.com/t/601457/GUI/java/Vertically-Maximizing-Window-Swing for a more detailed discussion. I have filed a bug report on this at bugs.sun.com.
I am using a system of the i7-2600k, ati radeon 6800 and win7 64bit and i've never had any such problems. Are you using the latest version of Java? I made the following program. It works fine on my system under without any problems.
Download link to JPositioner : JPositioner
Please check and let me know if u are facing the same problems even with JPositioner.
I'm developing a GUI for a moderately complex application using Java AWT for the GUI and it looks great when I run it in X11 (with any desktop manager) on linux but in Windows XP it looks weird.
Actually, at first it looks okay but if I need to change the background color of any of the frames, I can't change it back to the correct color afterwards. When I try to set the background color back to normal the frames get what looks like solid white backgrounds rather than the beige color that native applications have in XP. I can't seem to make them look more natural.
I've tried:
frame.setBackground(null);
and
frame.setBackground(java.awt.SystemColor.window);
with no success. Any suggestions would be appreciated.
Thanks in advance for any help!
-Jonathan Perry-Houts
Edit: Here's a quick example to demonstrate what I mean, I would expect this small empty frame to be beige but instead it's white in Windows XP:
import java.awt.*;
public class HelloWorld {
public static void main(String[] args) {
Frame f = new Frame("Hello World");
f.setPreferredSize(new Dimension(200, 200));
f.setBackground(SystemColor.window);
f.pack();
f.setVisible(true);
}
}
As stated in my comment... have you tried SystemColor.control? It should work! Be wary, however, when using SystemColor... it is a relic from a time when Motif and Windows 95-98 UI were predominantly used. More often than not, it will be utterly inadequate for dealing with modern UIs.
I am using the latest Eclipse, and GWT Designer, to make a swing application in Java.
The main function in my application window (which is a javax.swing.JFrame) in the auto generated by the tools looks like this:
/* launch the application */
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
public void run() {
try {
AppWindow window = new AppWindow();
window.frame.setVisible(true);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
This seems like a lot of noise around what could have been just this:
public static void main(String[] args) {
try {
AppWindow window = new AppWindow();
window.frame.setVisible(true);
} catch (Exception e) {
e.printStackTrace();
}
}
I have read that the EventQueue.InvokeLater technique is required in some situations, and another question asks where to use it here.
My question is simpler; Why do this automatically in the code generator here? Why should main return quickly and let the application window get created later by the event queue? Wouldn't blocking be exactly the point? Why is the JFrame auto-generated designer doing this EventQueue stuff? I have tried to see some difference in the start up and showing of forms whether this code is done the simpler way or the harder way, and I can only conclude provisionally that this has some benefits that are not visible in tiny demo apps made by beginners like me, and that perhaps in real-world large complex Jframe based classes, there is some benefit to this delaying/queuing strategy?
Depending on your application and how it's being used, it's possible that there could be something that is drawing on the screen (and thus using the EventQueue) before or during the call to your main method. Calls that modify any UI components should be made on the Event Dispatch Thread, and this includes setting the application visible.
So just to be safe, it's a good practice to start your application on the EDT.
Why do this automatically in the code generator here?
It won't hurt, it's easy to generate, and it's considered good practice.
Why should main return quickly and let the application window get created later by the event queue?
It's possible that the main method is being called from some other application that is using the EDT and may have already drawn something on screen. If you draw your application directly in main, it's possible that your application may be altering some component that is in the process of being handled by something on the EDT, and potentially already drawn on the screen.
So just to be safe in case this situation ever happens, you should leave it up to the EDT to draw your application so it can do it when it won't interfere with anything else.
Wouldn't blocking be exactly the point?
Unless something else is calling main other than the JVM process that your user started by double-clicking the desktop icon, it's not going to make a difference when main returns as long as there is something on the screen.
I can only conclude provisionally that this has some benefits that are not visible in tiny demo apps made by beginners like me
You're right - most of the time it's probably not gonna make a difference, but I presume they included it because it was easy to generate & implement, it can't hurt, and it would exemplify good practice.
1) why is building Swing GUI inside try-catch-finally, I can't see any reason(s) for that, split create non thread safe GUI and non thread safe code to the separates threads,
2) Swing isn't thread safe, then correct is in all cases that pack() + setVisible(true) would be
last GUI rellated code lines
wrapped into invokeLater
forgot for examples from some code ExamplesDepots, this forum, another forums, sure these code works, but with risk that whatever/everything could happen
correct Swing GUI launch
for example
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
public void run() {
AppWindow window = new AppWindow();
window.frame.setVisible(true);
}
});
}
3) is there some Serializable, Custom L&F then (better would be) wrap into invokeAndWait
I want to create a JDialog which can only float within its parent Frame. That is it cannot be dragged out from its parent frame. Any idea? mouse-motion listener?
thanks,
EDIT:
My applicaiton is based on frame not internal frame, so I cannot use JInternalFrame
I need a non-modal dialog so, I cannot use JOptionPane with internal feature.
Use JInternalFrame instead. See this page for an example.
Ok, you should have specified the "hidden" problem in the initial question.
I've have found a very tricky solution, I don't suggest to use it except from developing a better one, perhaps starting from this.
Given an JInternalFrame, provide it with a componentMove listener to inhibit moving it in hidden positions.
As far as I've tested it, it has refresh problems (maybe they can be solved) and the stability in extreme case to assess too.
Provided "as is" for further improvement, not as a nice piece of software :-)
public void componentMoved(ComponentEvent e) {
Rectangle r = new Rectangle();
MyInternalFrame mif = MyInternalFrame.this;
JDesktopPane dp = mif.getDesktopPane();
if (mif.getX() + mif.getWidth()> dp.getWidth()) {
mif.setLocation(mif.getDesktopPane().getWidth()-mif.getWidth(),mif.getY());
}
if (mif.getY() + mif.getHeight()> dp.getHeight()) {
mif.setLocation(mif.getX(), mif.getDesktopPane().getHeight()-mif.getHeight());
}
if (mif.getX()<0) {
mif.setLocation(0, mif.getY());
}
if (mif.getY()<0) {
mif.setLocation(mif.getX(), 0);
}
}
});
I have an app that sets a fullscreen frame but seems to minimize when the screensaver turns on. I want this app to be the only application that the users of the touchscreen kiosks can use so this is a problem. Is there anyway to prevent this?
The internet says that the cross-platform way to achieve this is to schedule keyboard events with this code:
import java.awt.Robot;
public void disableScreenSaver() throws AWTException {
Robot r = new Robot();
r.waitForIdle();
r.keyPress(KeyEvent.VK_CONTROL);
r.keyRelease(KeyEvent.VK_CONTROL);
}
and to schedule it to run every couple of minutes (e.g. with thread.sleep();). This way the screen-saver will not show up.
I have no idea, though, about a non-hackish, cross-platform solution, and I would be very happy to see one from someone who knows it :)
Another way is to add a window listener and reset state when it's deactivated:
frame.addWindowListener(new WindowAdapter() {
#Override
public void windowDeactivated(WindowEvent e) {
frame.setExtendedState(JFrame.MAXIMIZED_BOTH);
// or go to fullscreen mode here
}
});
But disabling screensaver might be the best thing to start with.
Probably (haven't tried it !) you'll get your answer by combining the answers to these questions:
Calling Win32 API method from Java
Need to disable the screen saver / screen locking in Windows C#/.Net
Of course this works only in Windows that's why I asked you about your OS :)