Threads and listener

[mogwai31]

Hi

I am devloping a board game in java. In order to allow a user to move, i want to detect mouse clicks on the board(graphics2D stuff). I have a method called move that gets the squares a user can move to (Rectangle2D.Float). I add a mouse listener to the board. I then loop and ask the mouse listener for the Point of the last event to check whther one of the allowed rectangles contains it. Unfortunately, it never goes in the mouse listener, it just sits in the loop. I know how to write mouse listeners and I have tested it without the loop.
Is a mouse listener created in a new thread? It seems like the mouse listener’s events are never called, and he code in stuck in the main thread.

Plaese help im so confused.

MY

[Kova]

mouse listener created in new thread? huh? No.
To see if mouse event gets call simply just print something out (good thing would be x and y pos of event) in console when you enter mouseClicked / mousePressed.
I don’t get the loop you’re in, is it a game loop? If you’re getting x any y of mouse every time you pass through game loop than I can’t help you, you didn’t wrote anything about it. All I can say why not use mouseClicked or mousePressed?

[modelsmith]

Hmm, If you’re running the loop from the base invoking thread, then no other threads are likely to get to work.
The main thread usually has priority over the rest.

A better way to run a loop is to create it in a new runnable thread and then periodically ‘sleep’ every loop iteration.

`
[b]class MouseInputHandler extends Thread
{
public void run()
{
for (int i=0; i<1000; ++i)
{
// < your code here > Check the x and y coords etc.

System.out.println(""+System.currentTimeMillis()+"> Tick.");

try
{
Thread.sleep(500); // Sleep for 500 milliseconds to allow other threads to run
}
catch (InterruptedException e)
{}
}
}
} // end class MouseInputHandler

public class ThreadTest
{
public static void main(String[] args)
{
// Create and add the mouse listener stuff etc.

Thread l_myThread = new MouseInputHandler();

// Start the looping thread
l_myThread.start();
}
} // end class ThreadTest[/b]
`

Also, events, like AWT events (mouse, keyboard, etc.) are only invoked in the base thread, which your initial code occupies.
If your code works without the loop, then I would definitely suggest moving your loop into a separate thread.

I hope this helps.

[CaptainJester]

@modelsmith

Hmm, If you’re running the loop from the base invoking thread, then no other threads are likely to get to work.
The main thread usually has priority over the rest.

Incorrect. The event dispatch thread has more priority than the main thread. Just look at all the Java 4K games. They are almost all written with a loop in the main thread.

@mogwai31:
You will have to post source to get more help.

[Anon666]

Also, events, like AWT events (mouse, keyboard, etc.) are only invoked in the base thread, which your initial code occupies.
If your code works without the loop, then I would definitely suggest moving your loop into a separate thread.

Also incorrect.

The Thread that initially invokes an applications main(…) method is in no-way related to the event dispatch Thread.

(infact the event dispatch Thread doesn’t even exist until the AWT subsystem is initialized - which can occur at various points; but usually upon constructor of a Window descendent.)

[modelsmith]

Sorry about that. I stand informed and corrected.

However, I think that if one has an infinite loop anywhere (even if one is doing something useful in there), that all other threads, including the EventQueue, will have difficulty getting a chance to work.

In any case, would my code above fix the problem?

[Riven]

Also incorrect

As long as all threads ahve the same priority, they have equal chance to get cpu-time.

[modelsmith]

Aw darn’it.

I have much still to learn.

[modelsmith]

Hmm. Searching the other posts, I found this.

Essentially, I think it means that if you start from a listener event call and have an infinite loop where you don’t return, only then do you tie up the EventQueue and no more events can be called until the method with the loop returns.

@kevglass

Does the GameWindow constructor start the game loop? If so you might be blocking the AWT event thread. Try constructing your GameWindow in a different thread.

Thread t = new Thread() {
    public void run() {
         new GameWindow(); // or whatever starts your game loop
    }
};
t.start();

Kev

This would explain why I thought that a loop would tie up the events, just for the wrong reasons.

Sorry if this isn’t right either. (me a n00b)

[Mr_Light]

@Riven

Also incorrect

As long as all threads ahve the same priority, they have equal chance to get cpu-time.

no guarenties though, depence on the underlaying system. unless a thread yields… well, these days all systems today seem to have that behavoir though