This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Beginning Java and the fly likes NetBeans and GUI linking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "NetBeans and GUI linking" Watch "NetBeans and GUI linking" New topic
Author

NetBeans and GUI linking

Rob Brew
Ranch Hand

Joined: Jun 23, 2011
Posts: 99
Hi everyone.

i've got a method in my main class to run and want it executed when i click a button on a JFrame form. The JFrame is in a class GUI, the method is part of the main class.

I could pass the class to the GUI and run it that way, but doing so seems sloppy. What's the best way to do this from within NetBeans?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38472
    
  23
What’s a main class? Is it a class designed to contain the main() method? In which case, should your main class have anything other than a main() method in? Maybe you should move that method into another class.
But you ought to have some sort of control, which you pass to the GUI, and that control will allow the method to be called.

Display class→All your GUI classes.

Control class→Methods to call other methods, to retrieve use and alter data in the model, etc.

Passing the control to the GUI allows you to link the buttons to listeners to the control class.


I presume you already have some way of calling methods which works from the command line, possibly with a switch on keyboard input. That will call different methods from the switch. You now call those methods from the buttons.
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 316
    
    2

I've always found this to be kind of sloppy and I won't say this is any better but you can do something like

((MyApp)MyApp.getInstance()).doIt()

or if it's a static method just MyApp.doIt()

The problem as I see it is we want a global function and Java doesn't believe in those.

As much as I try to be a Java guy sometimes a global seems like the best way to do it.

Joe


It's not what your program can do, it's what your users do with the program.
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 316
    
    2

Campbell and I seem to have been typing at the same time.

In general I agree him and try to avoid this situation but here's an example I haven't found a way to get around.

I like to use one Logger for the whole program with command line options to set the log level, and possibly other settings (like file, stdout, and text field). So I create it in the main class and set it from the command line.

Then every class that logs something has a static field like:

private static final Logger logger = MyApp.getLogger();

Joe
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38472
    
  23
Loggers are different from a control class; you can use a Logger as a singleton because you are (as a dreadful over-simplification) writing everything to the same file.
A control class need not be a singleton because you may have different applications accessing the same database simultaneously. You might of course have concurrency problems.

And lots of people write replies simultaneously with me; only they usually manage to post first
Rob Brew
Ranch Hand

Joined: Jun 23, 2011
Posts: 99
Thanks for the replies guys.

Campbell i understand using a control class to pass the GUI, but what creates an instance of the control class and how does it interact with the rest of the program?

Main

Initialize control class.
Initialize GUI passing it control class.

then what?
Rob Brew
Ranch Hand

Joined: Jun 23, 2011
Posts: 99
Is this right?


Model m = new Model();
ControlClass c = new ControlClass(m);
StockCheckGUI gui = new StockCheckGUI(c);
gui.setVisible(true);
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38472
    
  23
That is one way to do it, which looks good. You will probably need more classes for a large application
Rob Brew
Ranch Hand

Joined: Jun 23, 2011
Posts: 99
how else would you do so?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38472
    
  23
Rob Brew wrote:how else would you do so?
I can’t think of a different decent way to do it just at the moment.

But I like to be circumspect about saying, “That’s the way to do it,” in case somebody else says, “This way’s a lot bettert,” five minutes later
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 316
    
    2

Rob Brew wrote:Is this right?


Model m = new Model();
ControlClass c = new ControlClass(m);
StockCheckGUI gui = new StockCheckGUI(c);
gui.setVisible(true);


Since we're talking in general terms allow me to ponder the traps I've gotten into and the dirty code I've decided to live with.

In the example Rob posted my question would be: "Why does the main class need to know about the Model and ControlClass? Does some other GUI class use them and you require the same instance in all of them?

I can see situations where yes the Model has some property that is only in memory that needs to be shared, or perhaps needs some time intensive task to initialize that you don't want to repeat, or perhaps the Model keeps so much in memory you'd rather not make copies.

I often have a Configuration Object that is singleton but not static that I pass around like that. Generating it each Class that uses it opens the possibility of conflicts or limits when and where it can be changed and saved.

But if you can't think of good reason not to, The ControlClass and the Model can be instantiated in the StockCheckGUI constructor (like JTable and TableModel) and you have better encapsulation with all the benefits.

