Posts by JamesCherrill

That's how you use a swing timer. java.util.timer is different. Check its schedule(...) methods.
ps: Why not use a swing timer?

Sounds like you haven't got the allocation of functions to classes quite right. An ActionListener that accesses buttons should be in the GUI class. A "MyFunctions" kind of class should be reusable from various front-ends (Swing GUI, browser interface etc), and thus can't contain any hard-coded references to a particular front-end.

Typically, in the GUI ActionListener you would collect user input from the form then pass it as parameters to the fuctions object, which returns one or more values that the GUI can then display. So the GUI class handles all the form-based GUI stuff, and the functions class just does the logic/claculations etc.

Your case here is a little bit special, in that the underlying functional model is a model of a user interface, but this still works if you keep the model abstract in terms of how the user interactions are actually displayed.

Finally - you may need to use a Listener ("observer pattern") to handle GUI changes that are initiated by the functions layer (eg changing state after a delay). This is also very common when this kind of architecture is done right (Swing itself is a reallly good example!).

Yeah yeah yeah, we get all that. But "Where are you initializing the `_myFObj` object"?
In other words: where exactly do you have the following syntax fragment:
_myFObj =

exactly, I don't know why is it null

A reference variable is always null until you assign a value to it

Have a look at HashMap. It will let you store the 3 letter abbreviation as a key and the one letter abbreviation as a value (map.put(key, vaue)), then it will give you an instant lookup of the vaLue associated with any key (value = map.get(key));

Looks like you haven't read the whole NPE message properly - it's the very first line it mentions that you need to look at, the rest of the lines it refers to are just how it got there.

Suggest you do what I said previously. Generalities don't help when you have an error that even a computer can spot.

titsn5: Sorry, norm and I seem to have hijacked your thread a bit. how are you getting on?

There must be close on 1000 lines of code there - so, sorry, but I don't have that kind of free time.
But
null pointer means either an un-initialised variable or you valled a method expecting it to return something, but it didn't.
Here's what you need to do:
look at the line in your program where the NPE is raised. How many variables or retrned values are there? If its very complex, break it down into smaller steps and see which one throws the NPE. Add a line immediately before that staement to print all the variables and returned values, so you can see which is null.
When you know what is null you can work back to see why.

Sometimes the simple approach is best - the basic recursion scheme I outlined above runs the 10 dice/44 case in 300mSec on my 3 year old laptop.
Eliminating the duplicated cases is the killer (ie same digits but in a different order) those 1151370 combinations represent only 83 unique cases, but the best I can do is 5 seconds to eliminate the duplicates.

Generate base 6 string of digits, sort the digits and store in a HashSet

Yes, that will work - but it's going to be v slow if n is large. I was wondering what the most efficient way ws?

Hi Norm. I guess your single loop is just the flattened version of the nested loops - ie 1 loop with 6^n iterations rather than n nested loops with 6 iterations? What's the value of n for max int?
I too was more interested by the 6+2 == 2+6 problem - looks like a challenge to find a way of encoding the solutions such that they can quickly be compared for equality disrgarding order. Best I can do so far is to encode each solution as a 6 element array = no of 1s, no of 2s ... no of 6s. Reasonably fast to encode and compare, but I can't help thinking there's some other much smarter lateral approach.

If you need an exact answer then I think you can't avoid Order 6^n.
Since this is your assignment it would be against the rules of this forum for me to just give you the algorithm.
But here's a thought...
Find all the ways of totalling t with n dice is the same as finding all the ways of totalling (t-1) ... (t-6) with n-1 dice. Recursion anyone?

Yes (There are cleverer ways of structuring it, epecially when the number of dice is variable, but they still all come dowm to n nested loops).

Is there any special reason to use an array for statistics? This kind of tree-like structure fits very badly in arrays. Why not just add them to the class itself? This is a much more "object oriented" way of thinking. So in each class you have public getter methods like (for the Page class)

public int getParagraphCount() {
   return paragraphList.size();
}
public int getSentenceCount() {
  int n = 0;
  for (Paragraph p : paragraphList) {
    n += p.getSentenceCount();
  }
  return n;
}

Now you can access anything by a very natural for-each loop using the objects themselves, rather than trying to compute and understand array indexes.

