Messages posted by: mrider

I've been going nuts over this for several days. I found the solution without Google's aid (grumble, grumble). Seems to me like it's worthwhile to record this for posterity. And although I haven't posted here many times, I think this is a good site, so I figured maybe I could drive some traffic here if is so happens that someone else has the same problem I did. EDIT I also posted this here -> http://forums.devshed.com/java-help-9/not-a-question-for-posterity-jcombobox-does-not-drop-in-large-jdialog-822739.html

I had the problem where a JComboBox used as a simple drop down (no edit functionality) in a custom dialog would not, um, drop. It started out only manifesting in Windows. Then after a bit of thrashing where I eventually replicated it in Linux, it seemed as if it only happened in certain look and feels. Finally I narrowed it down to the fact that the drop down would only drop if the bottom of drop down would go below the bottom edge of the window. The LNF part was driven by the fact that some LNFs are more compact than others, and so hence sometimes items in the drop down would cause the edge to exceed the window size limit.

Anyway, here's a sample program. This does not work properly. Do not use this!

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.UIManager.*;

public class DialogTest implements Runnable, ActionListener {
    private JDialog dialog;
    private static final String[] items = {"Item1", "Item2", "Item3", "Item4", "Item5", "Item6", "Item7"};

public DialogTest(String lnf) {
        for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
            if (info.getName().equals(lnf)) {
                try {
                    UIManager.setLookAndFeel(info.getClassName());
                    break;
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }
        dialog = new JDialog();
        dialog.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
        dialog.setResizable(true);
        JButton ok = new JButton("Ok");
        ok.addActionListener(this);
        JRootPane root = dialog.getRootPane();
        root.setDefaultButton(ok);

root.setLayout(new FlowLayout());
        root.add(new JLabel("Try resizing the dialog to see the problem  "));
        root.add(new JComboBox(items));
        root.add(ok);
        dialog.pack();
    }

public void run() {
        dialog.setVisible(true);
    }

public void actionPerformed(ActionEvent e) {
        System.exit(0);
    }

public static void main(String[] args) {
        Runnable r;
        if(args.length == 0) {
            System.out.println("Try supplying one of these LNFs to see if there's a difference:");
            for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
                System.out.println(info.getName());
            }
            r = new DialogTest(null);
        } else {
            r = new DialogTest(args[0]);
        }
        Thread t = new Thread(r);
        t.start();
    }
}

The problem? I was adding content directly to the root pane. The corrected code which works looks like this:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.UIManager.*;

public class DialogTest implements Runnable, ActionListener {
    private JDialog dialog;
    private static final String[] items = {"Item1", "Item2", "Item3", "Item4", "Item5", "Item6", "Item7"};

public DialogTest(String lnf) {
        for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
            if (info.getName().equals(lnf)) {
                try {
                    UIManager.setLookAndFeel(info.getClassName());
                    break;
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }
        dialog = new JDialog();
        dialog.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
        dialog.setResizable(true);
        JButton ok = new JButton("Ok");
        ok.addActionListener(this);
        JRootPane root = dialog.getRootPane();
        root.setDefaultButton(ok);
        
        /** DO NOT DO THIS
        root.setLayout(new FlowLayout());
        root.add(new JLabel("Try resizing the dialog to see the problem  "));
        root.add(new JComboBox(items));
        root.add(ok);
        **/
        //INSTEAD, DO THIS
        Container container = dialog.getContentPane();
        container.setLayout(new FlowLayout());
        container.add(new JLabel("Try resizing the dialog - the problem is gone  "));
        container.add(new JComboBox(items));
        container.add(ok);
        dialog.pack();
    }

public void run() {
        dialog.setVisible(true);
    }

public void actionPerformed(ActionEvent e) {
        System.exit(0);
    }

public static void main(String[] args) {
        Runnable r;
        if(args.length == 0) {
            System.out.println("Try supplying one of these LNFs to see if there's a difference:");
            for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
                System.out.println(info.getName());
            }
            r = new DialogTest(null);
        } else {
            r = new DialogTest(args[0]);
        }
        Thread t = new Thread(r);
        t.start();
    }
}

