Java: En Guard Retired

The En Guard program has outrun it's usefulness in the tech support department. It has been replaced with a more robust Access database application that better tracks and retains information about customer contacts. It was fun creating the program and updating it with new features as the need arose. It it possible it will make a comeback in the future in a different form or for a different department, but for now it is simply collecting dust in my coding folder.

Java: En Guard Update #6

Beyond the search feature there were a few other minor changes I wanted to make to the En Guard program. First off the "Contact Info" JTextField is currently a required field to submit a new record. This field turned out to be less useful than I had intended so I am making it an optional field instead. At first I thought I would need to alter the code checking which fields are filled as well as the code that opens and saves the records. As it turns out none of this was necessary. All I needed to do was set the text of the JTextField to be a space character. By doing this the field is technically "filled" and saving/opening records works just as it did before. Good reminder to always look for the simple solution first and then work towards more complex resolutions.

The second feature I wanted to work on was making the skin chooser a bit more viable. Currently it works great to change the background color of the application, however whenever the app is closed it reverts back to the original color. This can get tedious to change such information every time the program is opened. Therefore I added a log in to the program that forces the user to choose a representative name before gaining access. This method is called before the properties of the JFrame are set.

JOptionPane.showConfirmDialog(aFrame, loginPanel, "Select Name", JOptionPane.DEFAULT_OPTION, JOptionPane.PLAIN_MESSAGE);
loginIndex = loginBox.getSelectedIndex();

The log in sets the loginIndex variable to the index corresponding to the rep's name. This information is then used to designate the file name that the program will need to open in order to determine what color to set the background to. Each rep has their own text file containing their color information, such as:

150
200
250

The file is then opened and each line of text assigned to the background color variables red, green and blue. Once done the SetBackground() method is called to change all of the JPanel's color accordingly. The text file will be updated whenever the ColorChanger() method is called as well, to ensure that the next time the program is opened it does so with the most recently selected color combination. As an added bonus, as the rep's name is being stored for this process, the Entered By field is automatically populated with the rep's name once the program is opened.

Java: En Guard Update #5

Two hundred and sixty-one lines of code later the Search tab is complete. The components were easily modified from other programs I have already made so putting the GUI together was a piece of cake. A combination of BorderLayouts and GroupLayouts were used for the look-and-feel portion. Once that was done the workhorses of this tab, the Listeners, needed to be created.


The Listener associated with the JList was copied along with the JList component itself and only small modifications were required to allow it to function properly. The JButton Listener however had to be created from scratch. Once the button was pressed several things needed to happen. First I needed to populate an array of file names for those currently present in the data directory. Originally I had gone with a brute force method since all of the file names are numbers ranging from 1 to 2.5 million. I had a For loop checking which files existed and if they did adding them to the JList component.

Obviously this took quite a bit of time to complete and slowed down the program considerably, enough so that it actually crashed the program on more than one occasion. Therefore a rewrite of the method (called by the Listener) was required. In reviewing the File Class I noticed a nice method named list() that would output a String array of the files present in a given directory. Exactly what I was looking for. Then calling a length method on the created arrays produced the exact number of files present so the slots used in the array is known and an exception isn't caused by trying to access a nonexistent array slot.

This search method was much faster than the previous one and does not crash the program at all, which was a nice bonus. Now a few other minor details need to be completed to have this version of En Guard finished. Specifically I want to add a log in dialogue to the program that will register which representative is using that version. This will allow me to auto populate the Submitted By field as well as save the user's skin color preference.

Java: En Guard Update #4

The way the program is currently written it is not very easy to modify or add additional components. Due to all of my work with JTabbedPanes with the CharSi application I decided to make a similar change here. To do this quite a bit of code needed to be altered and consolidated.

Up to this point I had two java files in order to create the GUI portion of the program. I decided to consolidate those two files together into a single java file, especially considering one of them was only 60 lines of code long. Problems came up there as I had used the same variable names for different components in each file so once they were combined the GUI was missing pieces. Eventually everything was ironed out.

The next step was to turn the main panel in to a JTabbedPane and each subsequent tab into it's own java file. Using CharSi as a guide this process was not too complex and left me with two workhorse files, Info.java and Search.java. Info.java contains the GUI portion of the application along with the methods utilized to open and save the informational text files.

Search.java will host a search engine that will allow the informational text files to be searched one at a time for a particular string. The resultant list will be displayed in a JList and when a selection is clicked it's contents will be displayed in a JTextArea. The other change that needs to take place is that the Contact Information field will no longer be a required field. It will still be present but the record may be saved without any information displayed. It simply didn't turn out to be as useful as I had hoped.

Java: En Guard Update #3

A bug came up recently in the En Guard program that allowed a representative to save a record without filling in the information as to which rep took the call and what platform the problem occurred on.

The fix itself was rather simple as there is already a check to ensure that the other fields (contact name, number, subscriber number) are filled in.

if ((tempNumber.compareTo("") == 0) || (name.compareTo("") == 0) || (input.compareTo("") == 0) || (contact.compareTo("") == 0))
JOptionPane.showMessageDialog(recordPanel, "Please fill in all fields before saving record.", "Incomplete Record", JOptionPane.ERROR_MESSAGE);

In order to include the two additional fields the compound OR statement needed to be expanded.

if ((tempNumber.compareTo("") == 0) || (name.compareTo("") == 0) || (input.compareTo("") == 0) || (contact.compareTo("") == 0) || (platformBox.getSelectedIndex() == 0) || (repBox.getSelectedIndex() == 0))

PlatformBox and RepBox are the JComboBox variables for the two associated fields. If their currently selected option is the initial value of a blank space then the statements will be true and the record will not be saved.

