[java] обработка сообщений
ход компа может занимать много времени, так что, по моему, лучше сразу реализовывать его в отдельном потоке, чем писать костыль, коль всё равно приходится узнавать на форуме, как писать костыль.
А что у тебя за среда? ОСь, ГУИ там, етц?
Рожать треды не вариант?
Рожать треды не вариант?
В Яве "событий" как таковых нет. Если что-то где-то происходит, то объект, вызвавший "событие" пробегается по своим слушателям, и вызывает по интерфейсу ActionListener метод actionPerformed. Из объектов не являющихся слушателями узнать о событии невозможно (насколько я знаю). Так что для того чтобы обработать "событие", тебе надо зарегистрировать слушателя (addActionListener) и т.д.
Попробуй
Только знай, что тот, кому придется это читать тебя точно захочет убить.
EventDispatchThread)Thread.currentThread.pumpEvents(new Conditional {
public boolean evaluate {
return globalVar;//вернуть false, когда нужно прервать цикл.
}
});Только знай, что тот, кому придется это читать тебя точно захочет убить.
Разрабатываю шахматную программу.Всегда удивляло, зачем делать криво? Возьми GNU Chess, и там есть АПИ, разрабатывай сколько влезет логику игры.
Есть функция, ожидающая от пользователя ход (фигура и целевая клетка она должна вернуть значение только после того, как пользователь этот ход обозначит. Для этого она садится в цикл, ожидающий пока обработчик события от кнопки поменяет некую глобальную переменную. Понятно, что все криво, но переделывать пока времени нет, занимаюсь логикой игры.
Нет, блин, делают своё убожество.
Тебе нужны континуации. В Java их нет.
эта твоя функция в каком потоке работает?
у тебя ваще Swing или что?
если свинг и функция эта в свинговском потоке вызывается то как уже сказали континуэйшенов нет
если не отдельно потоке, то поток этот можно просто усыпить типа навсегда, и тогда когда пользователь сделает ход то обработчик хода пошлет notify и разбудит этот поток, т.е. все время переменную проверять не надо будет
у тебя ваще Swing или что?
если свинг и функция эта в свинговском потоке вызывается то как уже сказали континуэйшенов нет
если не отдельно потоке, то поток этот можно просто усыпить типа навсегда, и тогда когда пользователь сделает ход то обработчик хода пошлет notify и разбудит этот поток, т.е. все время переменную проверять не надо будет
ээ, ну например можно так (вообще, тут одна игровая библиотека используется, ну, впрочем, у тебя шахматы 
)
Пишешь класс:
И еще один класс:
В главном классе своей программы, в конструкторе, например, пишешь что-нибудь типа:
Ну и потом, в цикле той своей функции, а лучше в каком-нибудь главном цикле программы или и правда в отдельном потоке вызываешь метод
который и будет проверять все прослушиваемые клавиши. Как-то так. Аналогично на прослушку можно и мышку посадить, если надо.
Для работы такой схемы нужно подключить библиотеку jinput.jar (В ней класс Keyboard взять можно на сайте http://lwjgl.org вместе со всем остальным. В общем, вот такие костыли, как вариант
)Пишешь класс:
import java.util.LinkedList;
import java.util.ListIterator;
public class EventManager
{
private static EventManager instance;
public static EventManager instance
{
if (instance == null)
instance = new EventManager;
return instance;
}
private LinkedList<KeyListener> listeners = new LinkedList<KeyListener>
public void addListener(int key, KeyListener listener)
{
listener.setMonitored(key);
listeners.add(listener);
}
public void checkEvents
{
for(ListIterator<KeyListener> li = listeners.listIterator; li.hasNext;)
{
li.next.check;
}
}
}
И еще один класс:
import org.lwjgl.input.Keyboard;
public class KeyListener
{
protected int monitored;
protected boolean wasPressed;
public void setMonitored(int key)
{
monitored = key;
}
public void check
{
if(Keyboard.isKeyDown(monitored
{
wasPressed = true;
onKeyDown;
}
else if (wasPressed)
{
onKeyUp;
wasPressed = false;
}
}
public void onKeyDown{};
public void keyPressed{};
public void onKeyUp{};
}
В главном классе своей программы, в конструкторе, например, пишешь что-нибудь типа:
EventManager.instance.addListener(Keyboard.KEY_SPACE, new KeyListener
{
public void onKeyDown
{
//здесь твой код, меняешь свою глобальную переменную
}
});
Ну и потом, в цикле той своей функции, а лучше в каком-нибудь главном цикле программы или и правда в отдельном потоке вызываешь метод
EventManager.instance.checkEvents;
который и будет проверять все прослушиваемые клавиши. Как-то так. Аналогично на прослушку можно и мышку посадить, если надо.
Для работы такой схемы нужно подключить библиотеку jinput.jar (В ней класс Keyboard взять можно на сайте http://lwjgl.org вместе со всем остальным. В общем, вот такие костыли, как вариант
ты используешь дженерики но не используешь foreach
почему?
почему?
ты используешь дженерики но не используешь foreachээ, ты имеешь в виду, почему я пишу
почему?
for(ListIterator<KeyListener> li = listeners.listIterator; li.hasNext;)
?
да просто, привык так. И вроде бы я где-то читал, что это конструкция работает быстрее, чем foreach. хз, впрочем, не проверял)
да просто, привык так. И вроде бы я где-то читал, что это конструкция работает быстрее, чем foreach. хз, впрочем, не проверял)дурачкая привычка имхо
ну просто дженерики многие ругают это понять можно, но не использовть foreach это как-то странно
по поводу быстрее
на бред конечно похоже, чуваки в сане не настоко же тупые
но даже если и протупили с какимнить очередным jvm апдейтом это починяется, т.е. полюбому на такое низзя закладываться
нет конечно
токо причем тут это?
токо причем тут это?
ну просто дженерики многие ругают это понять можноо, а за что ругают дженерики?
все-таки то что в foreach элементы не удаляются, не очень-то удобно, по моему
и ещё instance а не getInstance
эээ
это уже придирки к стилю
он и скобки на другой строке открывающиеся ставит
к стилю придираться бессмысленно, каждый пишет или как ему показалось правильным или как его заставили придурки по команде
это уже придирки к стилю
он и скобки на другой строке открывающиеся ставит
к стилю придираться бессмысленно, каждый пишет или как ему показалось правильным или как его заставили придурки по команде
это не придирка, это выглядит так же странно в контексте, как неиспользование foreach, как некий артефакт
другие-то функции оформлены с is и т. п.
расстановка скобок же единообразна
другие-то функции оформлены с is и т. п.
расстановка скобок же единообразна
это не придирка, это выглядит так же странно в контексте, как неиспользование foreach, как некий артефактнет ты не прав
другие-то функции оформлены с is и т. п.
оформлены геттеры/сеттеры
instance - это синглтон, он не обязан быть оформлен как геттер
я и правда у многих в коде такое встречал
о, а за что ругают дженерики?
За приведение к базовому типу. Так называемое "стирание"
Оставить комментарий
shtreg
Разрабатываю шахматную программу.Есть функция, ожидающая от пользователя ход (фигура и целевая клетка она должна вернуть значение только после того, как пользователь этот ход обозначит. Для этого она садится в цикл, ожидающий пока обработчик события от кнопки поменяет некую глобальную переменную. Понятно, что все криво, но переделывать пока времени нет, занимаюсь логикой игры.
Но в этом цикле надо как-то попросить "джаву" эти события обрабатывать. В дельфи было Application.ProcessMessages, нужен максимально близкий аналог этого метода. Нужно именно это, предложения все переделать по человечески не нужны, сам понимаю, это потом.