Man that cave must be deep for it to take a little over four years for the echo to return...

[EDIT]
Oh, I get it - nanai is a parrot!

Well, I don't know if you want to incorporate this into your tree or not stdunbar. You are more than welcome to this if you want it. I promised I'd post this in my previous JISQL post, and then got busy and forgot.

If this helps great. If not I won't be offended

[EDIT]
Sheesh, forgot to mention this... I added the ability to specify an output formatter. To use the formatter, one needs to edit the template properties file and put the fully qualified path to an object that implements the OutputFormatter interface. When starting the program one needs to supply the full path to the properties file that contains the mapping of SQL type to formatter.

Armed with this you could easily specify a formatter for blob types, and then tweak that formatter.

HTH

Sure - I'll take a look, although I doubt if you introduced any problems.

One thought I had was that it would be handy to be able to inject output formatters as a command argument. For example one of the tables I query has a date column. jisql always truncates the date from that table - and I've confirmed this to be a bug in Oracle's JDBC driver. It reports the length incorrectly - giving the size it would be if the numbers are totally unformatted, as opposed to having dashes ( 20060908 versus 2006-09-08 ). It would be nice to be able to specify a properties file that points to a series of objects that can be used for formatting. E.g.

java.sql.Types.DATE=my.formatters.DateFormatter

Fun stuff!!

Actually, I took the liberty of making that exact change, plus I added a two more minor tweaks:

1) I added the ability to specify the spacer for columns - which used to be the single char ' '. I did this because of brain-dead Windows' command line copy/paste. It seems that when a line of text ends in space, copy does not copy that space. Which makes it difficult to copy/paste into another program. This can probably be ignored most of the time.

2) I added a loop which outputs Java's column types when the -debug flag is specified.

I've been using jisql for a bit now, and I have a minor suggestion: Change your check for "exit" and "quit" to ignore case. It makes life slightly easier when typing all caps SQL commands.

A little used (so far as I know anyway), but legitimate use for JNI would be to provide a Java API to hardware. Take a look at the following post for an example of what I mean: http://forums.hotjoe.com/posts/list/274.page.

I have no personal experience to back this up, but it seems to me that with hardware like that it would be in everybody's best interest to provide the smallest native lump possible, and then provide as much portable code as possible. Code that comes with a device like that is just overhead, it's not the main order of business. If I were designing the interface for that printer (or something similar), I'd be championing Java. It only makes sense.

So from that perspective, JNI could be used in places where it's necessary to "get close to the metal".

Do I need to create a new Thread for this method?

Yes. When the tutorial says "use with extreme caution", they mean "make sure you do it correctly", not "stay away until you know better".

Arguably the easiest thread type is one where the thread goes off in it's own direction, runs to completion, and never talks back to the original thread - and it looks like you can do that here. It makes life so much easier if you're not synchronizing access to data, or waiting on events, or etcetera.

My suggestion: Wrap that code you've posted into a separate object that implements the Runnable interface. Then in your action listener for the button, simply create a new thread for that object, set it's priority correctly (event handlers run at too high of a priority for "normal" processing), and start it. Assume your server listener is called "MySocketListener" - you'd start it like this:

MySocketListener msl = new MySocketListener();
Thread t = new Thread( msl );
t.setPriority( Thread.NORM_PRIORITY );
t.start();

In essence what you're doing is starting a new thread with your listener, and then releasing it "into the wild".

HTH

I downloaded the drivers out of curiosity earlier, but didn't spend too much time digging then. Now that we've eliminated the serial/parallel issue, I thought I'd take a peek. One thing I notice is that there is an entry for the TSP700-windows-parallel driver in jpos.xml, but there is not an entry in StarReceiptTest.java.

So, what does your printer.open like look like in StarReceiptTest.java? Did you try this: printer.open("TSP700-windows-parallel"); ?

[EDIT] Which you have to enter by hand. I.e. it's not already in the code waiting to be uncommented.

[EDIT 2] And it sounds like that's exactly what you're doing. Hmm.

However, can you really get serial cables that are identical to parallel ones, or ports that look identical?

