using parent variables in eclipse

Is there a simpler way to reference processing functions in classes than using parent.method ? It's pretty tedious to do that when writing classes.

I am new to writing straight Java so I am still learning basic things like public and static voids. My apologies if the question is obvious.

Tagged:

Answers

  • edited December 2013

    Is there a simpler way to reference processing functions in classes than using parent.method ?

    this sounds like you're doing something wrong. post some code.

    processing is odd in that classes are actually inner classes because the code is wrapped in a class during compilation - export something as an application and then look for a java file in the exported directory to see what i mean.

    (edit: sorry, i missed the 'in eclipse' part)

  • edited December 2013

    When a Processing program starts, a PApplet object is created!
    In order for another library or an independent class (top-class) to access it, they indeed need a passed reference to it! :-&

  • edited December 2013

    My own code is too verbose to post right now, however I am following what is directed to do by Shiffman and others:

    learningprocessing.com/tutorials/processing-in-eclipse/

    The errors are all on lines where we call a Processing function (such as rect()) or reference a Processing variable (such as width). This is because a Stripe is not a PApplet and knows nothing about PApplets! We might be tempted to have Stripe extend PApplet, but this would be a fatal error. A Stripe is not a PApplet. A Stripe is a rectangular object that we want to draw onto a PApplet. What PApplet do we want to draw onto? The PApplet that is MyProcessingSketch. Instead of extending PApplet, we simply want to tell a Stripe object about a MyProcessingSketch.

    public class Stripe {
      PApplet parent; // The parent PApplet that we will render ourselves onto
    

    In the constructor, we initialize the parent:

      Stripe(PApplet p) {
        parent = p;
    

    And then anytime we want to call a Processing function, we access it via the parent variable.

      // Draw stripe
      void display() {
        parent.fill(255,100);
        parent.noStroke();
        parent.rect(x,0,w,parent.height);
      }
    

    If the only way to do this is to use parent.method(), can Eclipse make it easier somehow to convert things? When I export to Java applet as suggested, only one .java source file is created. So all the class tabs and .pde files that go with them get folded into one large source file. It's good for learning the differences between vanilla Java and Processing, but isn't helping me with using classes in separate files.

  • Answer ✓

    Welcome to Java. Without either subclassing PApplet (the main Processing sketch) or creating a nested class (Processing's "classes"), there is no easier way to access a particular object's fields and / or methods.

  • edited December 2013

    calsign, thanks for the insight! I looked up "nested classes" and found that one could work within nested classes in one file and refactor into separate files while moving along. This seems a little more like the sketching mentality that comes with the PDE.

    I used this as a reference: http://stackoverflow.com/questions/3645047/putting-nested-classes-in-separate-files

    After trying it out on one of my sketches this is what was produced by the Eclipses "refactor --> move type to a new file":

    RotatingBlob.java:

    package rotatingBlob;
    
    import processing.core.*;
    
    public class RotatingBlob extends PApplet {
    
        Blob myBlob;
        Blob myBlob2;
        Blob myBlob3;
    
        public void setup() {
            size(1200, 400);
    
            // initialize blob
            myBlob = new Blob(this, 255, width / 2, height / 2, 1, .01f, .001f);
            myBlob2 = new Blob(this, 155, width / 2, height - 50, 1, .02f, .005f);
            myBlob3 = new Blob(this, 45, width / 2, 50, 1, .02f, .03f);
        }
    
        public void draw() {
            frameRate(60);
            background(255);
            myBlob.move();
            myBlob.center();
            myBlob.body();
            myBlob2.move();
            myBlob2.center();
            myBlob2.body();
            myBlob3.move();
            myBlob3.center();
            myBlob3.body();
        }
    
    }
    

    Blob.java

    package rotatingBlob;
    
    class Blob {
    
        /**
         * 
         */
        private final RotatingBlob rotatingBlob;
        int c;
        float xpos;
        float ypos;
        float xspeed;
        float nVal;
        float nVal2;
    
        Blob(RotatingBlob rotatingBlob, int _C, float _Xpos, float _Ypos, float _Xspeed, float _nVal,
                float _nVal2) {
            this.rotatingBlob = rotatingBlob;
            c = _C; // color(244);
            xpos = _Xpos; // width/2;
            ypos = _Ypos; // height/2;
            xspeed = _Xspeed; // 1;
            nVal = _nVal;
            nVal2 = _nVal2;
        }
    
        public void center() {
            this.rotatingBlob.rectMode(RotatingBlob.CENTER);
            this.rotatingBlob.fill(c);
            this.rotatingBlob.rect(xpos, ypos, 5, 2.5f);
        }
    
        public void ring(float radian, float w, float h, int grey) {
            this.rotatingBlob.noFill();
            this.rotatingBlob.rotate(this.rotatingBlob.millis() * 0.001f * (RotatingBlob.radians(radian)));
            this.rotatingBlob.stroke(grey);
            this.rotatingBlob.ellipse(0, 0, w, h);
        }
    
        public void body() {
            nVal = nVal + .01f;
            nVal2 = nVal + .05f;
            float n = this.rotatingBlob.noise(nVal) * 40;
            float n1 = this.rotatingBlob.noise(nVal) * 50 * this.rotatingBlob.noise(nVal2);
    
            // float rSize10 = random(-10,10);
            // float rSize20 = random(-20,20);
            this.rotatingBlob.pushMatrix();
            this.rotatingBlob.translate(xpos, ypos);
    
            this.rotatingBlob.ellipseMode(RotatingBlob.CENTER);
            this.rotatingBlob.pushMatrix();
            ring(-270 + n1, 40 + n, 55 + n1, 153);
            this.rotatingBlob.popMatrix();
            this.rotatingBlob.pushMatrix();
            ring(120 + n1, 50 + n1, 40 + n, 150);
            ring(45 + n, 45 + n, 50 + n1, 155);
            this.rotatingBlob.popMatrix();
            this.rotatingBlob.popMatrix();
        }
    
        public void move() {
            xpos = xpos + xspeed;
            if (xpos > this.rotatingBlob.width) {
                xpos = 0;
            }
        }
    }
    

    Would this be an acceptable way to write classes from scratch? All the use of "this" reminds me of JavaScript.

  • If I understand it correctly, this would require you to re-refactor the nested class every time that you change it... but if you like the functionality, then I suppose it is acceptable.

    There may be an option somewhere to remove unnecessary this prefixes (perhaps in the Refactoring dialog?).

  • edited December 2013

    So far its working pretty much OK while working in one file. After the class is refactored into another file its a little cumbersome. Editing the refactored class files I have to rely heavily on auto-complete so I don't spend all day typing

    this.package.method(arg,arg);
    

    My biggest fear is that I'm picking up some sort of bad habit. According to this at least some people write programs in a similar way: http://stackoverflow.com/questions/98079/can-eclipse-extract-a-second-class-in-class-file-to-its-own-file

    What's your opinion as to how I'm going about it?

  • Answer ✓

    I don't think I would go about doing these things in this particular way... but this is a highly subjective matter and all that really matters is if it works for you.

  • Thanks for the honesty and helpful comment calsign. Pure Java is a much bigger animal than I would have expected.

  • Answer ✓

    I find simpler to write p.line() or pa.line() (p or pa for PApplet (or parent)), than to use all this "refactoring" adding even uglier prefixes... :-)

    And, yes, Processing has made Java edible by removing the need for all this (class declarations, prefixes, and all), making it look like a simple, procedural language... But then, those jumping in the Java bandwagon (a small portion of Processing coders) are struggling with a lot more verbose language...

    On the other hand, Eclipse's auto-completions, suggestions and refactoring capabilities (plus navigation, etc.) compensate partially for this.

Sign In or Register to comment.