Henry Wong wrote:Your classes also seem to have a circular requirement... Your btnSaveListener class requires a connect object in order to instantiate it (with no other option to instantiate it). And your connect class requires a btnSaveListener object in order to instantiate it (with no other option to instantiate it).
In other words, both classes require that you have an instance of the other first, or you won't be able to create it.
Henry
Henry Wong wrote:
Your constructor takes two parameters. To construct a connect object you must use...
c = new connect(blah, blah);
Where the first blah is a reference to a btnSaveListener object, and the second blah is a reference to a gList object.
Henry
Henry Wong wrote:
I'm not sure how I would add a value to 'c' without typing something like c = "1" or "test", which then gives me an incompatible types error.
Apologies for this being a simple error, but I just can't get my head around it!
The "connect" class type is part of your program. You wrote it (or got it from somewhere). If you can't figure out how to instantiate one, how do you expect us (who don't even know what it is) to tell you?
Henry
Henry Wong wrote:
I'd create a new btnSaveListener by typing "btnSaveListener bsl = new btnSaveListener()", but that would still be null, right?
If you did this, then you still have compile errors... please don't run you code until you get rid of all of your compile errors.
Henry
Rob Prime wrote:No, I meant was: how do you create new btnSaveListeners? Because if you pass null to the constructor, then the reference stays null of course.
Rob Prime wrote:
John Pisci wrote:
I thought I had instantiated it with the "this.c = connect;"
And how do you construct your instances? Are you sure you're not passing null to the constructor?
Campbell Ritchie wrote:Maneesh is right, but GridBag is often hard to learn. Google for MigLayout, which I have never used, but is supposed to be much easier to use. Or have a look at the Other GridBag Tutorial
But beware of trying a null Layout. That will give all sorts of problems if the Frame is resized; the lower or right Components may drop off the display altogether.
Henry Wong wrote:
Have another problem know though; one that just randomly appeared. I don't know why, but it has been working.
Stuff like this don't randomly appear. If it has been working, then this is caused by something that you changed.
By chance, did you happen to change the constructor of the btnSaveListener class? Maybe added a few parameters?
Henry
Fred Hamilton wrote:exactly. Readability and maintainability. And in addition to considerations about how much work you want your event handler (actionPerformed) to do, also one can think about the degree to which the application is "classified".
Just seeing this one class which is little more than an event handler leads to believe that you might end up with a real proliferation of classes. If you wanted to be able to use this particular listener/event handler with other applications, then your idea is pretty good. If the listener has no use outside of the current application, then maybe it's not so good.
In my programs, I usually have a main GUI class that includes most if not all of my listeners and event handlers, and the event handlers themselves are very minimal, often just a method call, and the method is in another class. This approach serves to separate functionality from presentation.
Again, this sort of stuff is more a question of style, readability, maintainability. You know your program best, so it's for you to decide these things, I'm not saying what is best, just pointing out a few design decisions you need to make. I haven't done much database work with java, so maybe that influences general application design.
Fred Hamilton wrote:
Henry Wong wrote:
I get the following error for each and everyone of the variables:
Each and every one of those variables are *local* variables of the actionPerformed() method. They are not in scope outside of the method.
Henry
It seems to me there some questions of programming style here also?
We have separate class for just an action listener and little else. (btnSaveListener) And that class is doing a lot of work with a lot of different variables. It seems that is a scenario that invites trouble. Sure you can make it work, but...
Maybe there are reasons for doing it this way, I don't know. There's always different ways of doing things. But I like to keep my action listeners much cleaner than what is shown here, and rely more on appropriate method calls.
Henry Wong wrote:
I get the following error for each and everyone of the variables:
Each and every one of those variables are *local* variables of the actionPerformed() method. They are not in scope outside of the method.
Henry