Posts by Ezzaral

The library is free and does have one or two demo sources in it. The developer sells a downloadable developer's guide which includes all of those demos to help support development of the open source library. It is those demos that you cannot post here.

Is that code in a file called "PublicGarage.java"? This is just a class path issue or a file naming issue.

No one here is going to answer your test for you.

jwenting is correct. That code is only available with a purchased a copy of the Developers Guide and I am sure the author does not want it posted for free.

Flagging it a bad post so a mod can delete that code.

So read the tutorials that were posted and try it. The burden is upon you to make an honest try before asking again.

kooljoycie,
javaAddict is correct, you are the student and regardless of your perception of the shortcomings of your university it is still upon you to make the effort to learn. That does not mean asking someone to explain every step of how to do your homework.
Also, you need to read the Announcement at the top of this forum regarding homework help:http://www.daniweb.com/forums/announcement9-2.html and the forum rules about keeping such help on the forums: http://www.daniweb.com/forums/faq.php?faq=daniweb_policies (read the whole thing, because it also mentions not starting threads with titles like "I need help!!!!")

Post your code and your questions if you have them, otherwise you have some studying to do first.

You're better off with the Sun concurrency tutorial http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html. The one posted above is from 1996 and will not cover any of the recent java.util.concurrent features.

For a more thorough treatment on concurrency, pick up a copy of Brian Goetz's Java Concurrency In Practice

I would just recommend working on getting the responsibilities for each of those classes that extend JPanel encapsulated. Think of them as separate entities with distinct duties to maintain certain pieces of your functionality. Your top-level class should just call methods on those to give them the info they need to update whatever state they are maintaining. Your classes should not have to update internal variables in one another. Ideally they shouldn't even know anything about the internal variables of the other. Create methods that provide the interaction mechanisms between them so the class itself is controlling it's own internal state. Don't let other classes muck about with the guts of a classes variables.

Well, this statement

update.updateScore();

is not updating the panel that is in your frame. It's being called against the local "update" variable that you created. You need to change the constructor to initialize a class level "player" instance variable instead of the local one that it is creating now (see my previous post) and call the updateScore() on that instance variable. Currently you don't have a reference to that instance to work from. (Whereas you do with the "correction" call that is currently working for you in that handler)

If you want to keep the panels as separate classes, I would recommend moving the JLabels that go in those panel into those classes and not have them in your top-level JFrame class. Let those panels handle their own components. There is no reason that updateScore should have to set text on a label that is defined at the JFrame level. Having them each extend JPanel is fine, but keep their functionality encapsulated as well, otherwise you are not gaining anything by separating them. Also note that you don't have to put those objects into other JPanels just to add them to the frame - they are JPanels themselves - just add them.

Well, you don't say what labels you are having trouble updating, but some things really stand out as a problem. In your constructor

JPanel playerpan = new JPanel();

You're defining this as a local variable - not initializing your class level "playerpan" variable. Same with the other panels. This means that you essentially have no reference to those panels outside the constructor. Aside from that, why does player extend JPanel but refer to components in the enclosing class? The only variables in "player" are two strings. This is a rather odd tangle of component classes.

As for the label update, this is most likely due to this line in your button handler

player update = new player();

You are creating a new separate "player" instance and calling the update method on it - not the one that you actually added to your JFrame.

If you are updating an existing record, you should be using

update emp set total=<total> where id=<empId>

You can either concatenate in the values of <total> and <empId> or use a PreparedStatement to set those variables. This means you need to capture whatever you are using for an id on that record in addition to the two values you want to add. Also, there is no updateQuery() in the java.sql.Statement interface. You need to call Statement.executeUpdate(java.lang.String)

You want to add that action listener to jMenuItem1 instead of jMenu1. Also, you aren't showing the dialog. I would recommend using the static JOptionPane method to show the dialog

JOptionPane.showMessageDialog(NewJFrame.this, "You pressed New.");

.

What is it doing that confuses you? You need to be more specific in your question. You should also pay more attention to proper indentation, because it will make programming much easier if you can identify code blocks easily.

It can't "skip the try". An exception is occurring and you need to figure out what it is. I would recommend putting e.printStackTrace() in your catch block.

Yep. The image loading is just a little different. All of the other painting in the same, just done on JFrame or JPanel (or JLabel even).

The 2D graphics tutorial should be enough to get you started: http://java.sun.com/docs/books/tutorial/2d/index.html
Once you see how to paint a simple line or geometric primitive on a frame, you should have no trouble drawing a basic graph of a function.

