We Keep Coding

Java SWT - Scaled Background Image Not Working After Compiled

This is my code
shell.setFullScreen(true);
shell.setMaximized(true);
shell.setText("SD Cyber Cafe");
shell.setLayout(new FormLayout());
Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
Image oriImage = new Image(display, "C:\\Users\\LAPTOP-SYAMSOUL\\Desktop\\lockscreen_app\\main_bg.jpeg"); //should get from database
//System.out.println(screenSize.width);
Image newImage = new Image(display, oriImage.getImageData(100).scaledTo(screenSize.width, screenSize.height));
shell.setBackgroundImage(newImage);
When I run the app via eclipse, it works fine...
But after I exported to Runnable JAR the background Image is not scaled... why??
This is what I expected:
..
..
..
But currently it appear like below: ( I don't want this):

It is hard to say for sure from this code but Toolkit is a Swing/AWT method and should not be used with SWT. It may well be giving the wrong values.
Get the primary display size using something like:
Rectangle displayArea = shell.getDisplay().getPrimaryMonitor().getBounds();
which tells you about the main (primary) monitor or
Rectangle displayArea = shell.getMonitor().getBounds();
which tells you about the monitor on which the shell will appear (may be different if there are several monitors).

JavaFX Application with SwingNode doesn't maximise properly on some machines

I have a slightly complicated JavaFX GUI with the following component structure (simplified) as shown below. You will see that a SwingNode is used to contain the main bulk of the application, but I cannot tell you the design principle behind this since I didn't write the original code.
I am aware of various cautions about occasional odd behaviour when Swing & JavaFX are mixed, but there isn't the time at present to re-write the UI. The application is built to run on a Windows 7/8/10 platform, and what I'm seeing is as follows:
(a) On three different platforms I've tested (Windows XP native, Windows 7 VM, Windows 8 VM, different size monitors), when the application's Windows "maximize" decoration is clicked, the application resizes OK (by which I mean it is slightly jumpy and delayed, but the actual repainting to fill the screen is done correctly).
(b) However, on one further platform, the 'maximize' causes the entire content of the Stage to go white, and doesn't repaint properly until, say, a menu or one of its items is clicked. The machine in question is a Dell Optiplex 64-bit Windows 7 Pro SP1 with a DVI monitor of 1920 x 1080 sourced from an Intel HD Graphics 4600. ClearType is set to ON, and the version of Java is 1.8.0_73_b02.
There is one further question on SO regarding this issue, but it was created in June 2015 and never answered, so I'm not sure what to think.
Has anyone else come across this issue and/or feels able to comment on what might be causing it ? Is there some sort of 'revalidate/repaint' code, or JavaFX equivalent, which might be worth me trying as a workaround ?
public class Main extends Application
{
private SwingNode mainSwingNode = new SwingNode();
private JPanel mainPanel = new JPanel();
public void start(Stage primaryStage) throws Exception
{
BorderPane parent = new BorderPane(mainSwingNode);
Scene scene = new Scene(parent, 1024, 768);
// Build Swing components
SwingUtilities.invokeLater(() ->
{
createAndShowGUI();
mainSwingNode.setContent(mainPanel);
});
primaryStage.setScene(scene);
primaryStage.show();
}
public void createAndShowGUI()
{
mainPanel.setLayout(new BorderLayout());
// Setup canvas area & canvas rulers
mCanvasTabbedPane.setPreferredSize(new Dimension(800,600));
mainPanel.add(mCanvasTabbedPane, BorderLayout.CENTER);
menubar.initForActionsMap(menuActionsMap);
// Listen for property changes for site to enable/disable menus
ProjSingleton.getInstance().addPropertyChangeListener(menubar);
mainPanel.add(menubar, BorderLayout.NORTH);
// Setup show/hide sidebar button
btnShowSidebar = new JButton(menuActionsMap.get(ShowSidebarAction.class));
menubar.add(Box.createHorizontalGlue());
menubar.add(btnShowSidebar);
btnShowSidebar.setOpaque(false);
btnShowSidebar.setAlignmentX(JComponent.RIGHT_ALIGNMENT);
btnShowSidebar.setBorder(new EmptyBorder(new Insets(2,2,2,2)));
// Add site manager toolbar
sidebar.setLayout(new GridLayout(2, 0));
sidebar.setAlignmentX(JComponent.RIGHT_ALIGNMENT);
sidebar.add(siteManagementPanel);
sidebar.add(new JScrollPane(layerManagerView));
mainPanel.add(sidebar, BorderLayout.EAST);
Main.statusBar = new StatusBar();
Main.statusBar.setCanvasTabbedPane(mCanvasTabbedPane);
mainPanel.add(Main.statusBar, BorderLayout.SOUTH);
mainPanel.setVisible(true);
}
....
....
}

The script doesn't terminate after closing a created plot with JMathPlot

Although I am a beginner in java, I am trying to plot some data I have using JMathPlot.
Every thing went well, but the script didn't terminate after I closed the window of the plot.
Could any body tells me how to force the script to terminate when I close the window of the plot.
I use a debian machine(32-bit), IDE = eclipse, java-version = 1,6
and here is the code I'm using for plotting:
Plot2DPanel plot = new Plot2DPanel();
plot.addLinePlot("test", x, y);
JFrame frame = new JFrame("A test panel");
frame.setContentPane(plot);
frame.setVisible(true);
Thank you in advance

You termainate the process when closing the frame, not the panel.
This this:
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
Also see JFrame Exit on close Java

Sure!
frame.addWindowListener(new WindowAdapter(){
public void windowClosing(WindowEvent e){
System.exit(0)
}
});
What that does is, waits until the close button is pressed, then runs System.exit(0) which simply terminates your program.
Note: I wrote this on iPhone, so watch for syntax errors :)