It's usually better prectice to get statistics like this "on the fly" rather than calculating them and storing them, if the overhead isn't large. This way they are guaranteed to always be up-to-date.

As for saving the parsed data, why nor just declare the classes as Serialisable and write the top Document instance to am Object file?

@Override is also v useful when you're reading other people's code. Without it there's no way to see that a method is overriding another without checking every method in every superclass by hand.

It's called an annotation - they were new in java 1.5 (ish). This one says that the following method is intended to override a method in the superclass (or implement a method in a declared interface). It allows the compiler to check that you are overriding as you intended - before annotations, if you spelled the name of a method wrong when you tried to override, you wouldn't get an error message, but the code wouldn't do what you expected.
Now you know what they are called you can google for a load more examples.

Use the solution I gave you in my previous post - and have a different anonymous inner class, each with its own different actionPeformed, for each button:

myButton1.addActionListener(new ActionListener() {
  @Override
  public void actionPerformed(ActionEvent e) {
    // do whatever you want when button 1 is pressed
  }
});

myButton2.addActionListener(new ActionListener() {
  @Override
  public void actionPerformed(ActionEvent e) {
    // do whatever you want when button 2 is pressed
  }
});

// etc

Merk thread as solved? ps which solution did you use?

You can do this in a more compact (but maybe less readable?) way by using an anonymous inner class, eg

myButton.addActionListener(new ActionListener() {
  @Override
  public void actionPerformed(ActionEvent e) {
    // do whatever
  }
});

Have a public method in the first class that accepts the object array as a parameter.
Pass the first window as a parameter to teh constructor of the second window.
When the user clicks OK you can then call the method in the first window to return the data.

Edit: Thanks norm: ... unless you need the first window to be blocked until the second is complete, in which case use norm's solution
J

Norm is right - the word in bold should not be there.
And don't worry - your English is good enough. A lot better then my ... Spanish?

Yes, of course. The code inside the loop would execute exactly once, regardless of whether the final reult was valid or not. If the user entered an invalid char they would not have a chance to try again.

That last break; is redundant but harmless. On balance it may be a good idea to get in the habit of always remembering to put in a break; because when people forget the break; (ecept on the last case, of course) they end up with bugs that can be very hard to find.

You have a block of code in a do { } while(! valid); loop
The code will be executed once.
If, after that, the boolean valid is not true this indicates that something was not correct about the execution, so the loop is executed again.
The do/while will keep on executing the code over and over again until it results in valid == true.
This is a very common way to use do/while.

I wasn't thinking of directly converting the file to XML... there were two separate ideas:
1. Have a class that handles the basic parsing of the file and has methods to get the next char or delimiter. How this works internally is private to the class.
2. Add methods to Word/Phrase etc to output them in XML format so you can see how well the code is working.
I have to go now - I'll be back later.

