Christopher Brooks

No, but I saw a dodo at the natural history museum the other day. If you have any luck let me know, I understand that the Thames Valley and the City are the best places to search.

Scraped through by the skin of my teeth 62%!!!
Am still very happy with the result because I am 100% self-taught

Good luck to my study buddy David who takes it in 2 weeks

I am glad you said b) because that's what I was leaning towards. I am not sure I understand your comment about the event handling. Do you mean that I should implement anonymous inner classes, so that the text "menuItem1" can appear in the same place in the source code?
menuItem1 = new JMenuItem("nicer");//neat coding menuItem1.addActionListener(new ActionAdapter(){// ??? ActionAdapter ??? public void actionPerformed(ActionEvent e) { //Event handler implementation goes here... } }); menuItem2.addActionListener(new ActionAdapter(){// ??? ActionAdapter ??? public void actionPerformed(ActionEvent e) { //Event handler implementation goes here... } });
instead of:
menuItem1.addActionListener(this); menuItem2.addActionListener(this); public void actionPerformed(ActionEvent e) { if (e.getSource() == menuItem1) {//not so neat coding //Event handler implementation goes here... } else if (e.getSource() == menuItem2) { //Event handler implementation goes here... } }

Excuse me, I did originally post this question in the Swing forum but felt it was more appropriate here...
I am having trouble deciding how to go about controlling the objects in my application. I want to have a JDesktopPane which when selecting menu options will spawn internal frames. The internal frames should themselves be able to spawn other internal frames.
Anyway I came up with a partial solution. In my GUI_DesktopPane class I have menu items and then also the following methods:
public void actionPerformed(ActionEvent e) { if (e.getSource() == menuItem) { createFrame(new GUI_MemberStatus()); } else if (e.getSource() == menuItem2) { quit(); } } //Create a new internal frame. protected void createFrame(JInternalFrame i) { i.setVisible(true); desktop.add(i); try { i.setSelected(true); } catch (java.beans.PropertyVetoException e) {} }
I then have various classes like GUI_MemberStatus that extends JInternalFrame and implements ActionListener. Now what should I do about those "special" internal frames that need to spawn internal frames in the JDesktopPane as well?
Should I:
a) Make the createFrame method static, and use it from wherever
b) Pass a reference of GUI_DesktopPane into the "special" internal frames constructor. Create the new internal frame within a method of the "special" internal frame. Call the createFrame method using the new internal frame as a parameter.
c) Make the GUI_DesktopPane a singleton. Call getinstance().createFrame from wherever I want.
d) Go away, read a book on design patterns, pass my SCJP exam, get a job in IT and stop trying to be a part-time programmer

That's encouraging, I thought it was just me. I tried using Forte to do my GUI building but I find the generated to code to be long-winded, the IDE not using loops and so on. You have to really learn how to use the IDE properly otherwise you hit a brick wall because you cant edit the generated code. I found that learning the IDE reelly well is in itself enough of a burden on top of trying to learn Java.
However I do sometimes find it useful to generate code, for example for the event handling, and then copy and paste the generated parts of the code I like into my program!

ok i was thinking in my GUI_DesktopPane class, to have menu items and then also the methods:
public void actionPerformed(ActionEvent e) { if (e.getSource() == menuItem) { createFrame(new GUI_MemberStatus()); } else if (e.getSource() == menuItem2) { quit(); } } //Create a new internal frame. protected void createFrame(JInternalFrame i) { i.setVisible(true); //necessary as of 1.3 desktop.add(i); try { i.setSelected(true); } catch (java.beans.PropertyVetoException e) {} }
I then have various classes like GUI_MemberStatus that extends JInternalFrame and implements ActionListener. Now what should I do about those "special" internal frames that need to spawn internal frames in the JDesktopPane as well?
Should I:
a) Make the creatFrame method static
b) Create the new internal frame within the "special" internal frame. Pass a reference of GUI_DesktopPane into the "special" internal frames, then call its createFrame method and pass it the new internal frame.
c) Make the GUI_DesktopPane a singleton. Call getinstance().creatFrame from wherever i want.
d) Stop posting stupid questions on the forum, open up a plumbing business and make more money than any programmer would dream of.

NEP - edited post to format code so it wasn't extra wide...
[ October 30, 2003: Message edited by: Nathan Pruett ]

Any ideas?

Thanks Joel, is that a particular design pattern that you are talking about in your bean example? Is there one that I might think about using for this scenario? Do you see anything wrong with the JDesktopPane being a singleton idea?

Can you elaborate a bit please.

I am having trouble deciding how to go about controlling the objects in my application. I want to have a JDesktopPane which when selecting menu options will spawn internal frames. The internal frames should themselves be able to spawn other internal frames.
My question is how is this normally done. Should I create a singleton JDesktopPane with methods in it to spawn every type of internal frame possible, that way it would be easy to get the frames to appear by calling the JDesktopPane instance from anywhere in the application, even from the other internal frames. In other words have the JDesktopPane create all the objects.
Or, should I allow the Internal frames to create the other Internal Frame objects in their methods?
In fact should I be creating the objects in the methods at all or should I be doing that in the constructor, I am getting very confused!?

What is the advantage of not using static methods in this particular example? Would you run into problems if you wanted more than one deck in a game? Would you run into problems if you wanted two games?
I suspect you would run into difficulty if you wanted more than one deck because you would not be able to change the decks independantly. I suspect that having two different games would not be a problem.
If you knew you were only ever going to have one deck, would having static methods be an issue?

Doh! So maybe I'm not that much wiser

A1. I would say 3 of 4 is the most that are "normally" right, but that is probably a useless question & answer because they could all be right
A2. No, you have to work it out for yourself
A3. Don't know, I got my exam score (but I failed). That was last year, now I'm wiser, and taking the exam next month too. Good luck! I remember there being heaps of threading questions and IO.

Oh Arun,
The private constructor means that you have to instantiate it from somewhere within its own class. You can't instantiate it from another class (well, except from an inner class).
Maybe its better to say - you can't instantiate it from outside its own class.