# G4P - Secondary Window Buttons Not Always Reliable

**URL:** <https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518>\
**Category:** Libraries\
**Created:** [May 31, 2024, 12:57pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518 "2024-05-31T12:57:07Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [May 31, 2024, 12:57pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/1 "2024-05-31T12:57:07Z")

</div>

Hi, I’m using the fantastic G4P library, and I’ve made some secondary windows with buttons on them.

I’m using the technique of creating them null, and then showing/hiding them with other buttons.

I’m finding that sometimes you have to click the buttons 2-3 times in the secondary window before they register a click. I’m wondering if there’s something I can do to make them work 100% reliably?

Here’s code from one of the sample windows that exhibits this behavior:

```auto
public void optionsDraw(PApplet app, GWinData data){
    app.background(127);
    //app.image(optionsIcon, 123, 10);   
    app.stroke(100);
    app.strokeWeight(2);
    app.fill(127);
    app.rect(15, 70, 270, 70, 5);
  }
  
void createOptionsWindow() {
  int windowWidth = 300;
  int windowHeight = 200;
  options = GWindow.getWindow(this, "Options", width/2 + 120, height/2 + 70, windowWidth, windowHeight, JAVA2D);
  options.setActionOnClose(G4P.HIDE_WINDOW);
  options.addDrawHandler(this, "optionsDraw");
  options.addMouseHandler(this, "optionsMouse");
  options.addKeyHandler(this, "optionsKey");
  //options.addData(new MyData());
  cbShowToolTips = new GCheckbox(options, 22, 80, 120, 20, "Show Tooltips");
  cbShowToolTips.setLocalColorScheme(GCScheme.SCHEME_15);
  cbShowToolTips.setSelected(blnShowToolTip);
  cbShowToolTips.addEventHandler(this, "cbShowToolTips_clicked");
  
  btnCancelOptions = new GButton (options, windowWidth/2 - buttonWidth - 15, windowHeight - buttonYOffset, buttonWidth, buttonHeight, "Cancel");
  btnCancelOptions.addEventHandler(this, "btnCancelOptions_clicked");
  btnCancelOptions.setLocalColorScheme(GCScheme.SCHEME_9);
  
  btnOKOptions = new GButton (options, windowWidth/2 + 15, windowHeight - buttonYOffset, buttonWidth, buttonHeight, "OK");
  btnOKOptions.addEventHandler(this, "btnOKOptions_clicked");
  btnOKOptions.setLocalColorScheme(GCScheme.SCHEME_9);
}
  
public void optionsMouse(PApplet app, GWinData data, MouseEvent event) {
    // Saves doing it for every variable in MyData class
    //MyData myData = (MyData) data;
    //if(event.getAction() == MouseEvent.CLICK){
    // myData.lastClickX = mouseX;
    // myData.lastClickY = mouseY;
    //}
}

public void optionsKey(PApplet app, GWinData data, KeyEvent event) {
  if (event.getKey() == RETURN || event.getKey() == ENTER) options.setVisible(false);
}

public class MyData extends GWinData {
    // The variables can be anything you like.
    public int lastClickX,lastClickY;
}

public void cbShowToolTips_clicked(GCheckbox source, GEvent event) {
  if (cbShowToolTips.isSelected()) blnShowToolTip = true;
  else blnShowToolTip = false;
  showHideToolTips();  
}

void showHideToolTips() { 
    
  if (blnShowToolTip) toolTipGap = 0;
  else toolTipGap = 1000; 
  setTooltips();  
}

public void btnCancelOptions_clicked(GButton source, GEvent event) {
  println("CANCEL CLICKED!");
  if (options != null) options.setVisible(false);  
}

public void btnOKOptions_clicked(GButton source, GEvent event) {
  println("OK CLICKED!");
  try{
    optString[1] = str(blnShowToolTip);
    saveStrings("options.txt", optString);
  }
  catch(Exception e) {
    e.printStackTrace();
  }
  if (options != null) options.setVisible(false);  
}

```

It works most of the time fine, but every once in awhile, you have to click either OK or Cancel 2-3 times before it registers the click.

It’s puzzling…

Thanks for any insights anyone may have,

Mike

---

<div class="post-metadata">

**Author:** ![LangdonS](https://avatars.discourse-cdn.com/v4/letter/l/ebca7d/32.png) [@LangdonS](https://discourse.processing.org/u/LangdonS)\
**Post date:** [June 2, 2024, 1:50pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/2 "2024-06-02T13:50:32Z")

</div>

Why are you coding your app this way?

Just use Swing.

> **[Trail: Creating a GUI With Swing (The Java™ Tutorials)](https://docs.oracle.com/javase/tutorial/uiswing/)**
>
> This Swing Java Tutorial describes developing graphical user interfaces (GUIs) for applications and applets using Swing components

> **[Lesson: Using Swing Components (The Java™ Tutorials \> Creating a GUI With...](https://docs.oracle.com/javase/tutorial/uiswing/components/index.html)**
>
> This Swing Java Tutorial describes developing graphical user interfaces (GUIs) for applications and applets using Swing components

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 2, 2024, 7:02pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/3 "2024-06-02T19:02:46Z")

</div>

Thank you. I appreciate the links and the suggestion.

In many places I have read that Processing doesn’t play well with the Swing library, so that’s why.

I’m heavily invested now in the G4P library so I probably wouldn’t change, unless I just can’t accomplish what I need to.

But the button clicking unreliability is problematic.

I have dabbled a little with Swing and Java.

---

<div class="post-metadata">

**Author:** ![svan](https://avatars.discourse-cdn.com/v4/letter/s/82dd89/32.png) [@svan](https://discourse.processing.org/u/svan)\
**Post date:** [June 2, 2024, 7:22pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/4 "2024-06-02T19:22:16Z")

</div>

```auto
I have read that Processing doesn’t play well with the Swing library

```

That’s not a problem if you use a separate thread. It was discussed here:[https://discourse.processing.org/t/swing-components-in-default-processingwindow/35483](https://discourse.processing.org/t/swing-components-in-default-processingwindow/35483)

A few things have been learned since that original post. For example the default canvas can be used for conventional drawing calls using draw() if you reduce the size of it and use it like a normal control instead of removing it entirely (obviates use of JPanel for drawing). Swing components can also be used in Python with py5. I’m mentioning all of this not to persuade you to switch from G4P but to clear up the threading issue; Processing plays nicely with Swing if you use a separate thread. We’ve also been using it in py5 without the additional thread and so far no problems that we are aware of.

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 2, 2024, 7:50pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/5 "2024-06-02T19:50:28Z")

</div>

That’s really useful @svan !

Thank you!

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [June 3, 2024, 1:49pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/6 "2024-06-03T13:49:16Z")

</div>

I tried to reproduce the problem (see sketch code below) without experiencing any problems. Why don’t you try it. 😄

The most likely causes for a sluggish GUI is

- time consuming code during frame-rendering-method or event-handling-methods or
- setting the frame-rate too low.

```auto
import g4p_controls.*;

public void setup() {
  size(480, 240, JAVA2D);
  createGUI();
}

public void draw() {
  background(160, 255, 160);
}

public void btn1_click(GButton source, GEvent event) { //_CODE_:btn1:726568:
  lbl1.setText("btn1 - clicked @ " + millis());
} //_CODE_:btn1:726568:

synchronized public void wnd1_draw(PApplet appc, GWinData data) { //_CODE_:wnd1:980755:
  appc.background(255, 180, 180);
} //_CODE_:wnd1:980755:

public void btn2_click(GButton source, GEvent event) { //_CODE_:btn2:317161:
  lbl2.setText("btn2 - clicked @ " + millis());
} //_CODE_:btn2:317161:

public void createGUI() {
  G4P.messagesEnabled(false);
  G4P.setGlobalColorScheme(GCScheme.BLUE_SCHEME);
  G4P.setMouseOverEnabled(false);
  surface.setTitle("Main Window");
  btn1 = new GButton(this, 30, 20, 230, 30);
  btn1.setText("Button on Main Window");
  btn1.setLocalColorScheme(GCScheme.GREEN_SCHEME);
  btn1.addEventHandler(this, "btn1_click");
  lbl1 = new GLabel(this, 30, 70, 220, 30);
  lbl1.setTextAlign(GAlign.CENTER, GAlign.MIDDLE);
  lbl1.setText("My label");
  lbl1.setLocalColorScheme(GCScheme.GREEN_SCHEME);
  lbl1.setOpaque(true);
  wnd1 = GWindow.getWindow(this, "Secondary Window", 200, 100, 260, 120, JAVA2D);
  wnd1.noLoop();
  wnd1.setActionOnClose(G4P.KEEP_OPEN);
  wnd1.addDrawHandler(this, "wnd1_draw");
  btn2 = new GButton(wnd1, 10, 10, 240, 30);
  btn2.setText("Button on Secondary WIndow");
  btn2.setLocalColorScheme(GCScheme.RED_SCHEME);
  btn2.addEventHandler(this, "btn2_click");
  lbl2 = new GLabel(wnd1, 10, 60, 240, 30);
  lbl2.setTextAlign(GAlign.CENTER, GAlign.MIDDLE);
  lbl2.setText("?");
  lbl2.setLocalColorScheme(GCScheme.RED_SCHEME);
  lbl2.setOpaque(true);
  wnd1.loop();
}

GButton btn1;
GLabel lbl1;
GWindow wnd1;
GButton btn2;
GLabel lbl2;

```

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 3, 2024, 2:45pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/7 "2024-06-03T14:45:00Z")

</div>

Thank you so much Peter! You always take care in your responses. Gratitude.

Yes I tried your lovely example and it works perfectly.

In my code, it’s not that the buttons are _sluggish_ to respond - they 25% of the time simply do not respond **at all**. In fact I’ve had the button change color when you click on it, and it does not trigger the click event. Like, WTAF? How could it register the mouseover and state change of the button but not trigger the click event?

I had a similar kind of problem before when I was making my own buttons - the click event was not reliable, and in another post someone suggested using the mouse release method instead, and in that case it solved the problem. I could perhaps try to get your buttons to respond to the release events using our previous discussion on fireAllEvents…

In the main window, and subwindows, I don’t have some crazy rendering code going on either, so I doubt it’s taxing the processor. It’s a very simple little box and the main window isn’t crazy processor intensive; just some buttons and text fields. And I have not changed the frame rate.

I have noticed that your image button controls do not exhibit this behavior so far; I may try making the OK and Cancel buttons into images and try them that way and see if that resolves it. That would also have the additional advantage that I can make a default button a different color, if it resolves the issues.

It’s one of those intermittent issues that’s hard to troubleshoot because it happens occasionally, but not consistently. It could work 10x in a row perfectly and then fail the next time. Enough to make me question my sanity.

I will keep working with it - and many thanks for your consistently kind and supportive responses. I seriously owe you a pint!

Thank you so much,

Mike

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 3, 2024, 3:21pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/8 "2024-06-03T15:21:52Z")

</div>

Here’s a little video showing the issue:

[Video](https://youtu.be/JiD4sH__sSo)

Thanks for watching

Mike

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 3, 2024, 3:25pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/9 "2024-06-03T15:25:37Z")

</div>

PS I am using this code in the draw() method:

```auto
 if(frameCount < 2) return; // first two frames are blank but does not stop G4P
  

```

to ensure all items load simultaneously between your library and other GUI elements (you gave this to me in another post).

Could this be part of the issue?

EDIT: Nevermind; disabled it and it’s not changing behavior.

Thanks,

Mike

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [June 3, 2024, 4:51pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/10 "2024-06-03T16:51:11Z")

</div>

Working backwards -

I assume that the frameCount code is only included in the main window draw method in which case it should make no difference at all. Of course you can test this yourself by commenting out the line 😇

I had a look at your video and I see what you mean I will have to think about it.

In Java the rendering method (in the case of Processing the `draw` function) and event handler code (mouse clicks etc) are ALL executed on the main event handling thread. It is not unknown for users to put in some processor intensive code inside these methods (or other methods called by them) e.g.

- calculating a ‘Game of Life’ iteration with 12million cells
- calculating a hires Mandelbrot image
- loading large amounts of data from a hard drive
- synchronous http requests
- …

At 60fps there is ~17ms to execute all events queued on the main event thread. Since our computers are multitasking and there are lots of other tasks being processed then really we need to limit any processing to \<10ms.

I doubt whether your application is doing anything like that so it should not be an issue.

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 3, 2024, 5:03pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/11 "2024-06-03T17:03:16Z")

</div>

I’m grateful for any thoughts you may have.

Yes I did REM out the line and it had no effect. Still same issue.

I wonder if using another “thread” would help…haven’t delved into those yet though.

Thanks for any insights, and I hope you are doing well kind sir.

Mike

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [June 3, 2024, 5:05pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/12 "2024-06-03T17:05:39Z")

</div>

In G4P each window is effectively a separate Processing applet, so each window has its own event thread.

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 3, 2024, 5:40pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/13 "2024-06-03T17:40:05Z")

</div>

Thank you Peter for explaining.

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 4, 2024, 11:46am UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/14 "2024-06-04T11:46:49Z")

