telkoth wrote:You don't code much do you nor study engineering? Hours and hours of study and trying is very common.
I've wasted the past... I don't know how many hours, and I'm starting to worry I've been going about this all wrong. Any kind of guidance would be much appreciated:
telkoth wrote:Alas, it can be: it's called AbsoluteLayout--or No Layout--or Null Layout, depends on where you read about it. In most cases it's called bad programming: you absolutely loose the ability to resize easily. (I cannot believe I just said that--me the Absolute Layout Evangelist of the late 90's).
sorry if my initial post was confusing/... of a frustrated tone. I will blame lack of sleep. perhaps I should have waited to post.
anyway! the use of a JFrame instead of a Canvas appears to have done the trick, with a few other modifications to the code - brilliant. it's not my own code, but it's pretty readable, and I feel like java function names are in most places pretty clear.
the whole "container" method of doing things is not particularly... natural or familiar to me. it surprises me that it's so difficult, or in some cases impossible, to just tell Java "put this object at (x, y) and be done with it," but whatever: if Java says "use my containers," then I'll learn to use it's containers. I guess that was my initial frustration. in some ways, it's still hard to believe that some things can't be done that way.
I was also surprised to learn that Canvas is apparently an older/out-of-date object. in all the reading I've been doing of graphical applications, Canvas seems to be the object of choice, but I suppose these articles are old. I am using Eclipse, which seems to do a great job of telling me when something is deprecated (many articles, I've noticed, handle threads in poor ways, using .stop(), etc)... but are there any guides/manuals available that can recommend "don't use X, use Y instead?" I notice increasingly that Java has many, many different ways to do things, with no clear indication of which is better suited to the task, and/or which are just so old as to be avoided!There is a lot of people writing books--many are recently published, but not really up to date. The Java Tutorials are great--I prefer the "Really Big Tutorial".
telkoth wrote:Never use getGraphics() for obtaining a Graphics reference of a component. Never, never, never.
1. a JPanel, which is being drawn to via getGraphics()
and all that; a loop of "do logic, render graphics, draw" (<-- this method is familiar to me, coming from a non-Java background, but I worry I should be using Java's paintComponent() and related functions, rather than ignoring them)You've been given a link to the tutorials. There's a section on Performing Custom Painting.
there's a bit of flicker which I'm having trouble sorting out, and I wonder if it's due to how Java wants to render thingsNo, it's due to your wrong approach.
... if the Swing objects are getting rendered separately, then my JPanel, etc, flicker-flicker. is this a point at which I can also not reinvent the wheel... should I be using paintComponent()Yes.
etc instead of a custom "logic, render, draw" loop? <-- is such a loop guaranteed to interfere with the normal rendering of other Swing objects?Yes.