Campbell Ritchie wrote:Where does that code come from? Why does it look so similar to Laura Peterson's, even with the same mistakes repeated? Are you on the same course as her?
I would probably not now design the node like that; I would make the letter final and I would give it a morseCode field. Once you add that field it becomes very easy to print S ... because the Node or some MorseCode object will encapsulate both data.
I would probably also make MorseCode implement Comparable<MorseCode>, or write a Comparator. You should be able to make those consistent with equals(), and you can create a tree around that.
Campbell Ritchie wrote:Expunge the word “float” from your vocabulary. [At least whilst programming.]
Why have you got so many instances of the keyword static?
Divide your task into smaller parts. You need to read from the file before you do anything else, so show us reading on its own. Don't mix reading and anything else. Do the other tasks, like counting words and sentences (which I think you are doing wrongly) later.
Rob Camick wrote:
Any idea what I could be doing wrong.
Seriously? How would expect us to guess what the problem is by looking at a picture?
Post a proper SSCCE that demonstrates the problem.
Since you question is about layout, then all you need is the frame and the components (not any of the processing logic of the components). By simplifying the problem it is easier to find the solution.
And my advice is to NOT use an IDE to generate code. The code will not be maintainable if you ever move to another IDE. Instead create the layout code yourself and just use the IDE for compiling and debugging etc.
Stefano Carniel wrote:What about Javafx? It's based on MVC pattern and you have complete separation between views (screens) and logic
Stevens Miller wrote:
Knute Snortum wrote:I think using import statements and short names in your code is the preferred way, but I'll post this to the IDE forum to get other opinions.
My opinion is that your opinion is correct.
As a C-to-Java programmer, I jumped to the false conclusion that "import" was Java's version of C's "#include" preprocessor directive (which may mean it isn't even part of C, but that's a topic for another thread).
All import does for you is allow you to refer to names defined within other packages, without having to qualify those names with their full package names. There are a mix of views on how best to use import, but I would venture to say that everyone uses it at least some of the time. Where it can fail you is if you must refer to symbols in two different packages that have the same short names. Consider these three classes, each in a different package:
Line 8 in that third bit is going to cause a compiler error, because the compiler knows (owing to the import statements at Lines 3 and 4) that both the thehill.jack package and the thehill.jill package define a symbol named PailOfWater. The compiler has no way of knowing which one you mean. You can solve this problem by refactoring one of the two packages (but that would mean refactoring all their clients in the light-cone created since you first deployed the second package), or you can resolve the ambiguity with full qualification:
Note that, even though both packages are fully imported, there is no ambiguous reference in the code above, so the compiler happily tolerates the fact that a symbol of the same name is defined in two different, imported packages. Until it needs to find an unqualified symbol in an imported package, the compiler doesn't care if that symbol is defined more than once.
Note also that none of what I've said depends on thehill.jack and thehill.jill starting with thehill., as it will apply if those packages were just named jack and jill, (I just named them the way I did so they'd all show up near each other in "Experiments" project package tree in NetBeans).
As for JFrame in particular, you will see that NetBeans loves to subclass JFrame to create your "main" window for you. This is usually harmless, but folks here persuaded me that it's not the best practice, and offers no meaningful benefits. Better is to create a JFrame directly, and put a JPanel into it that you use the NetBeans GUI editor to create. If you are just getting started, go ahead and use the JFrame subclasses that NetBeans creates for you. Just remember someday, if you can, that creating your own JFrame is probably what you ought to be doing.