I enjoy these discussions on how to write better code. I don't have a problem with the code Rob posted and have plenty of examples like that in my programs but I try not to use that pattern.

Joe "this version is only a temporary quick fix, unless it works" Areeda
Rob Brew
Ranch Hand

Joined: Jun 23, 2011
Posts: 99
But if you can't think of good reason not to, The ControlClass and the Model can be instantiated in the StockCheckGUI constructor (like JTable and TableModel) and you have better encapsulation with all the benefits.


Would you instantiate each separately within the GUI or pass the controller class to the model?
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 316
    
    2

Rob Brew wrote:
But if you can't think of good reason not to, The ControlClass and the Model can be instantiated in the StockCheckGUI constructor (like JTable and TableModel) and you have better encapsulation with all the benefits.


Would you instantiate each separately within the GUI or pass the controller class to the model?

The answer to most questions like this is "it depends".

If the situation is as simple as your example:


then I would put the "new Model()" in the ControlClass constructor and the "new ControlClass()" in the StockCheckGUI constructor.

But that assumes that StockCheckGUI always takes the same ControlClass which always takes the same Model. I'm going to go far out on a limb and assume from "StockCheck" that this is some sort of database controlled inventory system. And that the Model is somehow related to which table in the database or which subset of the table is being presented in the GUI.

Even in that case I see a slight advantage to creating the Model and ControlClass inside the StockCheckGUI and passing the GUI constructor some kind of specifier like column value in the database.

In general I like to keep my GUI as separate and sparse from program logic as possible. I've run into the situation where too much logic is scattered throughout event processors like button pushes or entry field focus lost events. Then I find I need to add a different user interface but want to keep the program function. Just for example if this were an Inventory Control program and you write it for a workstation with the idea people come in with all the info on forms in a clipboard. Now someone has the brilliant idea of using an iPad or an Android Tablet while they're walking through the warehouse. How much code can you reuse to translate your GUI classes into mobile friendly web pages?

I've become a real fan of refactoring especially with the tools NetBeans provides to help. The concept is to write code as quickly and conceptually simple as possible. The go over and over it to make it more robust, maintainable and clean from a design stand point. There's a lot of advantages to this. The biggest one is we get out of the mindset that once we write code we should carve it in stone to allow future generations to bask in our brilliance.

Another is a working prototype is much more understandable to end users, management and even other software designers that written specifications. I find I can usually produce a skeleton UI with some basic functionality as fast I can describe in enough detail what I want to do. I can get lots of people to download a jar file and try it but I can't get anyone to read the spec let alone understand it and provide constructive criticism. That's not to say I don't write development plans and architectural designs, it's just they they describe things at a higher level than what one set of screens is supposed to do.

So try it one way, once it works, look and see if you think of advantages to doing the other way (that make it worth changing). When you start making changes it becomes obvious where the real problems are. If you change something in one Class the fewer things that impacts the better. How much duplicate code do you have? Does this thing really need to depend on that thing? And so on.

Once you see how the Classes interact in the prototype don't be afraid to throw away everything you don't like and redo it. That possibility is why you want to get the prototype to people who will use it with a minimum of effort.

Sorry for going so far off on a tangent. I hope a little of that addresses your question.

Joe
Rob Brew
Ranch Hand

Joined: Jun 23, 2011
Posts: 99


tried synchronizing methods but still have this problem, there's a thread in ServerGUI to update the
GUI, the ArrayList buyingStock is manipulated by the thread and items are removed from it by actions on a ListBox.

Any ideas?
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 316
    
    2

Rob,

I think you may want to start a new thread for this issue.

The event driven GUI (Swing, AWT ...) is not thread-safe. There are lots of articles on why it never will be but it boils down to the event loop is a hack that simulates multi-tasking and putting threads in an event driven method is asking for trouble. See this Sun article and this Stack Overflow thread for an introduction to the problem. I'm sure there are plenty of threads here at the Code Ranch but Google didn't pop them up on top.

What I have done in the past is a worker thread that is fed by a LinkedBlockingQueue and have the event driven method add requests.

Joe
Rob Brew
Ranch Hand

Joined: Jun 23, 2011
Posts: 99
solved @)
 
wood burning stoves
 
subject: NetBeans and GUI linking