Combobox with present mode

i have an app that is quite ok; it s a very long and complicated thing but it runs, through a server and with multiple clients && rooms.

I have tested it in a lot of situations; as everything looks fine now i try to export it. If i export it “normally” not any (new!) problem; but i would like (for desktops) to export in present mode.
But if i do so i get a lot of big problems because the app is using multiple JComboBoxes (!editable) with lists (of players, of rooms…); so = if i set the JCombo loc outside of the app i get (MACOSX, sierra) a kernel panic and must restart the computer… but that is not done because even after restarting the app is always here and blockink every action or menu…Of course the stop button does not work…Solution is restarting again and using command line delete the app: not very confortable! -
After that i decided to give to my combos a location inside the app: no more krash and the combos appear at the beginning…Super! except that when you click on the app (and it s needed!) the combos disappear behind the app and i cannot see how to put them in front of the main window. I suppose that all these things are caused by the way P5 makes its present mode (A JFrame???) - anyway my question is : is it possible to use combo (or other java elements like that) with present mode P5. BTW that is probably a question for Peter Lager…
Below a code snippet in order to experiment. Dont change the loc of the combo if you want to avoid the kernel panick!

import javax.imageio.ImageIO;
import javax.swing.ImageIcon;
import javax.swing.JLabel;
import java.awt.Graphics;
import java.awt.Image;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Toolkit;
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JFrame;
import javax.swing.JComboBox;
import javax.swing.JPanel;

JComboBox comboConnectes;
String[] items = {"one", "two", "three"};
JFrame frame;
float xcombo =0;

import java.util.Iterator;
import java.util.HashSet;