Applet: Window opens with smaller size

I have an Applet program, which can be run from Eclipse directly for testing. I am setting window size of this Applet. But, I am seeing sometimes the applet opens with smaller window rather than the actual window size is set, and sometimes it opens with the proper set size setSize(550, 650);
I couldn't get fix for why sometimes it opens with the smaller window. Could someone advise me to fix this issue?
public class HomeApplet extends Applet implements ActionListener
{
public void init() {
titleStr = "Welcome to Application Home page!";
connectBtn = new Button("Submit");
connectBtn.addActionListener(this);
add(connectBtn);
connectBtn.setBounds(100, 120, 90, 20);
connectBtn.setEnabled(true);
setLayout( null );
setSize(550, 650);
sharedImage = new ImageIcon("sameer15.jpg" ).getImage();
}
public void paint (final Graphics g)
{
//super.paint(g);
int x = getSize().width;
int c1 = x/2;
Font titleFont = new Font("Arial", Font.BOLD, 20);
g.setFont(titleFont);
g.drawString(titleStr, c1-170, 20);
Font connectFont = new Font("Arial", Font.BOLD, 15);
g.setFont(connectFont);
g.drawString(connectStr, c1-190, 80);
g.drawImage(sharedImage, 100, 100, this);
System.out.println("drawImage");
}
}

Could someone advise me to fix this issue?
That applet can be tested in AppletViewer by including an applet element in a code block at the top of the source code.
I.E. change:
public class HomeApplet extends Applet implements ActionListener
To something like:
/* <applet code=HomeApplet width=550 height=650></applet> */
public class HomeApplet extends Applet implements ActionListener
Then to compile and run:
prompt> javac HomeApplet.java
prompt> appletviewer HomeApplet.java
Note
setSize(550, 650);
This is just plain wrong for an applet. The size of an applet should be set in HTML or by other means. The applet (which is effectively a guest in a web page), does not have the right to resize itself (that would be like your guest visiting, and knocking out a wall for 'a little more space').
Questions
These are not rhetorical questions. Another way to put that is: I expect to see answers to these questions.
Why code an applet? If it is due to spec. by teacher, please refer them to Why CS teachers should stop teaching Java applets.
Why AWT rather than Swing? See my answer on Swing extras over AWT for many good reasons to abandon using AWT components.
Future problems
sharedImage = new ImageIcon("sameer15.jpg" ).getImage();
You'll begin to discover just how wrong this is when you see AccessControlException in the Java Console when testing in Applet Viewer from the command line, or embedded in a web page. ..But we can deal with that in a separate Q&A. ;)

The simple answer in Eclipse is:
If you have multiple java classes open and you "run" the program from a class other than the one with init() and setSize(550,650) then the window will default to small.
Open the class with the setSize() and run it from there. Problem solved.
This drove me nuts until I figured it out.

JFrame gets decorated with Windows borders, even the Look&Feel is set otherwise

Good day everyone.
First of all: check this image.
Please note that in the first of the 3 frames, the button is styled with Metal Look and Feel, but the frame is Windows styled. The other 2 frames are "OK" in the sence that the button LAF matches the frame LAF.
The code for all of these (same order as the images):
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
JFrame frame = new JFrame();
frame.getContentPane().add(new JButton("button"));
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
});
}
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
JFrame frame = new JFrame();
frame.setUndecorated(true);
frame.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);
frame.setSize(100, 100);
frame.getContentPane().add(new JButton("button"));
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
});
}
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
try {
// 0 => "javax.swing.plaf.metal.MetalLookAndFeel"
// 3 => the Windows Look and Feel
String name = UIManager.getInstalledLookAndFeels()[3].getClassName();
UIManager.setLookAndFeel(name);
} catch (Exception ex) {
ex.printStackTrace();
}
JFrame frame = new JFrame();
frame.getContentPane().add(new JButton("button"));
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
});
}
Now what bothers me is that I have never been forced to use the lines frame.setUndecorated(true); frame.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);, as setting the Look and Feel just worked with the UIManager.setLookAndFeel() method. Normally, the JFrame itself would get styled too, but this seems not longer the case as I get a Windows styled frame (1st image, 1 code snippet).
Why is this? Is this new in Java 7? This seems really weird.
Normally, without touching code that involves Look and Feel, the program should start with the Metal Look and Feel, as this is the standard Java Look and Feel. So why does the first program start with a Windows frame?

Add this line in your main method before you init the JFrame
JFrame.setDefaultLookAndFeelDecorated(true);
I noticed the same thing a while ago when I started using substance but that line is all it took to fix it.
As the preceding code snippet implies, you must invoke the setDefaultLookAndFeelDecorated method before creating the frame whose decorations you wish to affect. The value you set with setDefaultLookAndFeelDecorated is used for all subsequently created JFrames. You can switch back to using window system decorations by invoking JFrame.setDefaultLookAndFeelDecorated(false). Some look and feels might not support window decorations; in this case, the window system decorations are used.
That's from Oracle in reference to that line of code.
This is a feature of Java, by default JFrame Window borders will not be decorated, but using the mentioned function allows the set look and feel to decorate the Window. This feature was implemented in 1.4 from what I can tell.
Edit:
Also, if you want to apply your custom look and feel to JDialog window borders, you can use the same static method on the JDialog class in the same place you called it on JFrame:
JDialog.setDefaultLookAndFeelDecorated(true);

I'm guessing that you hane not set the swing.defaultlaf system environment variable, but maybe you could check if your swing.properties is present and if it contains an entry swing.defaultlaf. This could be the reason, see below for how the UIManager chooses L&F.
I have the file present on my MacBook, obviously, as Apple wants the Apple L&F to be the default. But I have not checked a Windows machine yet..
Here's an excerpt from the Java 7 documentation which has been pretty much unchanged since Java 1.4. Java 1.4.2, Java 1.5, Java 6, Java 7:
Default look and feel
The class used for the default look and feel is chosen in the following
manner:
If the system property swing.defaultlaf is
non-null, use its value as the default look and feel class
name.
If the Properties file swing.properties
exists and contains the key swing.defaultlaf,
use its value as the default look and feel class name. The location
that is checked for swing.properties may vary depending
upon the implementation of the Java platform. In Sun's implementation
the location is ${java.home}/lib/swing.properties.
Refer to the release notes of the implementation being used for
further details.
Otherwise use the cross platform look and feel.