Új hozzászólás Aktív témák

• #10109 Drizzt nagyúr Dinter #10108

  Új Válasz 2018-11-20 22:05:18 #10109

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drizzt

  nagyúr

  válasz Dinter #10108 üzenetére

  Valahol van erre minta kódod?

  "Ha én az EventHandler-t az App-on belül valósítom meg, akkor minden gombnak az App osztály adattagjának kell lennie, hogy a handle függvényben le tudjam ellenőrizni, hogy melyik osztályban történt a kattintás."

  Ez szerintem nem így van. Vagyis nem teljesen értem, hogy mit értesz az alatt, hogy le kell tudd ellenőrizni, hogy melyik osztályban történt a kattintás? Miért kellene ezt leellenőrizni? Ha bárhol csinálsz EventHandler-t implementáló osztályt, azt be tudod állítani event handlernek. Akár csinálhatsz egy olyan függvényt az Appban, ami EventHandler<MouseEvent>-et ad vissza, pl. így:

  Class MyApplication {
EventHandler<MouseEvent> createTeamHandler(Team t) {
return new EventHandler<MouseEvent>() {
@Override
public void handle(MouseEvent e) {
System.out.println("MouseEventhandler runs");
t.doSomething();
}
};
}
}

  És akkor ahol akarod használni:

  MyApplication app = new MyApplication();
Team t = new Team();
button.addEventHandler(app.createTeamHandler(t));

  Mondjuk Javafx-hez sem értek. De ehhez hasonló dolog simán megy pl.: Consumer-ekkel:

  public class Book{

public Book(String name) {
this.name = name;
}

private String name;
private Consumer<Book> consumer;

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public void setConsumer(Consumer<Book> bookConsumer) {
consumer = bookConsumer;
}

public void consume() {
consumer.accept(this);
}
}

public class Tester {

public static Consumer<Book> getBookConsumer(int number) {
return new Consumer<Book>() {
@Override
public void accept(Book book) {
System.out.println(number);
}
};
}

public static void test() {
Book b1 = new Book("AGILE workflow");
b1.setConsumer((book -> {
System.out.println(visitables.size());
}));
b1.consume();
b1.setConsumer(getBookConsumer(8));
b1.consume();
}
}

• #10019 skoda12 aktív tag Dinter #10018

  Új Válasz 2018-10-24 22:29:33 #10019

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  skoda12

  aktív tag

  LOGOUT blog

  válasz Dinter #10018 üzenetére

  Itt több esetet kell majd szétválogatni szerintem. Induljunk egy runnable állapotból, ekkor a lépések:

  1. A foobar.wait() hívása előtt meg kell szerezni a monitor lockját. Ez vagy sikerül elsőre vagy blocked állapotba kerül a thread, ha valaki másnál van lock.
  2. Valahogy túljutunk az előző ponton, runnable állapotban van a thread és meghívódik a foobar.wait(). Az új állapot waiting.
  3. Valamiért (*) felébred a thread, runnable állapotba kerül. Ahhoz, hogy ki tudjon lépni a wait()-ből kell a monitor lock. Itt megint vagy sikerül elsőre vagy blocked állapot jön és ha megvan a lock akkor runnable megint.

  (*) A notify() hatására átmehet blocked állapotba a thread. A foobar.notify() híváshoz is kell a monitor lock. Ha a felébresztett thread már futna, de a notify()-t hívó thread még fogja a lockot, akkor a felébresztett thread megy a blocked állapotba. Ha viszont véletlen úgy kapna cpu időt, hogy a notfiy()-t hívó thread (és mindenki más) már eleresztette a lockot, akkor ki is maradhat ez a blocked állapot.
  Viszont nem csak a notify() miatt mehet át ilyen állapotokon a thread. Például spurious wakeup miatt a wait()-et hívó thread még a notify() hívás előtt is felébredhet "magától". És akkor itt megint jön az, hogy vagy runnable vagy runnable + blocked + runnable állapotokon megy át.

Új hozzászólás Aktív témák