Posts by JamesCherrill

lines 3,4 you have two {

rch1231
Yes, that's a solution, but I hoped the OP would get the benefit of working out the solution for himself!

ddanbe
it will work (compile and execute without errors), so the real question is what does the OP want to do about fractions in the result? Declaring C as int and F as double seems to indicate a schizophrenic approach to temperature values :)

( 9 / 5 )

9 and 5 are both ints, so the division is done in integer arithmetic, giving the result 1

Re video: just what I suspected. You may find that threading the screen shot and the writing may buy you a little improvement - it's not hard, so give it a try. But I doubt that you will get much from it. Realistically you will have to accept a frame rate that your computer is capable of maintaining- which looks like maybe 24fps? (good enough for the cinema!)

Re sound: sorry, no ideas.

Maybe:
You have video code like

loop
   do CPU intensive stuff
   wait 20 mSec

that's only going to loop 50 times per second if the CPU stuff is instantaneous (which stuff like yours will definitely not be)
At the very least you need something more like

loop
   endTime = time now + 20 mSec
   do CPU intensive stuff
   waitTime = endTime - time now
   wait (waitTime)

My guess is that the screen cap/encode/write code takes just over 40mSec on its own, taking your total time up to just over the minute.
Anyway, a couple of quick print statements for the nano time before amd after the screen cap/encode/write will confirm it either way.

As for the audio - maybe 200 just gives you a sound too short for a human to notice? Can you count the actual number of samples written / 44100 ?

? That reads the wrong way round...
If you do not set a seed then the Random() constructor picks one - eg current time in mSec - so two runs will provide different sequences.
If you set a seed and it's the the same, then you will get the same sequence.

I meant, for example, allowing the user to chose his own preferred colors for his application. Or having different color "themes" that he can chose from. Or having different day/night colors.

With only 3 colors maybe if tests or a switch are as good as a Map, but I try to suggest solutions that are scalable and extendable and which relate better to what happens in real life. The Map approach makes it easy to change colors and allows for any number of color types, so that's what I would use.

Yes, I edited your post so it wasn't code, as requested.