Originally I thought I would need to create another variable or two to track when the selected index of either JComboBox changed, but the getSelectedIndex() method made things so much simpler. Hopefully no other changes will need to be made to the En Guard program as this is the only report of an issue within the past three months.

Java: En Guard Update #2

I didn't expect to be making another post about En Guard this quickly, however I ended up having some free time yesterday afternoon to work on the one remaining bug in the program. The bug in question being the fact that the word wrapping was occurring by character and not by entire words, so it was difficult to read at times. My thought process for solving this problem was simple, yet not quite as simple as the final solution. I assumed that the reason the wrapping was occurring by character was because I was saving the file's text to a StringBuffer one character at a time. So I created a new StringBuffer, nextWord, where I saved all the characters of one work and then added this variable to the final StringBuffer as a word block. The below code was written to carry out this experiment.

while ( (c=myFile.read()) != -1 ) {
if (c != 32)
nextWord.append((char)c);

else{
textToDisplay.append(nextWord);
nextWord.delete(0, nextWord.length());
textToDisplay.append((char)c); }

}
textToDisplay.append(nextWord);

This code block replaced the original single line piece of code, which is colored above as it did remain in the block as well. For this code C is a char variable that as long as there are characters in the associated file then the loop is performed. A space character in this example is equal to 32 before it is converted to a char value, which is where the first part of the If statement comes from.

Once this code was written it was tested and lo and behold the same problem occurs. So I looked into the java API at the setLineWrap method and found that visible at the bottom of the page was a method named setWrapStyleWord. I was intrigued and once I looked into the method found that this was what I was looking for. Applying this method to both JTextAreas so that it was set to True solved my word wrapping problems. This resolved all of the outstanding issues with the En Guard Call Tracking System. I do have it in my mind to perhaps make the Platform and Entered By drop down menus alterable by the user as right now the lists are hard coded into the program. But that is for later, for now this program is considered completed for our work environment.

Java: En Guard update

The En Guard Call Tracking System had a few known bugs that we were living with for the past few months until I could find time to correct them. Specifically a record could be overwritten without any prompt and the old information lost. Also when a new record was saved the default text from the top field was added to the record on occasion. Solving the second problem was the easier of the two. At the end of the constructor the New() method was called, the one used when the Reset button is pressed. This seemed to resolve the problem as it was only happening on the very first record entered after En Guard was opened. After some testing it was found that if the Reset button was pressed after opening En Guard the issue would not arise, so this is now done automatically when En Guard is initialized.

The second issue was a little more serious, but still not too difficult. There is a test when saving that checks if the file already exists so that the old information can be inserted before the new call information. Using that check I wrote a boolean If statement that would cancel the save attempt and post an error message. This would happen only if both the file already existed and the text in the Current Record JTextArea field was still the default text instead of the output from the existing file. The user would be prompted to open the old record and copy the last call's data into the Additional Information field before saving the record.

Now the next bug to fix is the word wrapping for the JTextArea fields. Currently any text will wrap, but it does so in a way that leaves part of a word on one line and continues it on the next. It wraps separate characters instead of the entire word and I think I'll need to completely rewrite that part of the program to correct this issue.

Java: En Guard Call Tracker

I haven’t been able to create any personal projects for java programming recently but thankfully the workplace creates them for me. One thing our technical support department has always lacked is the ability to keep track of what each call was about so that if that customer calls back we don’t have to recreate the wheel. I do know that my company is working on purchasing just such a program but that will be at least a year in the future. So recently I created a poor man’s call tracking system for only our technical support group and not the entire call center in general.

I named the program En Guard as I was playing with the GoldIcon program to create icons and one of the ones I liked best was a shield with swords on it, rather medieval looking. It sounds much better than the original name of “Technical Support Call Tracking System”. This program will save all call information into a text document, Microsoft Word, with the documents organized by subscriber number and saved into a central location on our network. The call information itself that is asked for is very basic: name, subscriber number, contact information, representative and product version. Beyond that the topic of the call is recorded and entered before the record itself is created and saved.

This program went through several versions before a working one was produced. The most difficulty part was getting the program to read a file already on the network and save any updates accordingly back into the same file. Thankfully something similar was done with the AMAS program so as in that program a FileWriter/Reader was created. The entire program consists of two files; one for the main window with the buttons at the bottom and the other for the panel containing the variable information. Each document is setup the same way with the variable information at top followed by the contents of the call. So the FileReader reads and erases the customer information one piece at a time to fill in those fields then takes the rest and places it into the “Current Record” field. In order for this to work the spacing of the information had to be hard coded into the system, which wasn’t the most elegant way but is effective. The Platform and Entered By fields are also hard coded into the program, so if this were to be altered for someone else’s use the basic code would need to be altered.

With this program, unlike the other ones, I was able to obtain some feedback from my colleagues to make it more user friendly. The suggestions taken were setting the JTextArea fields to accept word wrapping, automatically adding the current date to the record, adding a separator between record entries rather than a simple newline character and last but not least a skin chooser. The skin chooser was more of a joke one of my colleagues threw out at me as he didn’t like the color I had picked, light goldenrod. But I took it as a challenge and it turned out to not be as hard as originally expected. Making sure I caught all of the setBackground calls in the skin chooser method was a bit tough, but perhaps that was more because I was trying to do it manually since the entire program is about six hundred lines of code. In order to change the program’s skin I did have to ask for the RGB values, which of course no one knows off the top of their heads.

Overall not the most difficult program I’ve created however it has been very useful in the workplace, being used several times a day. Some updates do need to be made, specifically that a skin can be used that obscures the JLabels as they are defaulted to black, a record can be overwritten without prompting the user if that is really what they want to do and the Platform and Entered By fields don’t need to be hard coded. I’ll get to all of these in the future, but for not the program is working quite well for our limited needs.