[Vanessa Astle:] AutomataFrame is a class which I've created. I do follow the MVC pattern in my code, which was the purpose of the getter methods. I'm trying to get my controller to retrieve user input from my GUI, and then hand that information on to my model. This is where I'm coming in to problems. How does your controller know when to retrieve user input from my GUI ?
[Vanessa Astle:] On the GUI, the user clicks a button. The button is called "Graph Setup". This JDialog box has 4 JTextFields (accompanied by labels), a "Finished" button and a "Cancel" button. A user places the appropriate information in the text fields. If they click "Cancel", none of the information is retained and the JDialog is closed. The user goes back to a default frame. If the user clicks the "Finished" button, the information is to be retained and sent back to the controller which will then send that information to the model classes. How do the controller classes and the GUI classes communicate ?
{This may seem an obvious issue, and obvious answer. It is not as simple as common sense would suggest. Incorrectly synchronized programs exhibit surprising behaviors.
} [Vanessa Astle:] Well, that's how I want the flow of control to work. However, the getter methods that are being called get their information after the Graph Setup Dialog pops up, instead of waiting until the user types information into the textfields. This way, the getter methods are always returning default values (or null, if that be the case). There are other ways of doing this, likely the approach EFH suggests will produce more stable code, your approach here is a good place to hang a program. Generally, from the wording here, default values are placed in the constructor ... and that's why I asked what editor/IDE you are using. These techniques tend to get obliterated in full-scale IDE's which are extremely useful for some people, but of limited utility when in time-domain malestroms.
Just remember ROP (Reality Oriented Programming): Do not try to do too much in the constructor. Usually just provide default values and get on with it.
[Vanessa Astle:] I'm using Eclipse, and the program thus far is over 20 classes long. That is why I tried to restrict what I posted to be only the relevant code. Okay.
[Vanessa Astle:] Is it possible to create a Thread from an object of a class that implements ActionListener instead of Runnable? I would like to hear Ernest's comments on this.
[Vanessa Astle:] ...my extensive explanation was simply... Doesn't look extensive after one has worked on threading issues awhile.
[Vanessa Astle:] But what if I don't want to call start() on the thread. I want the thread to run on its own when, say, a button is clicked. That way, I wouldnt' have to worry about knowing when to initialize and start the thread. But I could control when it would run after it had been started. Since the thread runs when the button is clicked, it would work from an actionPerformed() method as opposed to a run() method. There are ways of juggling a Thread, from your user code, but the problem is - as I understand it right this moment trying to write my own program - is that a Thread Object (in other words, an instance) cannot be re-run.If you work on this problem, you end up trying to do memory management ~ and shortly the heavyweight World Class Masters Association sends one or two busloads of Captain Doctrinare over two thwart in the nascent moments a classic computer science problem that is best left alone unless you enjoy computer science for it's own sake.
Additionally, the semantics of the Java programming language allow compilers and microprocessors to perform optimizations that can interact with incorrectly synchronized code in ways that can produce behaviors that seem paradoxical. Stick with Ernest's suggestions for now, then let us know how it comes out.
actionPerformed() should be better than trying to do your own thread juggling, but there are threads generated by the screen drawing classes and is what I was talking about earler, and as well there are - as best as I can tell - copies made ( I haven't got it all figured out yet ) that have to do with Thread and instance creation and unless you explicitly tell a method to return something, it probably is a devastaion waiting for an important moment.
Synchronize on
anything you intend to be modified in any way, and do a great deal of
testing before showing your boss.
[Message edit by: Nicholas Jordan ]
Vanessa, I saw this in the tutorials while working on my own project:
This, coupled with default init() vals for your controller classes, would be a good design paradigm, I think.
[ June 23, 2007: Message edited by: Nicholas Jordan ]