Develop Reference

how to make pop up overlay with my screen using java

Im trying to make a java program that will popup/notify me to stop what I am currently doing and do something. more like a reminder. My question is how will I make a pop up in java.
I found this docs, but dont know how to implement for the parent component.
JOptionPane.showMessageDialog(??,"this is a modal dialog.");

The answer depends, do you have a parent component (like a JFrame or other component) or are you simply display the JOptionPane independently?
If you are simply displaying the JOptionPane independently, you can simply pass it null.
If you are displaying the JOptionPane as part of a large application, with windows and other components, you can simply pass it a reference of what ever component you want the JOptionPane to displayed relative to, such as the window or most accessible container/component
The parent argument (if supplied) simply allows the dialog to act as a modal (blocking) dialog for the window which contains the supplied component. This requires the user to have to dismiss the dialog before they can continue to interact with the parent window/component
Take a closer look at How to Make Dialogs for more details

Design for a component with 2 listeners and 2 "setters" (Swing application)

I'm making a map editor using java swing for my tile based java game. the swing application has two major components, the "upper" component is the game map preview, and the "lower" component is modifyable properties of the map, like its height and width.
Currently the user types in to a jtextfield for the map width, then I use a change listener to set that value to the GameMap object. The GameMap object when changed fires a notification event to GameMapListeners, the primary listener it has is the preview display of the map inside the swing application.
This lets the user change the map width and instnatly see the results in a preview pane.
Now I want to go to the other way. I want the user to be able to click and drag the edges of the map in the preview pane, but then the results need to then be sent to the properties panel so it shows the updated width value.
This is where the problem is, if I update the jtextfield it'll fire a change event, which would update the GameMap and update the preview display, and then that would fire an event that changes the jtextfield again (so on and on until the program crashes due to stack overflow)
Are there any kind of design patterns i could use instead, or is there some common way to solve this issue?

In this type of case, you have at least two choices...
You Could
Remove the listener to the other component when you want to trigger a change, adding it back after you've raised the event...
You Could
Change the state of a flag to indicate that you should ignore any changes that might come in, resetting after you're raised the event...
Which one you choose will depend on how much code you want to add and how readily available the reference to the listeners in question are (ie, if you don't have a reference to the listener you want to remove, it's kind of hard to implement)

If I update the jtextfield it'll fire a change event, which would update the GameMap and update the preview display, and then that would fire an event that changes the jtextfield again (so on and on until the program crashes due to stack overflow).
When you have a situation like this, you can temporarily remove event listeners, fire the change event, and add the event listeners back. Yes, this is as much of a pain as it sounds, but it's a good way to prevent the stack overflow.
You can see a detailed explanation as well as a working example of managing event listeners in my Sudoku Solver Swing GUI article.

You can use action events for a JTextField. Action events don't trigger when you change the component programmatically.

SWT disable window causes lose focus

I'm making custom dialogs that I want to pop up and disable the main shell behind it so that it cannot be clicked while the dialog is active.
My initial plan was something like as follows:
shell.setEnabled(false);
doDialogStuff();
shell.setEnabled(true);
this worked but as I close the dialog, it loses focus of the shell that was open before the dialog. I managed to sort of fix it by adding
shell.setFocus();
after the last line but this is messy and causes the screen to flicker as the window loses and then gains focus in a split second, also, it sometimes doesn't regain focus and I can't understand why :/
Is there a better way to disable the background window without it losing focus.
Thanks in advance SO peeps

You should create a custom dialog based on this tutorial.
This way you just have to set the modality of the dialog to whatever you need exactly and the dialog will take care of the rest for you.
This should be helpful as well (Javadoc of Shell):
The modality of an instance may be specified using style bits. The modality style bits are used to determine whether input is blocked for other shells on the display. The PRIMARY_MODAL style allows an instance to block input to its parent. The APPLICATION_MODAL style allows an instance to block input to every other shell in the display. The SYSTEM_MODAL style allows an instance to block input to all shells, including shells belonging to different applications.

The proper thing to do is create the dialog as a modal window. When you create the dialog's shell you should do something like
dialogShell = new Shell(mainShell, PRIMARY_MODAL | DIALOG_TRIM);

Make a JDialog stick or snap to another one when moving it close to it

I'm trying to reproduce a feature I've seen on several apps:
I have a GUI app with several JDialogs.
I'd like to easily organize them tightly on screen:
when I move one JDialog, and one of its borders gets "close" (within 5 pixels for example) to another JDialog, I'd like it to automatically snap and stick right along it.
any idea how to achieve that ?

Add a ComponentListener to the dialog and listen for the comopnentMoved() event.
You can use the Window.getWindows() method to get all the Windows. Then you loop through the Windows and get the bounds of each window. Whenever you are near a window you manually set the size of the window you are moving.
Of course you will also need to handle the situation when you want to move the window away from another window so maybe you need to start a Timer with every componentMoved event and only manually position the window after events have stopped being generated.

Reusing Swing components which are time-consuming to initialize

If I have a massive Swing component in my application which takes a long time to initialize, and want to display this component in different places in my GUI at the same time, how would I preferably do this?
The GUI user must be able to interact with the different copies of the component
(they could, for example, work as mirrors).
Let's assume that one might want to display copies of this component dynamically, depending on the input of the GUI user (that is, we do not want pre-loading of many copies of the same component).

You need to change your components to access data in a model-view like fashion. Each component would need to point to the same model that would server up the data and do the intensive task once rather than multiple times.
Also, initialization is slowing the GUI, then it sounds like you need a splash screen or a progress bar and the task moved off the EDT.

Is there any way that you could pull the heavy-duty initialization code out, maybe into a '...Factory' class?

I would create a one instance of the component (let's say HeavyComponent) and a custom class extending e.g. JPanel and referencing the component. Let's name it MyContainer. On paintComponent() of the MyContainer I would draw original component into a BufferedImage or use heavyComponentReference.paint(g).
Then on click by the MyContainer I would swap the component replacing the panel with real instance of HeavyComponent and placing in the old location of the HeavyComponent new instance of MyContainer.

display this component in different
places in my GUI at the same time ...
without having to create a new copy of
the same component ... user must be able to interact with the different copies
No way.