Yes. They're older than dirt (circa 1980). But yes. As I say though, the cable gender would be wrong in that case. On a parallel cable - the end that attaches to your computer would be male (DB25 male). If it were a serial cable - the end that attaches to your computer would be female (DB25 female). These days one only sees a nine pin serial output on computers (or no serial at all - my how time flies), so the end of the cable is nine pin female (DB9 female). In fact I bet I still have one or two 9->25 pin adaptors laying around in my old junk somewhere.

Honestly I was hoping you'd say something like "Yeah, I had to look all over before I could find a gender changer thingie". Back when I used to do cabling that was always a sign the installer was trying to use the wrong interface.

I have to admit that I find this thread interesting, although I don't have much to offer by way of help.

I do find one thing a bit confusing though: Looking at the specifications from the link stdunbar posted, it looks like the printer is serial. Yet you say you've got it working on a parallel port. I find that contrary to my personal experience with how this stuff works.

I've never used a printer like your model. I have however configured Point of Sale and specialized use type printers that use serial cables. Usually they use serial because they are intended to be too far away from the computer for parallel to work. I think parallel has a roughly 2-3 meter (6-9 feet - ish) limitation. The ones I've seen use a 25 pin serial cable - and it's tempting to think they are actually parallel, except that the male versus female tends to be backwards.

Also, I have to wonder about TSP700. Sight unseen I would have thought that the "S" meant "Serial". Which would lead me to think that TUP700 would be "USB".

So now I find myself wondering if somehow your problem has to do with serial versus parallel. Perhaps the port you're using is in fact serial and you don't know it? Perhaps the code you are using needs a different configuration to communicate with the correct port?

Just random thoughts...

The value is a reference unless it is a value, then the value is a value. How could that not be clear?

I'm with stdunbar. I always look at it as if passing an object (or array) is the same as passing a reference, whilst passing a native type is passing a value. That's not correct, but it sure works like it's correct.

@angelnkh

Just so you know, Swing widgets return Objects as opposed to Strings so that you can use Objects other than Strings as your selection choices. It's relatively simple to do this: Just correctly override toString() in the Object type you are adding to the widget, and it'll display the text from toString(), but will return the actual object (not the text from toString()).

So as a design consideration, you might consider creating a database connection info object. One that encapsulates ALL the information required to connect. If this object overrides toString() with something meaningful - e.g. "Accounting database" - then you will receive back a meaningful object that you can use, but you'll see the contents of the "toString()" method on the screen. As opposed to having to construct it after the selection is made.

Just a thought.

[EDIT] Oh, and assuming you originally put a String into your JComboBox in the first place, you'll be able to cast it back to String again. As tfecw suggests.

I currently have no certifications at all. Back in the day when they were hard to get, I was an MCSE. When I took the tests there were very few study guides and no "here're the answers to any of the questions anyone is likely to see" web sites. It was HARD, and I had to learn the O.S. well. I answered the questions and passed the tests because I had done the work.

Then one day I started noticing all the paper certifications around me. I had one person that was an MCSE, MCT, as well as a few other non M.S. certifications. I handed this person a laptop with NT 4, a local administrator's account only, and turned him loose. He couldn't even create a local user account.

That's when I got serious about looking around at certs trying to see whether they actually meant anything. I was just so disgusted. At that time (around the time the dot bomb was falling), I realized that pretty much every cert was worthless. I haven't really tried to get certified in anything since. I guess if the student looks at the course-work as an excuse to delve into the deep, dark corners of the subject, and only gets certified after having learned the material - then well and fine.

So perhaps the fact that some sanity has returned is a good thing. It seems to me that the quality of a certification is inversely proportional to its popularity/desirability.

I do most of my programming in Eclipse, and I go to Kate when I want a GUI non-IDE editor in Linux, NoteTab Lite in Windows.

I've been trying to get NetBeans to work, but for some ****ing reason I can't get my cvs repository to work. NetBeans keeps telling me to check my user name, password, and repository. It's been a bit of a low priority, since I'm only doing that for curiosity's sake. Sigh.