[java] wacht op ander event tijdens event handling.

[Swinnio]

Ben bezig met een class in java die 2 event listeners implementeert, waarvan ik er eentje zelf heb gemaakt. Tijdens het afhandelen van een van die zelfgemaakte events ("IncomingEvent") is interactie met de gebruiker d.m.v. een dialog noodzakelijk. De uitkomst van deze dialog krijg ik alleen mee doordat een event van het tweede type ("actionPerformed") wordt gegenereerd. Die gebeurt echter op een andere plek, aangezien het afhandelen van het tweede event vast ligt.
Het probleem is nu: hoe kan ik bij het afhandelen van event1 rekening houden met wat event2 oplevert? Met andere woorden: tijdens het afhandelen van event1 kan ik pas verder wanneer event2 optreedt. Nu kan ik natuurlijk voor de niet-nette oplossing gaan door event2 een of andere object of variabele te laten bewerken en tijdens het afhandelen van event1 continu te checken of dit al gebeurd is, maar het lijkt me dat er nettere oplossingen moeten zijn.
Nogmaals het probleem in (pseude)code:

Java:

// Event 1 treedt op.
public void incomingEvent(Event e1) {
// Show dialog
// Doe iets, afhankelijk van Event 2
}

// Handles events from dialog
public void actionPerformed(Event e2) {

}

[ Voor 13% gewijzigd door Swinnio op 03-06-2005 16:34 ]

[JaWi]

Je kunt de user-interactie (dus de showDialog() en de actionPerformed()) beter in een eigen klasje stoppen (bijv. afleiden van JDialog oid) en deze instantieren in incomingEvent(). Zo heb je volledige controle over je programma flow...

[Janoz]

Ik weet niet exact hoe je programma opgebouwd is verder, maar je zou de afronding die je nu in event1 doet ook gewoon af kunnen maken bij event2 ipv het proberen af te maken bij event 1. Zet in event 1 gewoon de spullen klaar (middels private variabelen) die je bij event 2 nodig hebt, en handel de rest in event2 af.

[Swinnio]

JaWi schreef op vrijdag 03 juni 2005 @ 16:40:
Je kunt de user-interactie (dus de showDialog() en de actionPerformed()) beter in een eigen klasje stoppen (bijv. afleiden van JDialog oid) en deze instantieren in incomingEvent(). Zo heb je volledige controle over je programma flow...

Dat zou het probleem waarschijnlijk oplossen, ja. Hoewel het misschien niet zo netjes is om een klasse te maken die in feite alleen de functionaliteit van een methode (show dialog en wacht op antwoord) heeft?

[ Voor 1% gewijzigd door Swinnio op 03-06-2005 16:45 . Reden: tiepvoud ]

[Swinnio]

Janoz schreef op vrijdag 03 juni 2005 @ 16:45:
Ik weet niet exact hoe je programma opgebouwd is verder, maar je zou de afronding die je nu in event1 doet ook gewoon af kunnen maken bij event2 ipv het proberen af te maken bij event 1. Zet in event 1 gewoon de spullen klaar (middels private variabelen) die je bij event 2 nodig hebt, en handel de rest in event2 af.

Het probleem daarbij is, dat event2 ook onder andere omstandigheden kan optreden. Het is een algemene dialog, die ook zonder het optreden van event1 afgehandeld moet kunnen worden. Dat betekent dus dat ie onafhankelijk van event1 moet zijn en daarmee gaat jouw voorstel helaas niet werken, ben ik bang...

[ Voor 38% gewijzigd door Swinnio op 03-06-2005 16:50 ]

[JaWi]

Swinnio schreef op vrijdag 03 juni 2005 @ 16:45:
Dat zou het probleem waarschijnlijk oplossen, ja. Hoewel het misschien niet zo netjes is om een klasse te maken die in feite alleen de functionaliteit van een methode (show dialog en wacht op antwoord) heeft?

Je zou hem natuurlijk ook inline in je huidige klasse kunnen definieren, maar of dat nou zo netjes is... Desalniettemin, waarom zou je dit niet zo mogen oplossen? Het is gewoon een klein utility-klasje wat je in je GUI gebruikt.

[Alarmnummer]

Je moet je probleem even iets helderder uitleggen. Ik heb een en ander aan ervaring met events en swing, dus waarschijnlijk kan ik je probleem wel fixen. Maar je zult iets meer info moeten verstrekken.

[Robtimus]

Volgens mij moet je met verschillende threads gaan werken. Dit omdat de eventdispatcher thread (nodig voor event2) niet mag blokkeren in event1.
event1: start de thread, en in die thread heb je iets dergelijks:

Java:

synchronized (objectToSynchronizeOn)
{
    // do first stuff
    objectToSynchronizeOn.wait(); // block until notify is called
    // do other stuff
}

In event2:

Java:

synchronized (objectToSynchronizeOn)
{
    // do first stuff
    objectToSynchronizeOn.notify(); // or notifyAll();
    // do other stuff
}

Sommige code hoeft niet per se in deze synchronized blocks te staan, maar die wait en notify wel degelijk.

[JaWi]

@IceManX: poeh, om nou een multi-threading oplossing te kiezen voor zo'n relatief eenvoudig probleem is denk ik wel wat veel van het goede (laat staan eenvoudig). Als het even kan wil je dat zoveel mogelijk vermijden...

[Nick_S]

Je kan toch op het moment, dat je wil gaan wachten ipv. wachten een extra listener toevoegen voor Event2. Die inline listener, die al eerder genoemt is.

Dus zoiets:

Java:

public class GotExample implements CustomListener {

