Styling a Pop-Up Confirmation Dialog and Forcing Focus in Java

This is really Concurrent Programming in Java part II. So consider it part of that post.

Anyways I needed a pop up confirmation box which had a styled entry field. This isn’t possible in normal Java but I am going to show you how to do it anyways. First, why? Because I need the confirmation box entry field to be styled, and I need it to request focus. Unfortunately since I was adding the entryField myself (to get it styled, since I couldn’t figure out how to access the one that comes with Swing) Java wouldn’t autofocus to it. After a lot of hacking around I felt this wasn’t possible normally. So here’s what I did to get it done:

JTextField entryField = new JTextField(); // global so it's in the same scope as popUpConf and it's thread.
public String popUpConf(String title, String msg) {

        // create a thread to wait until the dialog box pops up.
        (new Thread() {
            public void run() {
                // Sleep long enough for the window to pop up.....
                try {
                    // a half second should be fine...
                } catch (Exception e) {
                    // not required
                // request focus.

        Object[] message = new Object[]{msg, entryField};
        JOptionPane.showConfirmDialog(mainFrame, message, title,

        // return the string.
        String s = entryField.getText();
        return s;

In retrospect I probably should have used entryField.isShowing() and/or entryField.isVisible() to determine when I should request focus. Perhaps a short while loop with a small sleep value (50 or 100). Maybe I’ll go fix that now. But so far I’ve never had it barf on me. The only “error” is that it wouldn’t get focus, I suppose, which would be annoying but not unbearable.

Ok so that’s how you can set the font on a pop up confirmation box’s entry field. Cool, huh?


Concurrent Programming in Java

Perhaps the biggest problem facing concurrent programming today is the ‘herding of cats’ required to force programmers to adopt concurrent programming models. That, and concurrent programming is plain old difficult.

However, there are winds in the air that modern CPU architecture will finally force us to use concurrent programming. As it turns out, these winds are what has propelled good programmers all along; the desire to write a program that runs well on current hardware. To avoid bloat. To be efficient. And small.

As Java programmers, and more loosely as object oriented programmers, the desire to be re-usable (as OO programmers) and the desire to show that Java is superior (let’s face it, it is) similarly propels us to do our best to embody the principles of OO programming.

So let’s get to the point. Java doesn’t have an easy way to do Threads. You have to make all these complex checks and balances and it’s just a big bother, isn’t it? Plus, if you do design or think about program flow, it’s all too easy to visualize program flow as a straight line. A = 1, B = 2, A + B = 3. No one thinks about setting A and B at the same time. Why? Besides not perceiving a need (due to outdated, single-core hardware), one answer could be speed.

Setting A and B might take less than a handful of nanoseconds on a fast computer, but starting a new thread takes time. On my i7 system, I timed the creation-to-execution time and main program impact of 1 million threads. Every time I created a thread it cost my program about 35 milliseconds. Additionally, each thread began executing approximately 18 milliseconds after it was created. Obviously, creating a thread just to add two numbers at the same time is a waste of CPU time. Secondarily, you would need to wait for both threads to finish executing before you added the numbers. So all-in-all, calculating when you should use concurrent programming is a really big headache.

Incidentally this is also why the “sufficiently smart compiler” will never exist; calculating execution time can’t be done in advance. CPUs might be slower or faster, it’s based on real-time and not on some variable which can be known ahead of time.

So what do we know?

a) Concurrent Programming takes a small amount of time to set up (around 50 milliseconds on an i7, on average).
b) It’s easiest to use for small, independent, “fire and forget” tasks that don’t need to be synchronized with the main program.

Have any lightbulbs flashed yet? Well, let me tell you a story.

I was writing code on my Kongzi project, and it kept crashing in the UI thread, which locked up the program itself. I had to open task manager to close it which was a pain. I realized that I was committing a mortal sin of the UI world; I was doing extensive processing in the UI thread. The user would click a button, and the UI thread would fire the button event, which would take the software on a merry romp through CPU land. This was unacceptable, but I didn’t realize I was doing it. Later on, had I put the code into production, the UI would have seemed unresponsive and sluggish under more stressful “normal” use conditions.

So I decided to use a new thread to process the data and “return” immediately. After all, clicking the button just tells the program what to do. We don’t need to freeze up the UI thread each time.

It turned out to be a genius idea. I created a method like this:

// This function does whatever you want -- in a thread!
public void doWhatever()
        (new Thread() {
                public void run() {
                        // Thread Code Goes Here
 // return immediately!

Now notably, such a method can’t return any data (but it can modify global variables), since it does everything in a thread. But it’s perfect for updating status labels, for auto-saving, for printing, for doing any kind of complex task that you don’t want to do in the UI thread. One example can be logging. If you need to institute extensive logging, using a method like the above will return in about 35 miliseconds. No I/O time will be added to the main program. There are surely many applications for this in gaming as well; adding a thread which changes the status of an object over time, and exits on it’s own after a predictable length of time, is an easy way to code simple physics like gravity. Say, for a mario-world/2d platform game. Shots from a spaceship, for example, could be controlled by a thread. This would clean up your game loop considerably.

Now, you normally wouldn’t want to create one thread for each force vector on an object, for example, because 35 miliseconds of game loop time is a lot; that would be only about 30 “shots” which could be fired, or 30 objects created, forces applied, etc. per second. This could have disastrous effects on a program which requires 60fps or higher. Never fear; Have a monitor thread that creates threads for you! If it’s backlocked, it can clone itself and work twice as fast. What it does is monitor a queue and create threads. So you just “list.add(“object name”); for example, and the little helper threads go crazy doing their little thing. It all seems so simple now! The only problem would be locking the list so only one helper thread can pull a value off of it at a time. That’s not really a problem. Use the volatile keyword. “public int”? “public volatile int”! No problem. Use a synchronized block of code. Use a SynchronizedList. No problem! The point is that it will take far less than 35 miliseconds to add data to a list and pull it off again. This kind of simple messaging will help you return values from methods which run in threads as shown above.

In short, threads aren’t really that difficult or time consuming. They can really help. And sometimes they’re even required to achieve certain effects.

I’ll be able to post some more specific examples of this in a bit. Right now, I have to go to work. Sayounara!

Kongzi Beta-8 announced for June

Okay. Kongzi Beta-7 has been in classroom-use testing for about 6 months now and it seems pretty solid. A lot of changes have gone on under the hood. It’s using a database for the main type of save files now and you can merge (import) data from other files without destroying your user info. This will be tuned as time goes by, but as of now it is solid for general use.


All the quizzes have gotten a swift kick up in power, they now don’t just present random items but will sometimes present items which are similar to the correct answer. To do this I have created an engine which analyzes the user’s expected knowledge level and searches for similar words .This works in any language and with sentences (shown below) as well as with words (shown above).

Another thing which I’ve done is add the list of test mistakes to the score screen for easy studying. The following example is from the dictionary I use to teach “Let’s Talk in English” to Chinese students.


Once I give the manual a once-over and double check a few features on my to-do list, I’m going to have to start looking at how to package this beast.

For one, I plan to blow away the competition by offering a companion textbook with preloaded vocabulary. The MCI Chinese project (see the navbar up top) isn’t dead at all and has actually expanded with sister projects such as MCI Japanese and so forth. Here are some shots of the MCI Japanese book, “Welcome to Japanese”:





As you can probably guess I’m really excited to have reached this point in the Kongzi project and I will be able to package and offer these materials to YOU (well, to anyone) very soon. Target is this summer, around June for a complete Chinese/Japanese/Korean package which will take you from step one to “fluency”.

Thank you for keeping patient all these years. The wait has been difficult for me, too! But it is almost ready now, for real!

One step at a time..

An old draft from September 2009…

In just a few short days I seem to have come far enough that I am regaining my confidence working on this project.

I’ve re-integrated all the old logic back into the forms and re-created the “kong” and “ze” graphics from the calligraphy work I had done before. I’ve also identified several key areas which could be improved. For example, Beta-3 had a selective export feature. I asked myself, why was this necessary? If someone wanted to selectively export something they could just delete the stuff they didn’t want and then save it. So, this seems to make more sense, just save everything at once.

I also found and fixed a bug in my unicode encoder-decoder ring. Additionally I’ve completed the new export dialog design and as soon as I hook it up I can delete the old code for exporting tags and what not.

There’s just one problem. I don’t know what look and feel I was using. You can see a blue tint on the screenshots. I like that. And I can’t remember what I was doing. Ungh. I’ll figure it out later. Top priority is getting the anki/stackz-style flashcards up and running.

One step at a time… I’ve been reminded why I’ve been so successful with Kongzi so far. One step at a time, keep chewing away…