Joe McCarthy

Greenhorn
+ Follow
since Sep 28, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Joe McCarthy

After further reflection, I realiized that I do not want one constructor to be, strictly speaking, simply a superset of the other. When I call it without any arguments, I want the class to read a configuration file; if I pass it a pair of strings (for host and name), I want to use those instead of whatever is in the file (I don't want to even read the file in that case) ... and set the private instance variables to the host & name it is passed via the constructor.

I've split off a separate "init" method ... but since I want to be able to be able to switch to a new database while the application is still running, I have overloaded that as well.

I'll copy and paste the actual "workaround" code I'm using. I'm still curious about whether there would be a more elegant solution if I didn't have the configuration file issue, but it's a lower priority issue (now).

Sorry to have taken up the bandwidth here without having thought this all through more thoroughly!

[ November 19, 2005: Message edited by: Joe McCarthy ]
18 years ago
Hi Marc,

Thanks for the suggestion. Unfortunately, I want to do the initialization before calling the no-arg version (rather than after).

Joe.
18 years ago
I want to be able to call a constructor with no parameters, and have default values be used for class instance variables, or call a constructor with parameters that set those variables, and then do some common stuff.

I tried two variations. In one, the parameterless constructor does the common stuff, and the multiple parameter constructor does initialization first, then calls the parameterless constructor.

This doesn't compile because the call to "this()" must be the first method called in the constructor.

In the second, the parameterized constructor does the work, and the parameterless constructor calls the parameterized constructor, passing it the default value.

"this( x )" doesn't compile because x doesn't have a value yet (since the instance has not yet been constructed when the constructor is invoked).

I have a feeling I'm missing something embarrassingly obvious, but I can't figure out how to get this work. Thanks, in advance, for any assistance!
18 years ago
I'm glad to learn that my "kludge" isn't such a bad solution, after all. I've incorporated the Random.nextInt call and the centering code you provided. Now I'm going back to my image scaling code (that you helped me with earlier) to start sewing this together.

I'm going post the code I wrote to experiment with the rotate( theta, offset, offset ) method you had earlier provided ... in case it's of use to anyone else. Not terribly elegant (particularly the enormously tall JSpinner components), but it was helpful to me in visualizing the effects of different parameters ... and, er, in learning more about a few other Swing components.

Thanks, once again, for helping me out!

18 years ago
The flag is [re]initialized to zero each time the actionPerformed method is invoked. You might want to use a separate variable -- external to actionPerformed -- to store the label you want to use for the button in the center of the window.

Here's a potential solution fragment:
18 years ago
I've spent most of today trying to better understand the two solutions provided by Henry and Craig. I tried a few different ways to combine them, but all failed. So, I decided to move on to the next phase of development -- enabling a variable number of thumbnail images to be shown in the QueuePanel. To do this, I decided to use a GridLayout and add a number of ImagePanels (one per grid element), and then use drawImage -- if there is an image for that panel -- or fillRect -- if there is no image for that panel. If there are fewer images than panels, the blank rectangles should go on the right portion of the screen.

In the version Henry provided, my modifications work fine when the JWindow is upright (0 degree rotation), but I couldn't make this work when the window is rotated 90 or 270 degrees. In the version that Craig provided, I could get it to work in all three rotation angles, but when it is rotated 270 degrees, the images are updated right to left (well, top to bottom). I tried using

but this didn't have any effect.

I'm posting the full version of the code below. Craig & Henry: if you're still paying attention to this thread, the differences are
  • using a Thread in go()
  • a new Runnable class, QueueMonitor
  • revisions to the QueuePanel class (GridLayout of ImagePanels)
  • a new ImagePanel class


  • Before posting the full code below, I'll note that the only differences between the modifications I made in Craig's version and those I made in Henry's version was the paintComponent() method in QueuePanel, which is not defined in Craig's version, and the paintComponent() in ImagePanel. In Henry's version, I use the following in QueuePanel
    and the following in ImagePanel

    Without further ado, the latest version is posted below. If anyone can help me figure out how to get the images in the QueuePanel to display left-to-right when the JWindow is rotated 270 degrees, I'd welcome any input. Other suggestions on how to better implement this are welcome, too. Thanks!



    [Update: I had posted a subsequent message, to share the code I used to graphically explore the Graphics2D rotate() method; I deleted it for fear that this message might not get seen (in such a long thread), and will repost that message later. I also inserted the modified paintComponent() method for ImagePanel from the version of Henry's code I modified.]

    [Update 2: For now, I added a kludge so that the ImagePanels are added in reverse order to the QueuePanel when the rotation angle is 270 ... I updated the code above (with "kludge warning" comment), but would still welcome a more elegant solution and/or explanation as to why this would happen. Thanks!]
    [ October 26, 2005: Message edited by: Joe McCarthy ]
    18 years ago
    Craig: thanks for the additional solution!

    I like the way that you have simplified the rotation & translation into a single call to rotate() with the x and y offset parameters. I also like the use of different colors, to help me see where the panel boundaries are. I will go back and plug this into the earlier SimpleGui2B code and play around with the three parameter version of rotate() to better understand how this works.

    On the other hand, I like the way that the code modification that Henry provided earlier handles all the manipulation in the enclosing contentPane, so that the individual panel classes need not take notice of whether any rotation is necessary. Perhaps I can combine the best of both ... and then combine the "final" version with the image scaling code you helped me with earlier.

    Thanks again!
    18 years ago
    Henry: thanks for the fix and explanation!
    Ken: thanks for the additional clarification!
    18 years ago
    Henry: thanks for persevering in helping me out! Using paint() vs. paintComponent() solves the problem ... though I am now curious about what the difference is between these methods (I'll browse around for some info).

    One last thing I notice is that using the new contextPane seems to have shifted everything down a few pixels from my version (which added panels directly to the JWindow). I welcome any input from you, or anyone else, who can help me understand why this is happening, and/or how I can eliminate these extra pixels. Thanks!
    18 years ago
    Hi Henry,

    Thanks for the help!

    I like the idea of modifying the container rather than modifying the individual panels. I'd earlier been trying to use rotate and translate on the graphics for the frame (window) itself, but it hadn't occurred to me to use the ContentPane of the window (doh!).

    I see what you mean about the repainting issue. When I run the application with a 90 or 270 degree rotation, and move my DOS command prompt window across the application window in a westerly direction, it "uncovers" the profileCanvas painted in an untranslated/unrotated position, centered in the X-axis (although, oddly, if I move the DOS window across the very top few pixels of the application window, it does not have this effect). Moving in southerly direction appears to "restore" the rotated version. I re-inserted my System.out.println() calls, and the "uncovering" problem appears to occur whenever paintComponent() of any of three subpanels is called without a corresponding (and immediately preceding) call to the paintComponent of RotatedCanvas (which is where fillRect() is called, along with rotate() and translate()). I tried declaring theCP at the top level, and invoking theCP.paintComponent() from each of the other methods, but this resulted in even odder behavior. I don't know if this description helps you (or anyone else) with any further diagnosis, but additional help is most welcome.

    BTW, I noticed the additional "translate" call you inserted, for modifying the X coordinates ; testing the application with different window sizes showed that the correct translation is dependent upon the width and height of the window, so I declared a new variable to represent this:



    Thanks again for your help!
    18 years ago
    I have an application in which I want to display three different types of information in a window: some profile information about a person in one, a queue of thumbnail images in another, and some kind of banner image in a third. This information will be updated at separate intervals with separate methods, and so I thought it would be best to use a separate panel for each one.

    The application will likely run in portrait-mode orientation, on a physical display that is tilted 90 (or 270) degrees, and so I have experimented with using the rotate() and translate() methods in Graphics2D. When I modified the SimpleGui2B code from Head First Java (the one that loaded the image of the cat), with a single JPanel on a single JFrame, these methods worked fine (rotating 0, 90 or 270 degrees). When I changed the JFrame to a JWindow, they still worked fine. When I added two more panels, though, with separate classes and paintComponent methods, they didn't work right anymore -- only the "top" panel was painted correctly (except when there was no rotation or translation).

    I've found a few code examples for using AffineTransform, but all of them use a single image in a single container. I suspect I'm missing something rather basic about using AffineTransform ... or perhaps JPanels and JWindows. Any suggestions are welcome. Thanks!

    [BTW, image files for the code below can be found at here.
    I invoke the application with three parameters specifying the width, height and rotation of the display, e.g., "432 768 0", "432 768 90" or "432 768 270"]

    18 years ago
    That did the trick -- thanks!

    I can see, now, that the reason that my earlier version "worked" (w.r.t. scaling) was due to the infinite loop -- eventually, the panel had a size, and so the image was correctly resized (er, repeatedly, forevermore).
    18 years ago
    Craig: thanks for the reply, the information and the code modifications!

    I didn't know getScaledInstance was an asynchronous method, so am glad to have a better way to accommodate that, and I hadn't considered pulling the image scaling out of the paintComponent method, so those are both welcome changes.

    When I compile and run the code you provided, it does not have an infinite loop, and I am grateful to have that problem resolved. Unfortunately, the image does not get scaled when I supply an additional parameter (e.g., "java SG2B2 t"). The System.out.println() traces I inserted show that the calls to getWidth() and getHeight() in the scaleImage method are now returning 0 (zero) values rather than 292 and 366, respectively, that were returned when my original code is executed, and so no scaling is performed.

    As so often happens, this, in turn, provided an unanticipated learning opportunity about Java and arithmetic: the widthRatio and heightRatio computations both involved dividing by zero, and yielded "-Infinity" results (rather than resulting in a run-time error).

    I tried to figure out why getWidth() and getHeight() work differently in the two versions of the code, but to no avail. Any further assistance will be further appreciated. Thanks!

    Oh, BTW, in case it's of use, the 480x480 JPEG file I am using can be found here: http://interrelativity.com/Logo.jpg
    [ October 16, 2005: Message edited by: Joe McCarthy ]
    18 years ago
    Hi,

    I want to be able to resize an image to fit within the bounds of a component (e.g., a JPanel) while preserving the original aspect ratio.

    To experiment, I adapted an example from the Head First Java (2ed) book, SimpleGui2B (p. 365), and wrote a method for MyDrawPanel to determine the dimensions of the image and the enclosing JPanel, and then adjust the height or width of the image using getScaledInstance.

    When I run the code, I encounter an infinite loop whenever I call drawImage on the scaledImage. Simply calling the scaleImage method does not cause any problems if I do not try to draw the resulting image. I modified the code so that it will draw the original image if run with no arguments, and draw the scaled image if run with any arguments. The image file is a 480x480 JPG, and the JFrame within which I am drawing it is 300x400.

    I'm fairly new to Java, so I may be missing something fairly obvious regarding paintComponent and/or drawImage. Any relevant insights / experiences / solutions are welcome -- thanks!

    18 years ago