    public void handleCustomEvent(CustomEvent e) {
        // Do some stuff
        final Dialog dialog = new Dialog();
        dialog.addActionListener(new ActionListener() {
            // aanname CustomListener is een Interface en geen klasse
            public void actionPerformed(ActionEvent e) {
                //Do some more stuff
                
                
                target.removeActionListener(this);
            }
        };
        dialog.show(); // Deze wordt dus ook nog uitgevoerd, voordat bovenstaand ActionPerformed wordt uitgevoerd;
        
    }
}

Hoop dat je hier iets mee kan! Zo niet, vragen is vrij!

(Antwoorden kosten geld! )

[ Voor 1% gewijzigd door Nick_S op 03-06-2005 22:52 . Reden: Kleurtjes toegevoegd.... ]

[Robtimus]

JaWi schreef op vrijdag 03 juni 2005 @ 20:14:
@IceManX: poeh, om nou een multi-threading oplossing te kiezen voor zo'n relatief eenvoudig probleem is denk ik wel wat veel van het goede (laat staan eenvoudig). Als het even kan wil je dat zoveel mogelijk vermijden...

Ik heb het eerste probleem beter doorgelezen, en het kan inderdaad een stuk eenvoudiger. Ik had over dat deel over de dialog gelezen.
Het verhaal met meerdere threads zal hooguit nodig zijn als je moet wachten op een andere event uit je UI zonder dat die vanuit de huidige method kan worden uitgevoerd.

Even de manier met JOptionPane:

Java:

public void incomingEvent(Event e)
{
    // do first stuff
    int answer = JOptionPane.showConfirmDialog(....);
    // do other stuff
}

Ipv showConfirmDialog kun je ook andere static methods van JOptionPane gebruiken. Deze zijn allemaal blocking in de huidige method totdat de dialog wordt afgesloten.
Alternatief kun je ook een eigen (J)Dialog schrijven met daarin de benodigde knoppen (OK, Cancel, ?). Aan deze knoppen kun je gewoon op de standaard manier action listeners / actions hangen.
Het aanroepen gaat bijna hetzelfde:

Java:

public void incomingEvent(Event e)
{
    // do first stuff
    MyDialog dialog = new MyDialog(...);
    // more initialization of dialog
    dialog.setVisible(true);
    // do other stuff
}

Een dialog of frame showen (setVisible(true) is ook blocking totdat het dialog of de frame wordt gesloten dmv hide() of dispose() (kruisje rechtsboven werkt ook tenzij er setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE) is aangeroepen).

[ Voor 4% gewijzigd door Robtimus op 04-06-2005 15:00 ]

[Swinnio]

Bedankt voor de info tot nu toe! Een inline action listener lijkt me inderdaad de beste oplossing.
Nog even voor de duidelijkheid: de dialog die ik gebruik is geen Swing-dialog. Ik heb dan ook niet de optie blokkende methoden of andere opties uit Swing te gebruiken. In principe is de enige methode via het registreren van een listener voor events die uit de dialog komen en daar op te reageren.

[Swinnio]

Heb nu het onderstaande geprobeerd, met 2 andere problemen als gevolg. Ten eerste heb ik alleen toegang op result wanneer deze final is. Dit maakt het verzetten van de flag natuurlijk niet meer mogelijk. Dit moet echter niet al te lastig op te lossen zijn.
Het grotere probleem is dat de dialog niet blokkend is. Dat wil zeggen: ik krijg het ActionEvent wel mee, maar op dat moment is al lang de default waarde terug gegeven. Ben bang dat zich dat niet op laat lossen, zolang ik niet in staat ben de ApplicationDialog aan te passen (hetgeen niet het geval is)....

Java:

   public boolean incomingEvent(String number) {
        final boolean result = false;

        final ApplicationDialog dialog = appCon.getApplicationDialog();

        dialog.addActionListener(new ActionListener() {
            Item message = new Item("Incoming event", null);

            final Item item1 = new Item("Accept", null);
            final Item item2 = new Item("Reject", null);

            DialogRegistration reg = showDialog(ApplicationDialog.QUESTION, 50,
                    false, message, item1, item2);

            public void actionPerformed(ActionEvent event) {
                if (event.getSource() == dialog) {
                    System.out.println("*** Inline listener event");

                    if (event.getItem().equals(item1)) {
                        // result = true;

                    } else if (event.getItem().equals(item2)) {
                        // result = false;
                    }
                }
            }
        });

        return result;

    }

[JaWi]

Voor wat betreft de toegang tot je 'result' variabele, zet hem als protected member van je klasse en probeer hem zo eens te benaderen:

Java:

<Naam klasse die incomingEvent implementeerd>.this.result = <true|false>;

[Swinnio]

JaWi schreef op maandag 06 juni 2005 @ 11:46:
Voor wat betreft de toegang tot je 'result' variabele, zet hem als protected member van je klasse en probeer hem zo eens te benaderen:

Java:

<Naam klasse die incomingEvent implementeerd>.this.result = <true|false>;

Ja, dat zal wel lukken. Niet zo'n groot probleem, zoals ik al zei. Enkel niet netjes misschien om een klasse-variabele te moeten maken i.pv. een method variabele.

[JaWi]

Swinnio schreef op maandag 06 juni 2005 @ 11:53:
[...]
Ja, dat zal wel lukken. Niet zo'n groot probleem, zoals ik al zei. Enkel niet netjes misschien om een klasse-variabele te moeten maken i.pv. een method variabele.

Da's waar; maar je kunt natuurlijk hetzelfde zeggen voor inline gedefineerde anonymous classes; als je je ActionListener als named private inner class opneemt, dan heb je het hele probleem niet meer...