void setup(){
  xcombo = (displayWidth/2)-612;

public void creeCombo() {
  comboConnectes = new JComboBox(items);
  comboConnectes.setBounds(5, 5, 140, 30);
  Color colo =new Color(175,104,12);
  comboConnectes.addActionListener(new ActionListener() {

      public void actionPerformed(ActionEvent event) {
      JComboBox<String> combo = (JComboBox<String>) event.getSource();
      String selectedJoueur = (String) combo.getSelectedItem();
      println("le joueur choisi est====" + selectedJoueur);
  frame = new JFrame ();
  frame.setPreferredSize(new Dimension(150, 600));
  frame.setContentPane(new PanelFond());
  frame.add (comboConnectes );
  frame.pack ();
  frame.setLocation(int(xcombo+210), 140);
  frame.setVisible ( true );

public class PanelFond extends JPanel
Image image;
   public PanelFond()
     try{ File(dataPath("")+"/combofondgris.png"));
     }catch (IOException e){
       println("je trouve pas l'image");
   public void paintComponent(Graphics g)
     g.drawImage (image, 0, 0, null); // elle doit etre avant
     //super.paintComponent(g); // lui il s'occupe de redessiner les composant enfant.

ps+++ sorry but my combo is using an image: the name(“combofondgris.png” and size are in the code and you can put what you want instead of mine

This sounds terrible! It also sounds like perhaps a Java / MacOS or Java / FreeBSD issue. Perhaps…?

thanks for replying (this topic has had only one answer: yours! - and yet, when it happens it s rather impressive…) - The first link you provided describes something which seems to be similar: necessity of restarting the computer and killing the process), yet it speaks about actions performed with the JCombo : in my case not any action is performed it s when the JCombo is created that the panic starts, in present mode && when i put its loc outside of the PApplet window: so i think that it could be of interest to look at this “present mode” more in details; as for now i suppose that it is a JFrame (with display size and loc(0,0) to which all other components are added. If it is i can understand what happens: when i put the JCombo inside the app window and before it, processing puts it behind and does not add it to the JFrame, so it disappears and is unreachable; and when i put it outside, as the JCombo is itself added to a JFrame, i suppose that there is some kind of incompatibility. If this is true what work around, i am thinking to that…

Glad that was helpful – good luck!

The issue may be in part that very few forum members mix using javax.swing with their Processing. Instead, they often use combo box elements from e.g. G4P or ControlP5.

It is also the case that a bug that causes a kernel panic isn’t something many people are excited to help test, unless they are core / library maintainers. In this case, it currently seems like this is likely a swing issue, not a Processing issue, so I also doubt you will be able to get much help from posting to Processing github issues (although you could always try) unless you have more information from inspecting the output. Even if there is a problem with the preprocessor, swing should NOT be kernel panicking…

i agree with you && as it works (with my combo) in debug mode or exporting not full screen in some sense that is not a P5 issue; yet it involves clearly the P5 present mode that i have already verified to be weird in some conditions (images repeated a lot of times, i have posted to github about that and seen that i am not the only one to have encountered this issue) - That s why ASAP i ill get a look to the source code for it… As for using G4P or ControlIP5, sorry, but i am not able with these libs to make a combo like i have done with swing! - More: i am not sure (i have to try) that you can set the loc of the combo OUT of the main window and even if it s possible that exporting (present mode) causes the same kind of problems…

You seem to be using Swing components inside the Processing IDE.

If that is is true then you have a problem because you will get conflicts between the two event handling mechanisms, Processing vs Swing

You have the main Processing window (800 x 600) and a second JFrame (150x600) with your combo box. I am not sure what you mean with

if i set the JCombo loc outside of the app i get (MACOSX, sierra) …

Do you mean outside the JFrame or something else? Can you show the code that causes the Kernal panic?

OK you also say

which suggests you are adding the combobox to the main Processing Window.

While you think on that I have a few observations.

  1. You must not add Java Swing components to the main sketch display window. Or more accurately if you could then you have a single application with 2 different event handling mechanisms, Processing’s and Java Swing’s. This will result in conflicts likely to crash the application.

Your code above works because you are segregating the Swing components in their own JFrame. You can visualise this as two linked applications each using its own event handling mechanism. This will work but each window has its own main-event-handling thread so there is a risk on modifying concurrent data exceptions.

  1. If the main Processing window is set to presentation mode then it will not only occupy the fullscreen but it will become the ‘topmost’ window covering all other windows. So the combo frame will not be visible, that is normal.

  2. The code comboConnectes.setBounds(5, 5, 140, 30); is setting the position of the combo using absolute coordinate positions. This is not the usual way to position Swing components, normally you use layout managers so the components’ position and size can be set if the window size is changed.

I should point out that I haven’t used presentation mode with Processing so what I have said is based on general knowledge and experience gained over the years.

1 Like

thanks for replying; i try to be more precise:

  • the code i have put is only a nippet with which you can reproduce what i have seen. But i have to add that, in the “real app” the events handling mechanism is not the same: my combo (on itemSelected) sends a message through a server to the app; it does nothing else (except modifying its list when it receives some other message from the server) - As for the size and loc in the app they are not fixed like in this snippet: the combo is movable and resizable. I have tested that for many months in debug mode and never got any problem.

  • In the app the combo is located OUTSIDE of the main P5 window and its initial coordinate are set relative to the display, let us say somewhere in the topleft corner: that is mandatory because at each moment a) the user has to see it b) it must not offuscate the main window

  • then when i export the app in “normal mode” ( i mean not in present mode) everything is working fine: i have my main window && my combo list.

  • the problem arises when i export in present mode, leaving all params as they are: combo top left corner: here everything krashes and i have to restart the computer…and kill the app by command line because on restart the app is still present in the absolute foreground, its stop button dose not work and i cannot acceed any menu.

  • seeing that i have tried to change the loc of the combo: instead of putting it OUTSIDE of the main window i have put it at the topleft corner of the main window; that has not any interest for my aim but it was to explore and experiment. In this case not any crash && at the very beginning (not any mousEvents) my combo is present, exactly where i have put it, except tat at the first click over the main window it disappears BEHIND it (not any krash) and is absolutely useless.

  • As for now i am only sure that the problem is with the present mode which perhaps does not accept 2 JFrames (as it is in my case) or…That is why i have now to look to the source code for the present mode. I guess that it creates another JFrame then add the main window to it and in front of it but cannot understand what to do with the JFrame combo…

I decided to have a look at Present and fullScreen modes.

The Present modes simply hides the desktop and any open windows. It is possible to bring another window to the top using cmd + tab (on the mac, not sure what it is on Windows) but they disappear again when you click on the main sketch. BUT that is what is expected in Present mode.

In your description you are still not being clear about positioning the Combo box e.g. you say

but a combo box can only be added to a windowed component e.g JFrame or JPanel, do you mean the JFrame containing the Combo was located outside the main PS window?

There is no forum member called quark===, you need a space after the k to get my attention :grinning:

@quark ===

yes, that is exactly what i mean: i create the combo with its items and so on, then i create a JFrame same dimension than the Combo and using my class PanelFond add to it a an image as background.
After some researches i see now that the problem is not with the JCombo but with the JFrame: you can easily verify it creating a JFrame in the most standard Java way and try present mode or ! present mode; trying that i decided to add to my JFrame .setAlwaysOnTop(true): and miracle it works in present mode…Even with exporting ! Code snippet below;
ps1= tried with the combo: same (good!) result…
ps2 = i dont understand why you say that it is not a good idea to use swing components inside P5?

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
JFrame frame;

void setup(){

void draw(){

    private void creeGUI() {
        //Create and set up the window.
        frame = new JFrame("i am a j frame");
        JLabel emptyLabel = new JLabel("");
        emptyLabel.setPreferredSize(new Dimension(175, 100));
        frame.getContentPane().add(emptyLabel, BorderLayout.CENTER);
     public  void lance() {
        javax.swing.SwingUtilities.invokeLater(new Runnable() {
            public void run() {
    public void mouseReleased(){
        frame.setVisible(true);//if the user hides the frame clicking the close button

You got my attention :wink:

I am not sure how clearer I can make the explanation, but here goes :grin:

If you run a Processing sketch using JAVA2D then the window opened will be a JFrame. The running sketch will have a main-animation thread to handle rendering and event handling and managed by the Processing core. For instance it will catch mouse events and call the appropriate event handler, for example

void mouseClicked(){
  // called by Processing to handle mouse click events

Since the main application is inside a JFrame then it is possible to add Swing components directly to this frame. This is not recommended and should be avoided.

The reason being is that it would create a second event-handling thread a Swing one. The two event-handling mechanisms, Processing and Swing, would conflict.

@quark ===

thanks a lot: now i understand what you are explaining; and of course it not at all a good idea to add Swing components to the main P5 jFrame, i agree absolutely : but as you have noticed that is not what i am doing: i create another independant JFrame and, putting it OUTSIDE of the main one and topLevel ordered; in this condition it seems to me that there cannot be any concurrent exception (though i will add this exception into the code for combo selected items, just for seeing). Anyway thanks again and thanks for your lib which my app uses for creating a lot of buttons and much more, except this awfull combo because i have not found the way to make what i want - image background- x ouside of the main window- with your lib)…

1 Like

G4P supports multiple Windows

@quark === perfect!!! - and image background for a combolist (i dont know how you call that)?

Unfortunately that is not possible with G4P. Can you post a picture of the combo box showing what you are doing?

@quark ===
ok; as you can see my background at this moment of the game is only a texture, the same as the main window, to the right. the dark green comes from the present window color, pref settings.

So it is the background of the JFrame that has the texture NOT the combo box G4P can do that,

@quark ===
combo has only a color
&& thanks again