To load the images you can either use ImageIO.read(java.io.File) or Image image = Toolkit.getDefaultToolkit().getImage("image.gif"); All the other methods, such as getHeight() and getWidth(), should be available from whatever component you are displaying the image on, such as a JPanel.

Well, you can do it with reflection like this

private static int getSomeNumber(Class<? extends Object> c)
{
    if (c == Mystery.class)
    {
        try {
            Class<Mystery> thing = (Class<Mystery>)c;
            Method m = thing.getDeclaredMethod("getNumber", (Class[])null);
            return (Integer)m.invoke(null, (Object[])null); 
        } catch(Exception ex) {
            ex.printStackTrace();
        }
    }
    return 0;
}

But whether you should is another thing altogether. What is the fear of using objects there? Reflection isn't exactly the fastest thing in the world either, so if you're worried about creation time of objects then you may find using reflection no better. Are the objects very expensive to create? If so, can you use lazy initialization to defer some of that expense and keep the contructor light?

I'd say there are more design issues raised by this than answered.

Are you certain of the SMTP address and are you certain that Yahoo will accept STMP connections for this account? It appears that is limited to paid Yahoo! Mail Plus accounts - not the free ones.

Invalid SMTP address? Wrong port? Invalid user name? Invalid password? Check those things.

Beyond that you will probably have to post some code, since it's hard to see over your shoulder from here.

You might want to pick up a copy of Head First Java instead. Any of the "<something> in X Days" books are usually fairly useless.

See the Read Me thread at the top of the forum for more resources on getting started with Java.

Then listen when he tells you that you CANNOT DO what you have been trying to do. You have been told this in many posts before in the many threads you have created on this same topic.

Get it through your head - You can't do this, so quit asking

It would be more useful to see the code with the try-catch block(s) included to know what you have tried.

I would recommend a try-catch on the parsing of each arg and in the catch, print the usage and the argument that caused the exception.

Well, yes, static methods can be called directly on the class by ClassName.methodName(). Is that all you needed to know or is there something more specific to your question?

StringTokenizer is considered a legacy class now and it is recommended to use String.split(java.lang.String) or the java.util.regex classes for this now.

With split() you could first split on the math operator, giving you the two operand strings, and then spilt those into the whole and fractional strings, and then split the fractional into it's numerator and denominator. The one issue you may face doing that is your fraction separator "/" is the same as the division operator "/". If you can be certain that the operator will have blank spaces on both sides, it becomes much easier.