</div>

Just curious if you had any further thoughts on the button clicking reliability?

Thx,

Mike

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 5, 2024, 11:06pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/15 "2024-06-05T23:06:29Z")

</div>

So far in testing using image buttons instead of the standard buttons, I can confirm that the unreliable behavior is gone. Clicking an image button appears to work 100% of the time; no missed clicks or funny business.

I will update this post again after more testing, but this seems to have done the trick.

Suggesting there is “something” going on with the standard buttons that the image buttons do not suffer from…

In any case I’m thrilled to have reliable clicks happening now, but of course it’s a bit more work to create all the images for the image buttons. But worth it.

Thanks,

Mike

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [June 6, 2024, 8:18pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/16 "2024-06-06T20:18:52Z")

</div>

> [@Thundercat](#):
>
> Suggesting there is “something” going on with the standard buttons that the image buttons do not suffer from…

I will do some experiments to see if I can find the problem and produce a solution. I make no promises since I have not been able to reproduce the problem yet.

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 6, 2024, 8:58pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/17 "2024-06-06T20:58:04Z")

</div>

Peter, I certainly do not expect you to spend a single second on this - honestly.

I have it working 100% reliably with image buttons. It could be something in my code, which is too byzantine to share or decipher.

So please, don’t spend any time on it. If something like it ever comes up again, well, then just know the image buttons are always responding to click events 100% in separate Windows.

