|
|
Hi, I’m trying to learn Java in preparation for getting a Bug and have gotten stuck when it comes to understanding how graphics work. I wrote a program that randomly selects a start and ending point on a 2D grid. Then, it unleashes thousands of ‘bugs’ (cast from the bug class) which move about quasi-randomly trying to find the end point. Basically, I’d like to simply be able to draw out that 2D grid and illustrate each bug as a colored circle. Could someone explain how that could be done in my code, or point to a sample program which does something similiar? Thanks! CLASS 1:
} CLASS 2: public class BugMain2 {
} |
|
|
Hey, I definately want to get back to you on this question although I am leaving for class in 5 minutes so here is the 10 second answer. 1) Check out the java.awt.Canvas and java.awt.Graphics2D classes Searching my del.icio.us I came up with these, don’t know if they helpful but at some point in time I tagged them with AWT and Java http://java.sun.com/developer/onlineTraining/aw… Longer answer later! |
|
|
Thanks for the quick reply, I’m definitely looking forward to your next one! I still am confused about the graphics class (probably because I am so new to this), so forgive the dumb question, but are there graphics objects? All examples seem to show a method accepting a graphics object as an input, but I never see where it is instantiated, or even what java libraries are needed. If you could, in your next response, could you shed some light on that? Thanks! |
|
|
If you get a chance, can you post some sample code / point to a tutorial? Thanks! |
|
|
Yea I definitely will I didn’t mean to leave you hanging but I’m in the middle of midterms this week (4 midterms 20 page paper a lot of regular homework = no time). Next week I will get a chance since I am on spring break, sorry for the wait. |
|
|
No problem at all! Good luck with the tests! |
|
|
Hey, I started working on an example for you. Got the static graphics going, the animation part is going to be harder. Do you want the BUG's location to update or just show the first time the app is launched statically? If you want them statically then just make a new class like the gridmarker one, but I had assumed you wanted it to update which is a bit more involved. I'll be working on that tomorrow. Here is what it looks like at the moment: ![]() And here is the code, the first two classes are the same as they would be for the bug, the last just the Frame to test stuff out The canvas that you can draw on This is the class for the little markers The main class, this would be your app that gets called from the servicetracker on the BUG, I am just doing it as a vanilla Java app for no particular reason
|
|
|
Thanks for the sample code! I’ve got it up and running and have been playing around with it for a bit now. FYI: Eclipse didn’t like a few lines like involving packaging and importing, so I commented them out. I have two quick questions for you though … 1. When I run the code in Eclipse, the frame pops up as it should … However, when I try to x-it out, it wont go away. I’ve had to resort to Ctrl-Alt-Delete. Why is that? 2. I can’t seem to figure out how the paint method it ExampleCanvas is being called! I’ve looked everywhere, but I never see it called, not even in the constructors … I must be missing something simple, what is it?? Thanks again! |
|
|
The paint method in ExampleCanvas gets called with the frame.show(); line in the main method. Every component that you add to a container gets its paint method called then. Even though Eclipse likes to cross that line out as depreciated, it is not and you need that line. As for stopping the window, not sure, but if you hit the red square on the console in Eclipse it will close easily. The packaging depends on how you setup your project. I like to make things broken up into a lot of packages because I like to reuse my code as much as possible, I’d rather write twice as much if I can use it again because no matter how one off a project I think it is, I always seem to use some of it later. |
|
|
Here is a good reference on the paint method and updating in AWT. I’m working on casting a bunch of BUGs around the screen and updating them. http://java.sun.com/products/jfc/tsc/articles/p… I have to say that my example is not exactly their perfect use case, but I’m working on it. They say that you should not call the paint class explicitly for a number of reasons (basically, it can fail) and use the repaint() method. That brings up the point of breaking up what you are drawing into objects. It would be tempting to just throw it all in as one Canvas object that needs to get drawn, but then each time it needs to be updated, everything needs to be redrawn. If you make it a number of objects then only the updated objects need to be repainted which hopefully will reduce flicker. Now I’m thinking should each BUG be an object or should I make an object that paints all of them like I did for the gridmarkers? If they are all to be updated every time, then one object is the best route for minimum overhead, but if only some are going to be updated each time than making each one an object would be better. That is kind of up to you. |
|
|
Amormachine, You raise a good point about responsible AWT and OSGi bundle programming. If by closing the Frame you mean to terminate the application, you must express this programmatically. The default behavior of a Frame object when closed is to do nothing. To change this, you must override and flesh out the relevant methods from the WindowAdapter interface. Picking up on Kevin's code, here is what that would look like: For more information about WindowListener, WindowEvent, WindowAdapter see some code samples here: http://www.exampledepot.com/egs/java.awt/pkg.html The code addition above uses anonymous inner classing, which can be very convenient for GUI programming. Instead of laboriously defining classes that extend the abstract classes and override the relevant methods, or worse, implementing an interface and overriding all the methods for each event handler (MouseListener, MouseMotionListener, etc), you may define it right within the declaration itself. This practice is very common in GUI programming. Most GUI Builders do this in code generation too. See a nice lecture at Stanford (PDF) for a pretty decent overview of anonymous inner classing in Java: www.stanford.edu/class/cs108/handouts061/17AnonymousInner.pdf I should also note that calling System.exit(0) from within any Bundle is bad news! This makes a system call which in turn terminates the entire VM process on the host OS. While this may be ok for the Virtual BUG, this would be very unkind to the other OSGi bundles running concurrently with your own. Lastly, it may be best not to hard-code the Frame size in your application. Not all LCD resolutions are the same, there is an LCD module in the pipes that would stretch nearly the entire width of the physical BUG! Dimension d = Toolkit.getDefaultToolkit().getScreenSize();I'm working on setting up a Wiki for Java tips and suggestions for BUG coders. I'll be sure to announce when it's up. |
|
|
Thanks John, I am far from an authority on AWT, my GUI programming was all Qt/C+ and GTK/C++ prior to the BUG, but Sun has a lot of good reference material, if only I took the time to read it! |
|
|
Kschultz, Your apps are great! With the physical BUG now available, it's important to ensure as much contunity in behavior between the Virtual BUG and physical BUG. Sometimes I wish there was a red "terminate application" square somewhere on the physical BUG. :wink: I've put up a sample application for how to use Anonymous Inner Classes and WindowAdapter/Listener, MouseAdapter/Listeners on BugNet for reference. |
|
|
Ha, well at the very end of my time in the office I got the apps going on a real BUG but at the time it was more WOW IT LOADS than worrying about details. I plan to go back and edit all my apps for things like loading from the menu and exiting nicely when I know more about the best way to do it. I guess a "managing application lifecycle/playing nice with other apps" page on the wiki would be a good idea. |