draw to a second window with G4P

Roland

Hello All,

I need a little help on how to draw to a second window...

I'm using G4P and have cerated a class "item". All this class can do is draw a rectangle. I create two instances of this class (p & r). One should draw the rect to the first window, the second instance should draw to the second window. But all I get is a rect in the first window, while the second window remains empty...

Has someone an idea what I'm doing wrong? Sorry, if this question is too stupid, but I can't get this to run after searching the net for hours.

Thankx in advance, Roland

//Begin of sketch

import g4p_controls.*;
 
GWindow myWindow;

item p = new item();
item r = new item();
 
public void setup(){
  size(480, 320, JAVA2D);
  G4P.messagesEnabled(false);
  G4P.setGlobalColorScheme(GCScheme.BLUE_SCHEME);
  G4P.setCursor(ARROW);
  if(frame != null) {
    frame.setTitle("Sketch Window");
  }
  myWindow = new GWindow(this, "Window title", 0, 0, 240, 120, false, JAVA2D);
}
 
public void draw(){
  background(100, 230, 100);
  fill(0);
  text("Main WIndow", 20 ,20);
  p.display();  
  myWindow.addDrawHandler(this, "myWindowDraw"); 
}
 
synchronized public void myWindowDraw(GWinApplet appc, GWinData data) {
  appc.text("Secondary window", 20, 20);
  r.display();
}
 
class item {
    
  void display() {
    rectMode(CORNER);
    fill(0);
    rect(50,50,100,100);
  } 
}

GoToLoop

I dunno how to use most 3rd-party libraries. But I don't think it's a good idea to setup a callback @ 60 FPS! @-)
Are you sure line #24 should be inside draw() callback, which is invoked @ 60 FPS by default? :-S

P.S.: By convention class & interface names should be capitalized: change item to Item! :P

Also, there's no need at all in checking if (frame != null) {}.
If that was the case, even size() would crash the JFrame instance!
Much probably, the sketch woulda crashed much before setup() had a chance to be invoked by the framework! >:)

quark

Yes the call to addDrawHandler should be in setup after line 16 where the window is created.

If the sketch is run as an applet inside a webpage then framewill be null. It was a safety net in Processing 1.5.1 when it was possible to export as an applet and is still valid since the Applet Builder tool can create applets for some sketches. So I wouldn't remove the test as it does no harm and might do some good.

Change the item class to

class Item {

  void display(PApplet app) {
    app.rectMode(CORNER);
    app.fill(0);
    app.rect(50,50,100,100);
  }
}

and change line 29 to

r.display(appc);

Also change all occurrences ofitem toItem since this is the convention used in naming classes.

GoToLoop

If the sketch is run as an applet inside a webpage then frame will be null.

Oh, I didn't know that. Generally before I access frame field, I test against online instead.
That online works for "JavaScript Mode" too. At least for processing.js v1.4.1! ;)

I believe you coulda noticed once this type of lines in my code before:

if (!online) frame.setTitle("blah, blah, blah..." + variable); :P

It's a common place in my (in)famous online examples! HEHE

quark

@GoToLoop

You might want to go back to testing frame since according to the PApplet source code online has been deprecated.

  /**
   * Confirms if a Processing program is running inside a web browser. This
   * variable is "true" if the program is online and "false" if not.
   */
  @Deprecated
  public boolean online = false;
  // This is deprecated because it's poorly named (and even more poorly
  // understood). Further, we'll probably be removing applets soon, in which
  // case this won't work at all. If you want this feature, you can check
  // whether getAppletContext() returns null.

I am not sure what they mean by 'removing applets' but if it means PApplet extenindiga Frame rather than Applet then using the getAppletContext() method is also redundant because it is in the Applet class.

GoToLoop

That was announced a long time ago and I knew that! L-)
But I strongly disagree deprecate things which are needed and got no other substitute!
Processing devs even refuse to have a constant to define current version! :-L
Writing cross-mode or cross-version sketches are impossible! ~X(

quark

Just tried using frame in JavaScript mode and it didn't work so no use going back to that :\">

GoToLoop

That's why I use online in order to check whether I can use frame.setTitle()!
Variable online exists in both Java & JS modes (processing.js v1.4.1)! So it's a cross-reference!

Accessing an undefined variable crashes in JS too! I've read we gotta use the line below to check for it:
if (typeof frame == 'undefined') {}

However, that wouldn't compile in Java Mode either! :-<

In order for different modes to cross-work, there gotta be API parity overlap!
But seems like devs from different modes hate each other and make cross-transpiling impossible! X(

quark

@GoToLoop This discussion has gone off the OP's topic. The whole area of cross mode development is a discussion in itself so if you want raise a discussion under General Discussion I am sure it will raise some strong arguments for and against and would be very interesting.

Roland

Hi quark, Hi GoToLoop,

I was out for a few days, so I come a little late...

I've modified my sketch in the way you described and it's running perfect!

Thanks for your help.