• Post Reply Bookmark Topic Watch Topic
  • New Topic

Dynamic Swing Components  RSS feed

 
Cory Hartford
Ranch Hand
Posts: 85
Eclipse IDE Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not sure if this belongs here or in the swing area since the question is kind of elementary.

I have a series of combo boxes for example, and I'd like to set.SelectedItem() programatically from an external class.
I have found a couple of ways to do this, although not exactly OO.

1) Make the comboboxes static and write setters to set them within the class.
2) Since there will only ever be one instance of the encompassing Jframe, I could make it a singleton and access the components via getInstace().
3) Have a static instance reference variable that I set inside a method (which seems pretty much like a singleton)
4) Pass the active reference around in instance calls until I need to use it.

I know both Static and singleton are dirty words so I am trying to figure a more OO way to do this. If #4 is the only answer, then I'd have to look at redesigning stuff so that I didn't have to bounce this reference variable all over the place until I needed it. I'm ok with redesigning it, but I was curious if maybe there was another option that I wasn't thinking of.

Thanks
 
Greg Brannon
Bartender
Posts: 563
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I often use your #1, except for the static part. Why do they have to be static in your world?
 
Cory Hartford
Ranch Hand
Posts: 85
Eclipse IDE Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greg Brannon wrote:I often use your #1, except for the static part. Why do they have to be static in your world?


Hi Greg; thanks for the reply.
The reason I put them as static is that I won't need to know what instance I am using in order to set the comboboxes. If I launch a new instance of the JFrame (which i do, I just never have two in existence at one time), all of my external modifying code wouldn't know which JFrame object I was using unless I somehow stored or passed it.
 
Greg Brannon
Bartender
Posts: 563
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't imagine your way of doing things or the reason for it, but I'll accept that there is a good reason for what you're doing. I'm more deterministic in my coding. I'll have to pass to someone more familiar with your approach.

Consider this though: If you never have more than one of your JFrames in existence at a time, why can't you accomplish the same thing using a single instance of your JFrame and then passing it to your "external code" as needed, like:


 
Cory Hartford
Ranch Hand
Posts: 85
Eclipse IDE Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greg Brannon wrote:I can't imagine your way of doing things or the reason for it, but I'll accept that there is a good reason for what you're doing. I'm more deterministic in my coding.
[/code]


I don't know if I'd say I have a good reason for it other than it does what i want it to.
The example you gave was I what i was talking about in point 4; keeping the object reference and passing it.

When you say you are more deterministic, what do you mean? Specific to design you mean or implementation?
 
Greg Brannon
Bartender
Posts: 563
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cory Hartford wrote:When you say you are more deterministic, what do you mean? Specific to design you mean or implementation?


The only 'static' element in my code is the main() method, but I'm still in Java elementary school.
 
Cory Hartford
Ranch Hand
Posts: 85
Eclipse IDE Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greg Brannon wrote:
Cory Hartford wrote:When you say you are more deterministic, what do you mean? Specific to design you mean or implementation?


The only 'static' element in my code is the main() method, but I'm still in Java elementary school.


Yeah me too; except I have to ride the little yellow bus.
I think the answer is that I shouldn't have designed myself into a corner where using these was necessary; as opposed to finding a better method to accomplish something that (from a design perspective) is broken.
 
Cory Hartford
Ranch Hand
Posts: 85
Eclipse IDE Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I went ahead and just passed the instance variable around where I needed it. I'm not sure I see the benefit though other than to say "hey look, my code is OO!". The code itself is pretty much the same except now I have added the frame type to the constructors of the classes that I want to access the combo box setters.
I get the whole idea of "just create one" when pojos are what we are operating on, but not so much with Swing components. In the example above, I have to dispose of my Frame object now when I'm done with it, versus updating static components in the existing frame object. When I create a new one, even though it happens quickly, there is a visible stutter.
I figure there has got to be another method to update the state of components in a Jframe without killing the frame object and creating a new one.
 
Paul Clapham
Sheriff
Posts: 22823
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cory Hartford wrote:I figure there has got to be another method to update the state of components in a Jframe without killing the frame object and creating a new one.


Yeah, well, there is. You update the state of those components by calling the appropriate methods on them. For example to disable a JButton you call setEnabled(false) on it -- or something like that, I'm going by memory here.

Of course to call a method of an object you need a reference to it. But you already know how to pass around references to objects, why aren't you doing that?
 
Greg Brannon
Bartender
Posts: 563
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cory Hartford wrote:I have to dispose of my Frame object now when I'm done with it, versus updating static components in the existing frame object. When I create a new one, even though it happens quickly, there is a visible stutter.


Adding to Paul's comment, it is unnecessary and not standard to dispose of a container and then recreate it to update the components it contains. There are methods available to update the components and even redraw/refresh the JFrame itself to update it. Check the API for the containers and components you're using and review the methods available for them to do what you need. If you're trying to do something and don't see an existing method to accomplish it, please ask. I doubt you'll come up with something that hasn't already been handled, but I suppose it's possible.

Once you get this, I think you'll understand better the usefulness of OOP and the benefit of having an instance of the object to pass to your other classes for them to operate on.
 
Cory Hartford
Ranch Hand
Posts: 85
Eclipse IDE Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
Cory Hartford wrote:I figure there has got to be another method to update the state of components in a Jframe without killing the frame object and creating a new one.


Of course to call a method of an object you need a reference to it. But you already know how to pass around references to objects, why aren't you doing that?


I have a really long, bad explanation, but suffice it to say its poor design.
I'll have to redesign to make sure I am efficiently passing the reference variable to the objects that need it and factor out (?) the ones that don't. Right now I'm passing it through a bunch of classes that don't need it just to get it to where I will need it. And thats just bad.
Once I have the ref variable I'm good with all of the component APIs, I have used those quite a bit.

As a side note, I think I am going to pick up Object Oriented Thought Process. A lot of my questions revolve around the why of this stuff. I can make the program function like I want it to, but the code would probably make you want to beat me over the head. I had this entire portion of my program working like I wanted it to, but based on our last conversation Paul, I re-looked at it and thought to myself that I could really make it more about objects than about the functionality. So I ended up tearing it apart to try take your advice.
Mixing the OO with the swing stuff kind of stumped me, but I get it now.

btw, I have all of my timer and monitor objects working like champs.

Thanks for your and Greg's help.

 
Campbell Ritchie
Marshal
Posts: 56533
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cory Hartford wrote: . . . I think I am going to pick up Object Oriented Thought Process. . . .
Search for other object-orientation books; there are better books available than that one.
 
Cory Hartford
Ranch Hand
Posts: 85
Eclipse IDE Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Cory Hartford wrote: . . . I think I am going to pick up Object Oriented Thought Process. . . .
Search for other object-orientation books; there are better books available than that one.


Thanks Campbell. I went with "OOP Demystified"; the review here at the ranch were pretty good and the ebook price was a bargain so not a lot to lose.
 
Campbell Ritchie
Marshal
Posts: 56533
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!