Hi Rick (the other one!), > If I understand correctly, it's not quite correct to call the > listener-callback mecahnism 'non object oriented' just because it doesn't use > inheritance. The term often used is the 'delegate model', I believe, as > distinct from the 'inheritance model'. But delegation of execution to contained objects is just what any procedural programming language can do - even C and certainly occam. So, I don't see `Objects' as contributing anything original here. The OO community may claim it as a special OO trick, but there doesn't seem to be anything new in it. The only new idea, apart from OO-syntax, is inheritance and everything that flows from that ... so it's those things that are `Object-oriented' ... nothing else seems to be new? Of course, if we interpret `Object-oriented' as a phrase from natural language, the code in active processes *is* written from the point of view of the object whose behaviour it is describing - i.e. occam processes are `Object-oriented'. On the other hand, the code in methods of passive objects (i.e. almost every class in a typical Java textbook) is written from the point of view of the invoking thread - i.e. such object methods are *not* `Object-oriented'. But I don't have much luck getting my OO colleagues here to go along with that ... > The latter is true, except for a very few exceptions. It has to run GUI > interactions in the JVM Event thread. I quote: > > Rule: Once a Swing component has been realized, all code that might > affect > or depend on the state of that component should be executed in the > event-dispatching thread. Thanks Rick. That clears that up. But they don't say why? It may be just an overkill to avoid the race-hazards of multiple threads doing this stuff ... i.e. that the less drastic: < Rule: Once a Swing component has been realized, all code that might < affect < or depend on the state of that component should be executed in one, < and only one, thread. may be an equally valid constraint. Or, it may be that they do some other thread-unsafe stuff that interferes in an uncontrolled way with what the Event thread does ... or with what each other are doing to the screen ... which would be pretty horrible. I'd still like to find out ... ;-) Cheers, Peter.