Yes, you should write the file like in your example - obviously there's a bit more syntax needed to make that work - more like
myOutputFile.println(dvd.getDvdItem() + "\t" + ...
Where to introduce the reader? That depends on your requirements, but you should probably make it a little self-contained method, and call that right at the start of your program - if it that turns out not to be right you can easily move or duplicate the call to wherever else it needs to be.
You'll find loads of sample code on the web, so I'm not going to spend any time writing another sample - just use Google, and look for the simplest one you can find.

This is the Java forum - I suggest you post this question in the databases section instead.

I had some more thoughts - feel free to use them or ignore them...
I would separate the messy business of parsing the chars and delimiters from the logic of building the doc structure. Instead of passing a Scanner, I would build a class to do the initial parsing and pass that around instead. It only needs 3 public methods: get next char, get next delimiter, "peek" at next delimiter (ie return the delimiter but leave it on the stack). I'd pass the file name into its constructor so all the choices about scanner vs byte array parsing etc are hidden inside it. That will make all the code easier to understand, allow the parsing to be tested before its used in the doc structure classes, and allows you to change the implementation if you get into difficulties.
I's return the delimiters as int values (1= word delim, 2= phrase delim etc) describing the exact type of delimiter, so you can test for == WORD_DELIM or >= WORD_DELIM - I think you'll need to do both.
Finally, I'd add a writeXLMto(PrintWriter out) method to all the doc classes so I can easily display and debug their contents - eg
word.writeXMLto gives
<Word>Fred</Word>
then you can use that for Phrase to give:
<Phrase>
<Word>Fred</Word>
<Word>Sally</Word>
</Phrase>
etc etc

Let me know how this goes - I'ts caught my interest!
J

Ah ha! I thought the code to read the file wasn't in th epart you displayed - I hadn't realised that it was completely missing!
So here's some simple guidance:
1. You write the file in a way that's very easy for a person to read, but harder for a computer to parse. Keep it simple. Write each DVD as a single line, with just the data, and a tab ("\t") between each field. Use a PrintWriter for simplicity.
Read the same file back in with a BufferedReader, one line at a time. Use the split(...) method from the String class to split each line back up into individual fields. Use those fields to (re)create the DVD objects.
All the other info you need is in the Java API doc for the classes & methods I mentioned.

"super" means this classes' immediate superclass - in this case it means "Person".
Because Employee inherits from Person, any constructor for Employee must first call a constructor from Person to ensure that all the inherited variables etc are correctly initialised. If you don't do this explicitly the compiler puts in a call to the superclass default constructor ie
super();
But if you want to use some other constructor from the superclass you must explicitly call it yourself as the first line of your constructor.
So,, in this case, when someone calls the Employee constructor with name etc, the first thing that does is to call the Person constructor with name etc so all those variables are initialised correctly.

The catch on line 24 seems far too general -so if you get an error acessing the data or converting it, or anything else, you always try to create a dircetory and try again. You should check for the exact exception that means you have a missing directory, then follow that with a second catch for "Exeception" that will catch everything else and allow you to treat it as a real error.

Hi ankilosado
Yes, the Scanner knows where its current poosition is, and it's considered better Java style to pass something as a parameter (ie share it in a controlled way) rather than making it public static (ie totally uncontrolled sharing). (When you pass an Object as a parameter what you are really doing is passing a local copy of a reference to the Object, so all the local parameters are references to exactly the same Object.)
As for the double CR problem - I automatically dislike the idea of special-casing this. Won't there be other similar cases? Eg full-stop+space at end of sentance is NOT two word delimiters. I never get to use Scanners myself, so I'm no expert, but can't you use hasNext for a quick look-ahead to see if the next "n" characters match a regex? If so, you can look first for the 2-character delimiters, and only if that fails, look for a single character delimiter.
As for empty elements: is this a gap in the spec? How should it handle consecutive delimeters (eg newPage/newPage - is this an empty page, or should you just ignore it?).
If you wnat top ignore empty elements completely, it's easy enough to chcck them before adding them to the ArrayLists, ie replace

add new Phrase(input) to ArrayList

with

Phrase p =  new Phrase(input);
if (! p.isEmpty()) add p to ArrayList

wher isEmpty() is a trivial method implemented in each class

Here's a strategy that may work for you - it's kinda like a recursive strategy, except that the levels are pre-defined. Pseudo code fragments follow:

new Document(Scanner input) {
  create empty ArrayList of Pages
  while (not input.EOF) add new Page(input) to ArrayList
}

new Page(Scanner input) {
  create empty ArrayList of Paragraphs
  while (not input.EOF) {
    if (next token in input is a Page delimiter) return;
    add new Paragraph(input) to ArrayList
  }
}

new Paragraph(Scanner input) {
  create empty ArrayList of Phrases
  while (not input.EOF) {
    if (next token in input is a Paragraph delimiter) return;
    add new Phrase(input) to ArrayList
  }
}

...


new Word(Scanner input) {
  create empty ArrayList of Characters
  while (not input.EOF) {
    if (next token in input is a Word delimiter) return;
    add next Character to ArrayList
  }
}

Yes.

This may help you: for each of yopur classes create a public String toString() method (overrides the defaultg useless implementation in Object) that returns a printable representation of the values in that class, then use it to print out the values before & after serialisation.
Every class should have a toString - it's really valuable for every kind of debugging.

Did you implement "equals" methods?

Your deserialised object(s) will contain data with the same values as the original objects - but they will not be the actual same data items as were serialised (eg: you may serialise to a file, quit your app, close the JVM, start a new app in a new JVM and deserialise the objects - values will be the same, but the original objects will be long gone).
== tests for two references being references to exactly thwe same object in the JVM's memory, which these are not.
If it's appropriate in your app (eg) for two of your object to be considered equal if they contain the same values, then you need to give them an equals(Object 0) method that compares all the values and returns true or false as appropriate. This is exactly what happens with String objects - the String class has an equals method which returns true if both strings contain exactly the same sequence of characters, even if they happen to be two different String objects in memory.

~s.o.s~ Well, yes.
I generally wouldn't put UI behaviour into any kind of State model. But given a view of what this app is about, it seemed a useful compression to alangamate the two. But, no. I'd never do it in real life.
I wouldn't hesitate to put behaviour as well as data into an enum definition - why on earth not? - but only if the behaviour was an intrinsic aspect of the model.
"paintBox" was just a sketch to show how behaviour can be incorporated - obviously it would need something like a Graphics + x,y coords, or a JLabel for an ImageIcon, anything like that.

I really like the use of enums for state, especially because you can define different implementations of a method for each member of the enum. This allows you to compress the whiole interface/mutiple state classes thing into a single enum. Eg:

enum State {
   waiting() {
      @Override
      public void paintBox() {
        // code to paint black box
      }
   },
   go() {
      @Override
      public void paintBox() {
        // code to paint green box
      }
   },
   stop() {
      @Override
      public void paintBox() {
        // code to paint red box
      }
   };
   abstract public void paintBox();
}

Then in your program you can have something like:

State s = State.waiting; // or whatever

and call

s.paintBox(); // to get the appropriate paint behaviour.

By all means have fun and learn by doing that. However, I would say that
1. There is no single "most efficient" way; it will depend on exactly what you are doing
2. In practice you need to code as clearly as possible, test and run it (optimising before dugging is guaranteed to be a waste of time), then IF there is a problem profile the code to see exacly whaere the problem is, finally optimise the code where the problem is.
Recent versions of Java have a load of optimisiation built into Swing's screen painting, most of it hidden from the ordinary Java programmer - so you may find that an apparently good idea actually makes things worse because it conficts with or disables a built-in optimisation.

Before starting to optimise... do you know that you have a perdormance problem?

Sorry, my my bad, copied/psted too quickly. Should be
new Timer(5000, new ActionListener() { etc

re the timer - yes, that's the right way. You can compress the code by using an anonymous inner class, but it still comes to the same thing in the end.

_myTimer = new Timer(5000,new TimerListener() {
public void actionPerformed(ActionEvent e) {
resetState();  // leave this method in the main class
}
});

I have no experience of the State pattern, so can't help you there, sorry.

You need to create a new instance of your SwingWorker class each time the button is pressed - I don't have your code, but presumably you create the instance once, then start it in the button's action handler - in which case just move the code that creates the new instance into the handler.

Leave the setVisible(true) as it is.
Run myFunction in a SwingWorker thread (see the API or online tutorials)
call the setVisible(false) immediatley after myFunction runs (eg add it to t he end of myFunction - simple, even if it's bad design).
This is the way - a bit of a learning curve, but essential for real JAva programming anyway.

Fortunately (!) there's exactly one right way to do this: use a Timer... That's a javax.swing.Timer, not a java.util.Timer.
Set up the timer to run once after 5000 mSec, and use it to call your resetState method.
You'll find loads of examples on the web, just copy&paste one that fits.
It may look a little complex at first sight, but it's a standard Java idiom that you'll need to get comfortable with anyway.

After a VERY quick look, looks like check() disables them then immediately calls resetState which enables them again

I'll say it one mire time. The code as posted will NEVER display the label because it's made invisible again before the action method returns. Swing is single-threaded. Repaints and action methods execute on the same thread. The repaint will not happen until the action method terminates, at which time the label's visibility is false.
NormR1 is right.(Use a SwingWorker thread). The other posts are irrelevant.

Don't have time to explain now, but your setVisible on line 5 won't do anything until after your actionPerformed method terminates. It's a threading problem - Google the Swing Event Dispatch Thread.

Its a workspace that you have to open, not a project. Projects exist within a workspace, and can only be opened after you have the appropriate workspace. See "switch workspace" in the File menu.

What do YOU think is wrong with it? Have you compiled it? Have you executed it? Have you tried executing it with a different value for i1 (eg 0)?