Here's the thing about enums: they are fixed at compile time. So if your colors are hard-wired into the program, and you're happy to re-compile and redistribute your program for any color changes then enums are best.
But of you want colors to be configurable in any way then they will have to change at runtime and enums are not suitable (well, there are ways round that, but it's missing the point).
My guess is that sooner or later someone will want to change those colors, so you will need to read them from a config file or a user Preferences. That's where a simple Map implementation is by far the easiest way to go.

If you want the deluxe solution I would suggest an enum for the various types of color, eg

public enum ColorType {MAIN_BACKGROUND, SUB_BACKGROUND, NORMAL TEXT, ERROR_TEXT etc

then use those as the keys for a Map that links them to actual instances of the Color class, wrapped in a safe method like

public static Color getColor(ColorType ct) {
  return colorMap.get(ct);
}

That gives you all the type safety and self-documenting of an enum, but with the ability to configure the actual Colors that each type should use.

OK.
So all really you want is a getColor method to wrap some kind of Map<String, Color> so you can do stuff like

myField.setBackground(getColor("MyFieldMainArea"));

or maybe

myField.setBackground(getColor("MyField", MAIN_AREA));

<I have to go out now, so no more posts for at least couple of hours... stultuske, you still there mate? - can you take over?>

SO the intent is to replace ocurrences of GRAY50 with the background color (which may been defined by a previous call to the (invalid) method called Color(String) on line 15, or maybe is uninitialised). Why not just use the background color in the first place instaed of GRAY50?
And why return a String from a method that gets a Color?

It would be really helpful if you could explain what this class is intended to do, rather than just looking at individual methods that make no sense out of context.

Sorry man, I cannot understand what you just posted.

Why does a method called getBackgroundColor return a String? Why does it need a parameter? What is the significance of the String you pass into it?

If they take no parameters, then just return the appropriate Color like the examples in the enum code above.
But since those methods don't seem to create anything, let alone a complete schema, they are badly named. And if so, "SubjectAreaDefaultColor" can be just another color name in the Map or value in the enum.

re enums: it's probable that an enum will serve very well for what you are doing, and will provide type safety in method calls. But without a complete spec for what you need to achieve, it's impossible to say - eg if these colors need to be loaded from a user config or preferences file then enum's won't fit.

Before people write too much code...
What is the purpose of this class? Does it just hold some standard colors for yor app, and/or do you want to be able to retrive those colors by a name which is a variable at run time?
Colors are immutable, so you don't need accessors etc, just declare the Color variables as public final
If you want to retrieve them by name, build a private Map<String, Color> and populate it, then the public COlor getColorByName(String name) method is a simple get, regardless of the number of available colors.

It's obviously designed with the assumption that it will only encode/decode A-Z, so it's not surprising that it fails with a blank in the input.
Having said that...
args[0] is maybe just the first word of your input, the other words being in args[1] etc, depending on how you typed the command.

// call this once

that's right. You call it twice.

the number you read first (line 18) is never used, and is immediately replaced by the second number (line 23).
All you need is to remove line 18, and initialise number to some dummy value (not zero) so the while loop will start executing.

Why download Eclipse when you already have NetBeans? Whay do you think Eclipse can possibly do for you at this stage?
Eclipse won't give you anything more than Netbeans for ordinary Java development, but it will confuse you and waste your time learning how to use a second IDE.

You have so many problems already with the simplest Java code. In my opinion it's crazy to add an IDE's learning curve to your existing struggle. I would advise you to delete your IDE and use a simple editor and the JDK tools to learn how to code Java first.

It's a cliche, but software lasts long beyond its initial expected life. Management have some rose-tinted idea that they can replace it in 2,5,8 years or whatever, but once it's in place it's always cheaper to do a "small" fix or upgrade than a complete re-write.
So, IMHO, the people you are writing for when you write code are the poor minions who will be creating incremental update number 23471 in n years time.
Hence my first off-the-cuff response to this thread:

Someone else is going to have to read and understand it.
Whatever the requirements are now, they will change.

Someone else is going to have to read and understand it.
Whatever the requirements are now, they will change.

Method 1: (Object...params)
That's as unhelpful and error-prone method signature as I can imagine. You have no idea what the arguments should be, and the compiler can do nothing to help you.
Method 2: (Class<T> entityClass,String name, String idName,String value,String id)
Now at least I know what the arguments are supposed to be, and the compiler can check that the first is a class<T>, the second a String etc

For me it's 100% the second version. No contest.

Sorry, I don't know to make that any clearer. Just re-read the post and thuink about it...

Some comments:

That code is hard to read because:
The indentation is all over the place - use NetBeans to forma the code properly
You ignore Java naming conventions - class names should always start with a Capital letter, variables with a lower case letter

Declare the list as ArrayList<Book> saveBook= new ArrayList<>(); so Java knpws it only contains Books and thus you don't need to cast the elements when you get them

The file reading strategy is confused.
You only need to read the file into saveBook once, when the program starts. Then apply all your add/delete/updates to saveBook, and write the updated version to the file.

A list of Book objects is a very good start. You can add Books to it, or delete them, or update them by changing the values in their variables. For the changes you will probably need some kind of search method to get the right Book basd on its name or serial number etc.
If you wany to store that data between runs of your program then you will need some kind of external storage - eg an SQL database or a file.
You can store a whole list of objects in to a file and retrieve the whole list very easily, eith using the Serializable interface (for a binary file) or XMLEncode/XMLDecode (for a readable text XML file). You will find info on all that on the web.

printStackTrace() is really valuable when debugging, but is not something you would typically do in a live production system for the reasons discussed in that link.
When logging in a live system, and when a fatal Exception occurs I would log everything that could be relevant, including the stack at the time, obtained from getStackTrace()

You wouldn't need it for info, and probably not for well-designed debug logs, but if you need to trace an error then it's near essential. It doesn't cost much, and then only when you actually have an Exception.

Personally I always want the complete stack trace, not just the error message

In my opinion the Eclipse debugger has a very steep learning curve, and is far too difficult for someone who hasn't started learning about threads yet. For a beginner I think it's far better to stick to what they already know, and put in lots of System.out.println calls.

This is easilyy resolved... what are the names of all the classes in your app?

HArd to create a elevant example without a lit mroe info, but the essence of it is just

abstract class Workflow {
   // methods common to all workflows

   abstract public void update();
   // same for any other methods that vary by kind of workflow
}

class Parking extends Workflow {
   public void update() {
      // version of update code for Parking
   }
}

class Loan extends Workflow {
   public void update() {
      // version of update code for Loan
   }
}

now you can instantiate Parking or Loan objects (etc) and subsequently call update() for any such object, and the appropriate version will be executed.

If it is the case that:
Parking, Loan etc are all a kind-of Workflow
and
There is a lot that's common to all of those, but each has it's own variations
and
You don't need to add new Workflows without updating the program
then
Define an abstract Workflow class with Parking etc as subclasses

otherwize, you could define a data structure with "Parking", "Loan" etc as keys, and data that tells you what parameters to use in the update calls. Probably the easiest way to do that is simply to hold the appropriate calls as lambdas.

fis.close(); etc, of course

"if a connection fails to close because it was already closed, I would like to know."

Fair enough (although for most streams etc a second close will just be ignored). But the finally will be executed even after the try block has failed, so close etc may fail in the finally because they were never opened. So then you start to have tests in the finally to see what needs to be cleaned up, and catches if that doesn't work, and the whole thing balloons out of proportion.
Often all you want is to be sure that anything open will be closed when the method finishes, in which case I would go with the empty catch.

The real answer, of course, is to use try-with-resources

In that first piece of code you definitely need to close the streams.

"code like that is always bad."
Actually that is the one place where an empty catch is often OK - inside a finally block where yoy are just trying to tidy up anything left untidy.

Maybe you have an earlier version of the code that started executing but has not terminated for some reason? Check your task manager for running versions of java.exe or javaw.exe

If you are just using Files.move then there's no need to close anything. You only need to close input/output streams if you use those.

Maybe created a class with the same name as a JRE class that was imported with a .* ?

Oh. Yes. You're right. My mistake - I apologise.

Maybe it's slow because you are thrashing the file system with 1000 requests per second. Depending on your latency requirements you may find that it's a lot faster overall with a sleep of (eg) 100mSec

OK
Mark this one "solved" and start a new thread for a new question.
J

"I get a syntax error stating that it might not be initialized."

There's the answer. It tells you which variable you forgot to calculate.

Well, yes. Your calcs are a bit of a mess to be honest.
Start by tidying up your variables. For example - the user's input goes into hrswrk, but in the calculation you use numhrswrk (which is still zero).
Declare one variable for each item in the calculation, and just use those.
Then as you go through the calc, print every result as you calculate it, so you can see what you are calculating and how well tht's working.

That sleeps even if the file is available. Maybe better like

while (true) {
  try {
     get filestream
     break;
  } catch ... {
     sleep 1
  }
)

They look kinda importatnt to me. Maybe you should be using them rather than deleting them.

You calculate values on lines 28,29,30 but you don't use them in the following calculations.

You know the rules: try to do it yourslef. Post your best attempt and we'll help from there.

Maybe you could use a 1 byte file and open it for exclusive access for use as a system-wide lock?

   public static double getResult(){
        return getResult();
    }

As soon as you call this method you will get a stack overflow.
getResult calls getResult in an infinite recursive loop.
I guess it should be something like

   public static double getResult(){
        return <some calculation involving mass and acceleration?>;
    }

my time is cheap... you're welcome.

Please read my previous post.

Use your debugger (or lots of print statements) to trace the execution of both the server and the client so you can see what is happening.

JFrame's DISPOSE_ON_CLOSE, DO_NOTHING_ON_CLOSE, HIDE_ON_CLOSE are inherited from WindowConstants (JFrame implements WindowConstants)

EXIT_ON_CLOSE seems a historical oddity - it was first implemented in JFrame in Java 1.3, but then added to WindowConstants in Java 1.4 anyway.

So the answer to your question is: it makes no difference.

Please be aware of DaniWeb member rules, including "Do not solicit for help by email". DaniWeb is a resource that everyone can contribute to and everybody can use, so please post your question in the forum so others can help answer it and more people can learn from it.

It's impossible to know what help to give you without an understanding of where you are now in terms of Java knowledge and specific progress on this application.
But if you really don't even know where to start, then this assignment is sure to be beyond your current skill level.

If you have a B.Tech in computer science then you will know how to answer those questions.