Posts by JamesCherrill

Like I said earlier:
Around line 92 you should print the exception e to see exactly what went wrong and where
can you pass a string in that kind of format and receive it in args[0] (try printing it)?

I'm not sure what you are trying to do there. You currently seem to accept three runtime arguments and parse those correctly as a date, yes?
Now you want to pass a single argument that is a String in format DD/MM/YYYY or DD,MM,YYYY, yes?
Step 1 - can you pass a string in that kind of format and receive it in args[0] (try printing it)?

Given the restriction of not using stuff you haven't been formally taught yet, I think you're doing very well. That's nice code, properly designed, formatted, commented etc. It looks quite professional. We see a lot worse code posted here.
The sooner you can start working with more of the language the better.

Problem is: if month is invalid your array index daysInMonthArray[month-1] will be invalid, so the JRE will throw an unchecked runtime exception and your date method will terminate abnormally without returning any kind of explanation message. If you validate month first it will return "Invalid month "+month, which is correct behaviour.

Line 98 you use month to index an array, but you don't validate month until line 101. So an invalid month is going to throw an exception on line 98. You need to validate month first.
Around line 92 you should print the exception e to see exactly what went wrong and where - you may be surprised.

Before you start messing about with those kinds of methods I would suggest you write a known double value to a file (just like you did with the int) and compare the hex with the same value written from C++. Then you will know what you need to achieve by way of swapping bytes etc.

You'll see "mark this thread solved" just above the box where you can type a new message. Just click it!

I have no idea - somewhere in the dusty recesses of the remains of my brain there's a lorry-load of stuff that I came across somewhere sometime and thought "that's interesting". I can never remember the details, but it gives me a starting point to hunt it down again.

It's an int! It's a byte! It's a string! Its an int but backwards!
My head's spinning.
But here's something you may find useful, based on your most recent post:

int abcd = 9999;
int dcba = Integer.reverseBytes(abcd);

So if you use that to reverse the bytes, then write the resulting int to your file, you should get the same output as your C++ program.
NB: 1. I haven't tried this myself. 2. Java 1.5 or later.

ps. Now I have tried it. It converts 9999 = hex 00 00 27 0F to hex 0F 27 00 00

You don't say what layout manager you are using, but you could resize the components in the window depending on which menu item is selected, then pack() the window so it fits the re-sized components.

Try again. Add a print statement in the same if to see if that path through the code is being taken as you expected.

If you have a while (true) you may want to consider calling break; at some point to exit the loop.

Not directly, no. You need to get an instance through which to access them.

Yes, if you have a "non-static" object ("instance") you can use that to call non-static methods. This is true whether it's all happening inside a static or non-static method.

If you have A - B (1 to *) then a collections of B stored in A encodes that info completely. Storing the B in A just duplicates that info, so it's redundant. You can find the same info by searching the As. But normally it's a lot easier to hold that redundant info, so that's what people normally do.

In general, if there is an aggregation relationship "an A has-many Bs" then you can use any member of the Collection hierarchy to hold multiple instances of B as an instance variable of A.
A simple ArrayList<B> is the most obvious choice, but if you want to access those Bs by, for example, their names, you could instead use a HashMap<String, B> to give you that access as well.
Holding the A as an instance variable in B is strictly speaking redundant, but in the vast majority of cases you would do exactly that because the code is simpler and faster.
It's hard to say anything more specific without a lot more info on your design criteria, volumes etc.