Thank you, and apologies; I do not mean to give you assignments or stress.

Mike

PS - it worked out even better because now I’ve colored the default buttons so it’s even more intuitive. Plus I have the whole messaging system working perfectly now with individual icons for each kind of message.

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [June 7, 2024, 2:53pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/18 "2024-06-07T14:53:45Z")

</div>

Although I am unable to recreate this problem I have compared the mouse handling source code in GButton and GImageButton and believe I have a solution, even though I can’t test it.

---

<div class="post-metadata">

**Author:** ![Thundercat](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Thundercat](https://discourse.processing.org/u/Thundercat)\
**Post date:** [June 7, 2024, 3:05pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/19 "2024-06-07T15:05:39Z")

</div>

If you share it I can test it on an older version of the app I’m making.

Your support and caring are waaaay out of line kind sir! Seriously can I buy you a pint or send you a thank-you ££?? Send me a PM with a link.

I don’t take you for granted.

All the best and THANK YOU!

Mike

---

<div class="post-metadata">

**Author:** ![quark](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/quark/32/26_2.png) [@quark](https://discourse.processing.org/u/quark)\
**Post date:** [June 8, 2024, 12:50pm UTC](https://discourse.processing.org/t/g4p-secondary-window-buttons-not-always-reliable/44518/20 "2024-06-08T12:50:52Z")

</div>

Thanks to @Thundercat for testing my solution and confirming it worked.

This issue has been resolved and will appear in the next release 4.3.11