Paul Clapham

Francesca duBois wrote:Like sending the parameters of the shape? (e.g. x and y values)

Yes, exactly, something like that. Some data which can be used to draw the shape on a Graphics object.

Gourav Das wrote:Its very strange...

It's exactly the same as

Object hi = "Hello world"; Object other = hi.substring(3);

A "busy" thread is one which is doing something. An "idle" thread is one which is doing nothing. Naturally all threads are either busy or idle, but not both.

The term "current thread" doesn't mean anything. The word "current" -- at least this version of the word -- means "at the present time". So I suppose the "current thread" might mean the one you're looking at now, or something like that. But you just made that up by picking words out of the quote you posted.

That clarifies things. So as others said earlier, you should not be sending Swing components over the network. However you can send images, as mentioned earlier. Or you could send an object of some kind which represents a shape and can be drawn on a JPanel (for example).

I'm sure you're right. My rough idea goes like this:

Apply .stream() to the Optional<String> and you'll get a Stream<String> with 0 or 1 entries. You can use filter() instead of your if-statement, that's what filter() is for, then you need some kind of map() to convert a String to an int if you have one, then you need to make the result into an Optional. Give it a try.

Then instead of

label1.setIcon(new ImageIcon("/Users/johnzalubski/Desktop/dropIn/Complete-Audi-Buying-Guide-gear-patrol-lead-full.jpg"));

you need something like

theIcon = new ImageIcon("/Users/johnzalubski/Desktop/dropIn/Complete-Audi-Buying-Guide-gear-patrol-lead-full.jpg"); label1.setIcon(theIcon);

where "theIcon" is an instance variable. If you later want that icon to appear on "label2", well, you know how to put an icon onto a label.

I'm not impressed by teachers who impose arbitrary restrictions which aren't really in line with good programming practice in order to teach some other thing. But look. In Java when you want to do two things one after the other, you put the code for those two things in the code one after the other, right? That's a rule in every language I've ever worked with.

So I suggested you want to create the menu items and then disable them. That means you put those two pieces of code to run consecutively. So far you have:

       MenuItem menu11 = new MenuItem("Login");        MenuItem menu12 = new MenuItem("Add Customer");        MenuItem menu13 = new MenuItem("Add Order");

which creates the menu items. (Yeah, I know there's more but I don't want to belabour the point.) Now after that you want to put the code which disables them. You've already got code which does that, I've seen it earlier in the thread. So in real life you'd just put it right there, right after you initialize the menu items. But some PHB tells you that you have to put the menu-item-disabling code in a separate method. Fine. Maybe the idea is you might need to re-disable the menu items at a later time, maybe in response to a logout button. So instead of putting the menu-item-disabling code right there after the menu-item-creating code, you put it elsewhere in a method. And then you call that method right after the menu-item-creating code.

Maybe there's something I'm missing in that description, but I still think you should start with that. Give it a try and let us know if you run into problems.

I don't see what I've missed. The fact that you have to use a different method is just a triviality, as far as I can see. Why don't you write some code that attempts to do that and show me why it isn't actually possible?

Steven Moore wrote:The only thing I don't know how to code is calling disableMenuItems(). Once I can do that, I can pass that to the employeeSignIn so it calls enableMenuItems(). I can't put it within the button setOnAction otherwise it will enable them when the button is pressed.

It seems to me that you want to create the menu items, then immediately disable them. That shouldn't be hard. Or am I missing something?

Kirk James wrote:Thanks for your help but I think you misunderstood the point. The behaviour I was facing was not inside the aspect but inside the method that is matching the aspect:

I'm sure I did misunderstand. I assumed that, since you posted the code with the variable which disappeared immediately, you must be using that code for something. Sorry about that.

I get my news from Google News, where Google gets/steals news from a variety of sources. It sends me articles about topics which it thinks I'm interested in, so I get articles about Java programming.

I was particularly interested in this article: Java tutorial for beginners: Write a simple app with no previous experience. It wasn't lying. It did present an app which was (apparently) written by someone with no previous experience.

Good to hear that!

As for "what happens under the hood", that isn't what you need to know. You need to know how variables work in Java. Here's a link to a pretty decent tutorial which tells you about that: Variable Scope in Java.

If I understand it correctly:

       try {            Object result = joinPoint.proceed();            log.info(END_LOG + " method: {} | result: {}", methodName, result);        } catch (Exception e){            log.error(ERROR_LOG + " AOP aroundFindRepository: ", e);        }

You say that this fragment produces a non-null value and assigns it to the result variable. Am I right?

And then you say that some other code tries to use some other value, and it's null. Right?

Well, the result variable is local to that try-block and it's not visible anywhere else in any other code. And when the try-block terminates, that variable disappears entirely. So that other code with the NPE can't be using that result variable. It must be using something else, and then maybe it's not that surprising that it's null.

Château Na Fleur wrote:I have one more question.  When you add a row to a JTable and then call fireDataTableChanged(), is the entire table repopulated or is it just the new row that is added?  That is, are the methods to add a row to the table called again for each row or just for the row being added?

For the first of your questions: Neither.

 And for the second question: The fireDataTableChanged() method doesn't modify the JTable in any way. It just notifies the objects that were listening to the table model (Note: You don't add rows to a JTable, you add the rows to a table model. The JTable will be one of those listeners and will react by redrawing itself.)

And my question: Why aren't you calling fireTableRowsInserted(row, row) when you insert a row into a table model?

That's an interesting-looking bunch of instructors you had!