For so,me reason the word "parse" came out as {****. I have no idea why!

Anyway. SimpleDateFormat parses the input according to the pattern/format string. The default format is far too detailed and complete to use as a parsing template.
You need to create a SimpleDateFormat with a format that matches what the user can type in. The user will expect to enter data according to the format that's checked in the check boxes, so that's the format you should use for parsing.

You [arse using a default SimpleDateFormat - which is OK for printing, but far too detailed and complete to use as a parsing template for user date input. Better to create a SimpleDateFormat with a format that matches the current choice in your checkboxes.

Just declare it anywhere in the inner class. It must NOT be declared final, because that means its value will never change, so you can't use it for a loop. The code you posted earlier is good.

for(int i=0; i<5; i++) // i is declared here, in the inner class
 {
    item[i].setTitle(newAmmendTitle);
 }

I see no reason to declare i final - in fact it will prevent it being used as a loop variable. That piece of code looks 100% OK to me as far as i is concerned. The final is only needed when an inner class tries to use a local variable declared in the enclosing method.

No. I said declare the parameter as final, as in

public void ammend(final Broadcast[] item){

You didn't declare item as a local variable, but you did use it as a parameter name, which is much the same thing, thus masking the class-level variable. Try declaring the parameter as final.

" and the exact error message (including line number) "

I was only able to give a general description because the posted code is incomplete and uncompilable. If you post the complete code and the exact error message (including line number) I'll have a closer look.
J

You create an action listener inside a method, and the code of the listener refers to one of the local variables in that method. The problem is that when the action listener is called, the original method will have finished executing, and its local variables will no longer be available.
If you declare the local variable as "final" then the compiler knows that its value can never change. That means it's safe for the compiler to make a copy of that value for the listener to use after the method has terminated.
Short answer - just do what it said and make the variable final.

Just for clarity - because you may be misunderstanding what happens with the comma here:

private String[] ingredientName,units = new String [40];

is equivalent to

private String[] ingredientName;
private String[] units = new String [40];

The value part of an int for a negative value is held in "two's compliment" form, in which ffffffff is -1 and 80000000 is the largest possible negative number. It's a bit like inverting all the 1s and 0s for negative numbers, because that makes it much easier to design the hardware for adding numbers. The full story is a bit more complicated, so here's an article that explains it in great detail
http://en.wikipedia.org/wiki/Two%27s_complement

Sorry, that's as clear as I can make it. Just read it slowly and check any words you don't understand by looking on Google or Wikipedia

x=0xffffff0;
That's 7 hex digits, so the full value of your int, in hex is
0F FF FF F0
shifted 4 left that becomes
FF FF FF 00
ints are stored as 1 sign bit (0 = positive, 1 = negative) and 31 bits of value.
So on your 4th shift the first bit changes from 0 to 1 and the int gets interpreted as a negative number.

Wehn in doubt check the official documentation. Here's what the JLS says:

8.3.1.1 static Fields
If a field is declared static, there exists exactly one incarnation of the field, no
matter how many instances (possibly zero) of the class may eventually be created.
A static field, sometimes called a class variable, is incarnated when the class is
initialized (§12.4).

This makes it clear that static fields cannot be in any object that is an instance of the class. They are associated with the class itself. So although stultuske's explanation correctly describes the end result, Samith Dilhara's version is closer to the JLS.

It will take you about 1 minute to write a tiny program to test this. Try it with xMethod declared static or not, and see what the result it.
Tip: I have never known ~s.o.s~ to be wrong, never.

There's no function because you haven't coded any function. You just set the variable "ans" but you never use it.

On button: All you do in your code is set ans=true; so there's nothing visible to happen when you click it.

Off button: On line 217 you disable it, so it's disabled.

When the use clicks "on" you could disable "on" and enable "off" (and vice-versa for "off")

On line 217 you disable it, so it's disabled.
Maybe when the use clicks "on" you could disable "on" and enable "off"?

Are you sure its disabled? Is its text grey?
All you do in your code is set ans=true; so there's nothing visible to happen when you click it.

I already posted step-by-step instructions for you. Try following them. If you get stuck post what you have coded so far and explain what's stopping you.

No. I will not, and neither will anyone else.
This isn't a "we do your homework" service. There are lots of people here who will freely give their time to help you become the best Java programmer you can be, but there's nobody here who is interested in doing your homework for you.

Have a button with text "Off". Add the listener just like all your other buttons. In the actionPerformed, test if text is "Off" - if so, disable all the other buttons and change the text to "On", else enable all the other buttons and change the txt to "Off".

A big advantage of setEnabled(false) is that the UI will automatically update the appearance of the buttons so it's clear to the user that they are disabled.

If you're using Windows then it's possibe to get this problem because Windows file names are not case-sensitive, but files within a jar are case-sensitive. So if the file name in you code differs in case from the real file name it will work in Windows, but not in a jar.

On the contrary, it's absolutely essential. Every view class instance needs a reference to the controller class instance so it can pass requests back up to the controller.

ps: Normally its the controller that creates the new view window/tab, and passes a reference to itself as a param to the constructor. The other common parameter is a ref to the Model instance that this view is expected to work with. So somewhere in the controller you usually see something like:

JComponent aView = new OneOfMyViews(this, theModel);

Unless things get particularly complicated I can see no reason why the tabbedpane class can't also be the controller. In smaller apps it's quite common to see the formal MVC structure being simplified into just a couple of classes. It's still a lot better then a free-for-all spaghetti architecture!

Yes.
More specifically:
Controller: yes - high-level controller delegates "tasks" to lower level ones.
View: The whole point is to remove the need for any direct coupling between view classes, so the question of "nesting" doesn't apply here.
Model: The Model is what it is - but some subsets of the application may only use part of it.
So, in summary, "nesting" really only applies to Controllers, where its often a good idea.

It's very similar, but he uses subclasses for each tab whereas I would create one "template" class, including all the "duplicate" code, and have one instance per tab. Frankly I don't think that either has a decisive advantage over the other, so go with what you fancy.
For communication I would treat the tabs like any other collection of panels or windows - I'd go MVC (Model-View-Controller) with one or more Model (data) classes and one Controller. The Controller has all the code to manage the flow of logic as you open/close windows and move from tab to tab, and all the tabs share an instance of the Model so they all share the same data.

Wouldn't the easiest way be to make a super class tab, and define each tab as a subclass? Or am I out of my mind here? :)

You are not out of your mind. That's exactly what I would do (and I suggested something like it in my earlier post), except that there's no value in defining them all as different subclasses. Just create a class with all the common elements, then make the individual tabs instances of that class and add their specific controls as required.

OK! That's really helpful - this is all starting to make sense now.
So we definitely need to write a sequence of single bytes.
In that case it's definitely a DataOutputStream that you need, and you can use the writeByte(int b) method for single values or the write(byte[] b, int off, int len) to write an array of bytes.
For writeByte(int b) you need to specify b as an int in the range 0-255
For write(byte[] b, int off, int len) just be careful because bytes are expressed as values -128 to +127, not 0 to 255. So you may find it easier to use writeByte in a loop.

OK, got that.
So, moving onwards, let's stop worrying about the C++ program. You say the data is read by the "PLC". What is that? Does it have any documentation about the data it expects? Do you have source code for the part where it reads the file?
ps: a small point, but it will help to keep things clear: please use the term "bits" when talking about the 8 things in a byte. Use "digits" when talking about the characters 0-9. Thanks.

Hi riahc3
You are still missing a key point here.
"read them normally just like a C++ program" isn't an answer. There is no "normally". There are many many ways for a program to read or write binary numbers, and C++ can read all of them, depending on how the program is written. Unless you can say which of all those formats your C++ program is expecting, you can't write a file for it to read.

If, as you say, each int is written as a single byte, then you can use a DataOutputStream and its write method to write any arbitrary array of bytes. Note, however, that this cannot write the sample data that you posted earlier because that has ints >255. You cannot write arbitrary ints (in java or C++ ) to single bytes because they simply don't fit.

I'm sorry to hear that.

Did you try following the instruction in the error message and changing it to

switch (dir) {
  case RIGHT: