Possible bug in GTextField.isValid()? (G4P library)

This seems to be a bug, although maybe it’s just a misunderstanding on my part. I’m initializing a text field with “0” and calling ‘setNumeric(0,16,0)’ to limit the range between 0 and 16, with a default of 0. If I just click on the “OK” button without editing the field, the value returned is 0, but the ‘isValid()’ function returns ‘false’. However, if I edit the field and make a change, even setting it to 0, the ‘isValid()’ function returns ‘true’. Is there something I’m missing?

import g4p_controls.*;

GTextField textfield1; 
GButton button1; 
GLabel label1; 
GLabel label2; 

public void setup(){
  size(400, 300, JAVA2D);

public void draw(){

public void createGUI(){
  textfield1 = new GTextField(this, 42, 36, 40, 20, G4P.SCROLLBARS_NONE);
  textfield1.addEventHandler(this, "textfield1_change1");
  button1 = new GButton(this, 42, 93, 60, 30);
  button1.addEventHandler(this, "button1_click1");
  label1 = new GLabel(this, 40, 150, 232, 20);
  label1.setTextAlign(GAlign.CENTER, GAlign.MIDDLE);
  label2 = new GLabel(this, 40, 180, 232, 20);
  label2.setTextAlign(GAlign.CENTER, GAlign.MIDDLE);

public void textfield1_change1(GTextField source, GEvent event) {
  println("textfield1 - GTextField >> GEvent." + event + " @ " + millis());

public void button1_click1(GButton source, GEvent event) {
  println("button1 - GButton >> GEvent." + event + " @ " + millis());
  label1.setText("textfield1.getValueI() = "+textfield1.getValueI());
  label2.setText("textfield1.isValid() = "+textfield1.isValid());


1 Like

Have you tried making it numeric first, THEN setting it to 0? (untested)

@jeremydouglass I just tried it and it didn’t work, although I agree that setting the filter before setting a value is more logical.

The issue appears because G4P does not -

  1. test any pre-existing text when setNumeric(...) is invoked
  2. validate the value passed in setText(...) even when a numeric filter has been applied.

In fact G4P only validates the text during keyboard input

I will look at changing the source code to remove the above two restrictions for the next release. :+1:

1 Like

Thanks. It may seem unimportant, and of course I can write code to do the validation myself, it’s just a simple range-check. But the user isn’t likely to edit the field if the default value is the one he or she wants, they’ll just click on some other field or on the “OK” button. (The default value is within the acceptable range, of course.) Here’s a screen shot of the actual window I was testing when I found the problem. The field in question is “Channel”. If you’re not familiar with MIDI, channel number can be from 1 to 16, to indicate which MIDI channel you want to listen to, or you can select “omni” mode to listen to all channels. I’m using zero to indicate “omni” mode.

I’m not sure I understand why the order of declaration would matter, there’s nothing in the documentation stating that it does, as long as both get called before the window is displayed.

Just to be clear, I think it’s fine to only validate the text during keyboard input, as you say it does. The only problem is with the ‘isValid()’ function, which returns ‘false’ if the field hasn’t been edited, even if the default value is valid.


BTW, there was another question I had in mind.What happens if the default value in ‘setNumeric()’ function is not the same as the value in the ‘setText()’ function? Which value should the ‘getValueI()’ function use, the current text value or the default value in the ‘setNumeric()’ function?

For example, if you changed the line in the code above to this:


I don’t know why anybody would write code like that, unless it’s by mistake, but I was just wondering. The ‘getValueI()’ function seems to be using the default from the ‘setNumeric()’ function, even though the value displayed (the current text value) may be something different. Here’s what happened when I tried it:


In this particular case it doesn’t matter because G4P only tests for validity when the content is changed via the keyboard.

I think the point is that it would be reasonable for the user to assume that G4P perform these actions and the fact that it doesn’t is an omission on my part . :innocent:

Anyway I have already modified the source code to correct my mistake and they will be in the next release of G4P. :grinning: