Try Catching Explosions

For some reason it seems like a lot of people who are just starting their programming degrees claim that try-catch blocks are a hard concept. That combined with a little office humor inspired this post:

Okay, the basics: a try-catch block in Java is really composed of the following:

try{}
Catch(Exception e){}
finally{}

So we place any code we think might cause an exception in the try part and thecatch part is where we place code to handle the exception and the finally block executes if there's an exception thrown or not. So using a subclass of Exception, ExplosionException, we can check code for explosions and deal with them as follows:

methodThatCanNeverExplode();
try{
methodThatMightExplode();
}
catch(ExplosionException e){
methodToDealWithAnExplosionWhenItOccurs();
}
finally{
methodToExecuteAfterTheMethodThatMightExplodeRegardless();
}

Okay so maybe this is a useless post that does nothing more than make my blog more recently updated and let me ramble about a subject usually covered in an introductory programming course.

The Sky is Falling!

The world is doomed, I posted to my blog!

Selection Preserving on JTables

This is a random useless post, I really don't have much to say right now. I can provide a small tip on JTables.

We ran into the case where we had a model that sorted its data and then refreshed the table with a call to fireTableDataChanged() in AbstractTable. Generally this is a good thing as it rebuilds the table from scratch (no need to keep track of how many rows were deleted/added, etc.); however, in our case it had a nasty side-efffect: the selection was cleared in the table. What we needed was a way to track the rows before and after the search and then be able to restore the same rows (in their new position) as selected. When I searched on the Internet for other people who had similar problems (i.e. fireTableDataChanged()) and the solution was simple and consistent across all sights...you need to save and restore your selection. That being said, this blog may be a good place for a quick abstract rundown of what we encountered and how we fixed our tables to preserve selection.

1) We created an interface to mark TableModels that we needed to preserve selection.
2) We wrapped each row of our table (which were fortunately Objects) into another Object that referenced the table data and a unique ID that was incremented in that TAbleModel when a new row was added.
3) When our custom Table had its model set to something with this interface it created an instance of a "bridge" class, which the Table and the TableModel had references to.
4) Before calling fireTableDataChanged() we saved off the unique IDs that were selected in the TableModel.
5) Inside our table we overrode the TableChanged(TableModelEvent) inherited from JTable to call the super version of the method and then select the rows whose unique IDs we saved off.

"Rubber Stamping" in Java

I've placed this here for 3 reasons:
1) I said there might be some code here.
2) In an application with even 10-15 similar items this makes a difference.
3) This way I can look at my blog to find this rather than trying to jog my memory searching through piles of code and trying to remember where I've done something similar.

JLists and JTables in Java have a performance feature loosly termed "rubber stamping". The idea is one static Component exists that is drawn on the screen multiple times rather than having a seperate control for each cell, I've seen this make a performance difference with as few as 10 similar componenets.

Beyond instantiating a class or static Component there are four steps to drawing it on the screen in multiple places:
1) Set the variables of the Component
2) Use graphicsInstance.translate(int changeInX,int changeInY) to move the origin of the Graphics object to where the componenet will be placed.
3) use sharedComponeentInstance.setBounds(int parentX,int parentY,int width,int height)
4) Finally draw the component on the screen (for a regular Componenet instance try: componentInstance.paint(Graphics translatedGraphicsInstsance).

One more thing: Get a Gladius Hal.

It's Here.....

Coworkers asked for a blog and now here it is (so my coworker with the extra pink blog can remove it now).

I'm sure there are many questions being asked about this blog right now: What will be on the blog? Good question. How often will I update it? You probably don't want to know. Will other things take priority over it? Most definately (work, school , family, etc.) When will your profile be up to date? Good question. Do you have any interest? Yes, I just havn't put them down yet. When will you use on a nondefault template? Sometime.

I will probably have programming and gaming stuff up here soon, what exactly is a good question. Why nuclear monkey of doom? I'll explain that later as well.