We are about to switch to a new forum software. Until then we have removed the registration on this forum.
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.
Answers
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)
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! :-&
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/
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.
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.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:
Blob.java
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?).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
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?
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.
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.