Give that a try and see how it goes. Even if you must use StringTokenizer due to some professor insisting you use legacy classes (does he know it's a legacy class?), still it may help if you consider that you don't have to parse the string in one shot from left to right. You can parse it into separate pieces and then parse those pieces into other pieces and so on, which can make the problem much cleaner to approach.

I guess the logic is fine, since the code runs for cases with less branches. It's just that once branch number exceeds 30 it gives me out of memory error.

If you are hitting out of memory exceptions at 150 nodes, I would say the logic is not fine and you are recursing the collection much more than necessary. As mentioned above, since your limiting variables (i,m,b) are external to the method, it's difficult to say what's breaking down, but none of your traversals are limited to parameters of the current node and since you say every node has a reference to every other node, you are probably checking the same nodes over and over again.

You are correct in that security is the reason, but some tend to think security just means hackers breaking into your computer. The security referred to here is the integrity of the workings of the code. Access modifier allow class designers to restrict what any other classes can modify and the means by which it can be modified. Regardless of any notions of malicious intent, it ensures that the code works as intended and guards against outside code interfering with those workings.

Same reply as the original on this 3+ year old post:
Post your work and the problems that you are having with it. This isn't "Give Teh Codez" central. You have to show some effort.

Perhaps you missed this Announcement at the top of forum: http://www.daniweb.com/forums/announcement9-2.html

If you need help with it, you'll need to work up a first try at it or at least ask specific questions about what portion you do not understand.

Ok, I didn't realize that was part of the base constructor as well. So now your base constructor takes minStrength, maxStrength, and strength? I'm assuming it still needs the strength value as before, otherwise it's not really initializing the data. That would seem to leave you in a worse position than before, design-wise. Now you need to pass 3 parameters for every attribute that you wish to have on the object. If your LivingThing has 8 attributes, then you will be passing 24 arguments to your constructor, which is just painful and unnecessary.

Personally, I would still recommend going with protected methods to set that state in the base class and pulling those values out of the base constructor, but that's just me.

String result = "Is not included.";
for(int i = 0; i < 7; i ++) 
 {
  if(team.group.toys[i].getName().equalsIgnoreCase(name )
      {
        team.insert(team.group.toys[i].getDescrip());
        result = "OK";
        break;  // no reason to keep looking here
       }
}
System.out.println(result);

Just to clarify the question, the printing of "Ok" part works fine if the match is found, but you don't want it to also print "not included"?

Yes, an off-screen buffer image can be used for such things. If you are actually recreating the image each display cycle it won't really help much, but if the image is only changed occasionally, or you only need to redraw parts of it, it can help quite a bit.

They can be very helpful when you have a constant "background" image (like a game board perhaps) that you draw other things on top of a lot, as the background image only needs to be created from scratch once.

As a general guideline, try to keep the code in paintComponent() as minimal as possible, since repaints occur frequently due to other events besides your own repaint() calls. If your drawing routines are math intensive, try to perform those as infrequently as possible in a separate method and let the painting code just use the results of those calculations.

It does work, but what happens when you need to set other values that are specific to the subclasses? Then you have to add more parameters to the constructor and alter all the calls to it.

A more flexible way to go about it is to make the maxStrength variable "protected" in the base class, which will allow subclasses to access it, or to create a protected method setMaxStrength() that can be used by child classes.

If you need to make the calculations yourself at the pixel level, you first calculate the luminence from the RGB values y = .30*R + .59*G + .11*B and then set the R,G,and B values to that calculated value.
http://en.wikipedia.org/wiki/Grayscale#Converting_color_to_grayscale

Drawing the image to a new BufferedImage of TYPE_BYTE_GRAY, as mentioned in the previous post, is probably the easiest though.

As far as Java, check the "Read Me" thread at the top of this forum. For JavaScript, I couldn't say, because they are not the same thing and not used in the same context. You may want to check in the JavaScript forum for that.

You still have an error with the block structure then, because there is nothing wrong with that line.

The BufferedImage is just an image in memory - it doesn't have a location. It's the paintComponent() calls that render that image to the graphics context. So yes, if you have a reference to the graphics context you can draw that BufferedImage to it.

No, not really, because you only posted a fragment of code that cannot be run and your indexes are going to vary at runtime. It's very simple for you to find the problem on your own though. Check your array sizes before you access them. Obviously one of those arrays only has a single element and you are trying to access a second.

Most likely you are missing a brace or semi-colon somewhere above that line. Check all of your code blocks for proper brace structure and make sure all of your statements have appropriate semi-colons.

Also, check your spelling errors in the remove() and update() methods and if you re-post any code, make sure you place tags around it. Unformatted code is a painful mess to read.[code ] tags around it. Unformatted code is a painful mess to read.

The Runtime.exec() call will return a Process reference, from which you can get the standard input, output, and error streams.

Also, I am not really that familiar with the "abstract" qualifier and whether that would affect anything. I notice you made AbsFireworksPanel abstract.

In C++ it would be an abstract base class that declares pure virtual functions. Declaring the class abstract ensures that it cannot be instantiated itself and only serves as a base class for concrete subclasses. A better explanation can be found here: http://www.codeguru.com/java/tij/tij0079.shtml

I don't really see where you are gaining anything by having AbsFireworksPanel be an abstract base implementation and FireworksPanel extending it - except perhaps headaches and confusion at this point. Why not combine those until you get it working as you would like and then, if there really is a reason to abstract some shared functionality out, refactor that as appropriate? If the only concrete implementation of AbsFireworksPanel that you have is FireworksPanel, you're just making one class be two for the sake of it.

I thought you were much too young to drink alcohol.

Legal age is 18 in the UK.

Well, use "\\\\" then.

String newString = oldString.replace("\\","\n");

Bourbon & coke
Tequila & 7up
Beer (mostly ales)

Some (most) design patterns in Java are done for getting around the inherent limitations of the language. Java tends to make a big deal out of little things. Many other languages don't need them (or don't consider them anything worthy of being called a fruity name). But some basic universal patterns (like the interpreted utility language pattern ^_^) are seen elsewhere.

Oh, and that is the reason the canonical GoF Design Patterns book used C++ and SmallTalk for their examples? To present patterns to work around limitations in Java? Sure, that makes sense.

The book was published in 1994. Java was released in 1995.

possibly

for(int r = row; row<8; r++) {
    for(int c = column; c>-1; c--) {
        System.out.println("c "+c);
        if(board[r][c]!=null||board[r][c].getTeam()!=board[row][column].getTeam()) {
        //locations.add(new Location(r, c));
        //count++;
        }

        if(board[r][c].getTeam()==board[row][column].getTeam()||board[r][c].getTeam()!=board[row][column].getTeam()) {
            c = -1;
            row = 8;
        }
    }
}

or perhaps "row" is 1- prior to entering the outer loop?

I'm sure he would be happy to hear from you if you wish to write him at that email address :)