I am really struggling with getting an applet program to repaint outside of minimizing and then bringing to the foreground again my applet window (which it does repaint, and quite neatly, revealing the underlying mechanics at work as intended).
But resizing after each input is getting really, really old in testing my program. The compiler gets angry whenever I try to call any of the methods to repaint from events in my primary object (A Selection Class object named selector) trying to make me turn even more of my program bits and bobs static (actions I had taken to satiate demands from other classes) or - more disconcerting - screaming that I need to input a Graphics object parameter, but when I do so, all kinds of everything becomes broken. It gets even angrier and crazier on the rabbit-trails elsewhere. Goal: I would like the program to repaint every so often on its own.
*afterthought* maybe I could prebuild each Graphics object in another class extending Graphics class then treat them as blocks of image? Is that even possible? Trying to hold out on doing a load of custom artwork for the time being.
I read that there is no way to directly call the paint() method, yet, that is what repaint() seems to do, from everything else I read and see. But repaint() and I are NOT friends. Yet.
But for me it doesn't seem to work any which way I approach this thing. I don't want to post too much code initially, but I really don't know where to start. Tell me if you need more info. I'm thinking lines 51 of Flank Class should (indirectly) invoke the method at line 61 (the following Blocks of code Classes Deck and Card are there just to show you what lines 62/63 call.). But it acts like it doesn't. It probably doesn't and I have no clue why others can use it in threads to get what they want and I can't. Repaint() doesn't take parameters. Maybe there's a command in there to resize my window to some arbitrary size and back again like I've been doing manually? I'm desperate to get this working.
I've tried rewriting the whole damn thing as a JPanel, as a JFrame (before I learned those two objects are just brothers with different layout managers) and then as a Canvas (also before I did any research on what it was). In the end, Applet is as good as any for what I need, so it seems from what I read, anyway.
I've mimicked and modified, mixing and matching successful techniques from what I've seen others do and all of my versions fail in the same brutal way. Maybe I just don't understand Graphics objects, though from everything I read they seem straightforward. It is possible I don't fully understand threading, but that seems straightforward to me as well (thread just branches the program much like using conditionals, but flitting back and forth between each branch's execution priority, right?). I have yet to implement the other thread pathway, which I'm guessing I'll need separated out to manage some animations, etc.
Thank you to those willing to take the time to look at this! The input I've received here is always really, really helpful.
although you start a Thread in your 'start' method, the problem is that that thread isn't
doing anything at all.
So you might try this:
In that case, I would also advise to put in a method 'stop'
(see the Applet API), in which you kill this thread.
However, this also has some consequences, so in the end it is best
to follow Pauls advise: use a JPanel instead of an applet, and use
a Swing Timer. That will make things far more easy. Should that give
any problems: let us know!
There are three kinds of actuaries: those who can count, and those who can't.
Good advice from PS. Avoid starting new threads for GUIs because they are not thread‑safe. If you need to run something in parallel find out about the SwingWorker class. Applets are obsolete because of security problems, and I shall move this discussion to the GUIs forum.
I've tried rewriting the whole damn thing as a JPanel, as a JFrame
That is the way it should be done. You create a JPanel and do the custom painting on this panel, then you add the panel to the frame. Custom painting is done by overriding the paintComponet(...) method.
And don't forget to invoke super.paintComponent() at the start of the overridden method.
Your current code is a bit of a mess. First you extend Applet and then you create a Frame. This is wrong and 15 years out of date. As has already been mentioned people don't used Applets, or AWT components. Just use Swing components.
I suggest you start by reading the Swing tutorial on Custom Painting for the basics and simple examples to start with. Learn painting basics first before writing more complex code.
I will rewrite this as you say, as a JFrame with a JPanel within it. I had gone one or the other but not both. I had not heard about Swing's timers, I'll learn how that works to implement this.
And the word "this" did indeed fix all my dead thread code. With just that keyword, it all started refreshing as I had hoped, but since I'm headed down a dead-end, outdated path, I'll start fresh!
Folks, this is huge for me! (Since my version 1.7, when I first encountered this about two weeks ago, I've made basically a new version of the game every night by 0.1 increments, up to 2.9) This was a huge leap forward to know that I should revamp this and approach a whole new way!
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop