 |
Author |
Topic: Split pde file (Read 464 times) |
|
Andre_Michelle
|
Split pde file
« on: Jul 31st, 2004, 11:41am » |
|
My pde gets unreadable (too much classes, code).
Is there a proofed way to split the classes into several files ?
I found a thread about ellipses and p5, but all the refences get lost(loadImage, width, etc.).
Same when extract a class to a file named java and drop it into the data folder.
any suggestions ?
|
|
|
|
|
fjen
|
Re: Split pde file
« Reply #1 on: Jul 31st, 2004, 1:54pm » |
|
ellipses ? do you mean eclipse ?
anyway .. a pde-file is actually one class extending BApplet (see the .java-file on "export to web").
Code: ...
public class <your sketch name> extends BApplet { ...
|
|
so all properties (width, ..) and methods (loadImage(), ..) are inheritaged from BApplet. if you were to create a class that needs or uses one of these properties or methods then you need that class to either extend BApplet or keep one inside .. i suggest you pass on your sketch class as a parent object like (untested):
Code:
public class <your sketch name> extends BApplet {
my_external_class some_instance;
void setup()
{
size(100,100);
// create instance of my_external_class
some_instance = new my_external_class(this);
}
void loop()
{ ... }
}
public class my_external_class {
BApplet parent;
my_external_class (Bapplet _parent)
{
this.parent = _parent;
}
public int getWidth ()
{
return this.parent.width;
}
}
|
|
|
| « Last Edit: Jul 31st, 2004, 3:15pm by fjen » |
|
|
|
|
Andre_Michelle
|
Re: Split pde file
« Reply #2 on: Jul 31st, 2004, 3:24pm » |
|
thanks fjien.
That was the point. I was looking for a solution to avoid passing the sketch object to the extern classes when create objects from them.
Is there no simple include"classfile.ext" to let processing think, its here in the *.pde file ?
|
|
|
|
|
narain
|
Re: Split pde file
« Reply #3 on: Jul 31st, 2004, 3:25pm » |
|
I don't think that's what Andre meant...
Oops, Andre posted while I was composing my reply. Oh well, I think this is still relevant.
I guess you just want to keep different classes in different files, easier to maintain and everything. I just looked at how the Sonia library works, and tried out a few things of my own, and as it turns out, it's really easy!
(This should be documented somewhere... It's useful!)
First, you need to create a subfolder called "code" in your sketch folder (Sketch -> Show code folder). Then you put each class into its own file called "<className>.java" in the code folder, and Processing should be able to access the classes.
(It's also possible to put more than one class in one .java file, but then you'll need to compile it to create .class files before Processing can see it. Apparently Processing needs to see a file called <className>.java or <className>.class in the code folder.)
Update: "I was looking for a solution to avoid passing the sketch object to the extern classes when create objects from them." I guess I'm still reading you wrong... Why do you need to pass the sketch object to external classes? Eh, erm... Okay, I have no idea what your original question was.
|
| « Last Edit: Jul 31st, 2004, 3:35pm by narain » |
|
|
|
|
Andre_Michelle
|
Re: Split pde file
« Reply #4 on: Jul 31st, 2004, 3:37pm » |
|
thank you narain.
This is great, but i have some problems left (compiler errors).
To have better Key Event security(some machine ignore the processing keyPressed, etc) I use the java one.
public void keyPressed( KeyEvent e )
But written in the SketchClass extends BApplet the compiler found no 'KeyEvent'.
Any suggestions ?
+ There are more errors left, which seems, that the methods and properties are still not available from there...
ok. I just put the folder online. perhaps it is more simple to understand:
http://www.andre-michelle.com/processing/cytris/Cytris.zip (80KB)
|
| « Last Edit: Jul 31st, 2004, 3:45pm by Andre_Michelle » |
|
|
|
|
narain
|
Re: Split pde file
« Reply #5 on: Jul 31st, 2004, 3:59pm » |
|
You can try java.awt.KeyEvent...
Now a question of my own: I don't understand why Cytris extends BApplet, actually. Not that this has anything to do with your problem, though, it's just that I don't know what the use of extending BApplet is. Are there things you can do with that, that you can't otherwise?
|
|
|
|
|
arielm
|
Re: Split pde file
« Reply #6 on: Jul 31st, 2004, 4:23pm » |
|
on Jul 31st, 2004, 3:37pm, Andre_Michelle wrote:| + There are more errors left, which seems, that the methods and properties are still not available from there... |
|
i think that with "megabucket" (the forthcoming big processing version), the "bagel" library will be package-friendly, and the "visibility" (i.e. access-enabled from the outside) of a bunch of methods and fields will be fixed.
on Jul 31st, 2004, 3:24pm, Andre_Michelle wrote:| That was the point. I was looking for a solution to avoid passing the sketch object to the extern classes when create objects from them. |
|
actually, even if it sounds overkill at a first sight, it's an excellent practice (when working on big java projects, you're "obliged" at some point to separate everything into standalone classes anyway)
and btw, if you reverse-engineer the average processing sketch that makes use of nested classes, you'll discover that the java compiler is doing exactly that (passing a reference to the "mother class" in the nested class constructor!)
it's due to the fact that there's no such thing as a nested class in java at the atomic level (every class is a separated instance...)
finally, just in terms of processing speed: using nested classes can make everything run slower.
e.g.
you have a nested class in your sketch that is working on the pixel-buffer:
for (int i = 0; i < 999999; i++)
{
pixels[i] = 0;
}
now, internally (at the so-called atomic level), it's different, more like:
BApplet parent; (the name "parent" is arbitrary, but anyway: in the nested class constructor, parent is initialized with a reference)
then...
for (int i = 0; i < 999999; i++)
{
parent.pixels[i] = 0;
}
see the difference
|
| « Last Edit: Jul 31st, 2004, 4:31pm by arielm » |
|
Ariel Malka | www.chronotext.org
|
|
|
Andre_Michelle
|
Re: Split pde file
« Reply #7 on: Jul 31st, 2004, 4:40pm » |
|
Quote:| BApplet parent; (the name "parent" is arbitrary, but anyway: in the nested class constructor, parent is initialized with a reference) |
|
No problem to do that, but what about performance.
I think the bytecode in loops will increase noticeable.
[edit]I not sure anymore about this above[/edit]
Quote:| You can try java.awt.KeyEvent... |
|
Has no effect. mmh strange...
Quote:| Now a question of my own: I don't understand why Cytris extends BApplet, actually. Not that this has anything to do with your problem, though, it's just that I don't know what the use of extending BApplet is. Are there things you can do with that, that you can't otherwise? |
|
Don't know what you mean. You don't understand why I(!) do this or why processing(!) uses this construct ?
Quote:| actually, even if it sounds overkill at a first sight, it's an excellent practice (when working on big java projects, you're "obliged" at some point to separate everything into standalone classes anyway) |
|
Yep, believe it, but what about some globals in your project ?
--
I rewrite the keyevents to processings back. Every try to compile now is a crash and a new browser window to the bugforum 
|
| « Last Edit: Jul 31st, 2004, 4:50pm by Andre_Michelle » |
|
|
|
|
narain
|
Re: Split pde file
« Reply #8 on: Jul 31st, 2004, 5:50pm » |
|
ariel: Thanks for the info about nested classes! Didn't know it made a performance difference. Good to know!
Andre:
Ignore the java.awt.KeyEvent shizazz. I'd forgotten the proper way to import things in Java, and managed to post some completely fictitious syntax. It's supposed to be import java.awt.KeyEvent; in the beginning of the source, but that may not work in Processing, so just forget I said anything.
Quote:| You don't understand why I(!) do this or why processing(!) uses this construct ? |
|
Well, I was just wondering why you have public class Cytris extends BApplet { in your .pde. So, why do you(!) do this?
Quote:| Every try to compile now is a crash and a new browser window to the bugforum |
|
I was getting that too... It didn't crash when I removed, um, static or final in your initial declarations, I don't remember which one. But then your switch/case wouldn't work.
Quote:| what about some globals in your project ? |
|
You can always try keeping your globals in one object, and have every other object access them from there.
|
|
|
|
|
arielm
|
Re: Split pde file
« Reply #9 on: Jul 31st, 2004, 10:50pm » |
|
on Jul 31st, 2004, 4:40pm, Andre_Michelle wrote:
No problem to do that, but what about performance.
I think the bytecode in loops will increase noticeable.
[edit]I not sure anymore about this above[/edit] |
|
exactly: with nested classes, bytecode quantity is increased and performance decreased as i tried to explain in the last part of my previous post.
on Jul 31st, 2004, 4:40pm, Andre_Michelle wrote:| Yep, believe it, but what about some globals in your project |
|
no problem, create an "interface" with "final static" fields, it will be helpful both in term of performance (i.e. fields compiled to numbers) and in term of code-organization...
(well... all these practices become really relevant when you work in something like eclipse)
|
Ariel Malka | www.chronotext.org
|
|
|
|
