Re: Follow-up: Cocoa-Java Threads
Re: Follow-up: Cocoa-Java Threads
- Subject: Re: Follow-up: Cocoa-Java Threads
- From: OS X AIBO <email@hidden>
- Date: Sat, 26 Oct 2002 11:28:53 -0700 (PDT)
--- Steve Klingsporn <email@hidden> wrote:
>
override sendEvent
There used to be a method on Application (the predecessor of
NSApplication) just for app-defined event handling called
-applicationDefined:(NXEvent *)event which would be sent to the app
delegate if the app didn't implement it.
This method probably got nuked from OpenStep, along with the AppDefined
event types which are now "Apple additions" to the spec. (And I think
we know where that puts the Java implementation :-)
--Dan
--- Steve Klingsporn <email@hidden> wrote:
>
Thank you to all who responded. The NSEvent solution works, albeit
>
in
>
an awkward manner. It's a real bummer that NSResponder doesn't have
>
delegate methods.
>
>
Here's another thing that didn't work, first:
>
>
NSApplication.sharedApplication().tryToPerform(new
>
NSSelector("scrollConversationView", new Class[] { }), null);
>
>
The selector is performed from the calling thread. You can easily
>
see
>
what the calling thread is by:
>
>
System.out.println(Thread.currentThread()). Naming your threads
>
helps
>
(Thread.setName()).
>
>
Here's what does seem to work:
>
>
1. Subclass (yuck) NSApplication, and override sendEvent like so.
>
Be
>
sure to call super().sendEvent(event) first, as if you don't, your
>
app
>
will not respond to events at all:
>
>
public class AtaxxApplication
>
extends NSApplication
>
{
>
public void sendEvent(NSEvent event)
>
{
>
super.sendEvent(event);
>
if (event.type() == NSEvent.ApplicationDefined &&
>
event.subtype() ==
>
AtaxxController.SCROLL_CONVERSATION_EVENT)
>
{
>
// This is app-specific, obviously, as is the constant above
>
>
AtaxxController.sharedController().scrollConversationView();
>
}
>
}
>
}
>
>
2. From the thread that you want to post an event from, call
>
something
>
similar to this:
>
>
/**
>
Posts an application-defined event
>
@param type the event type
>
@param data1 the first parameter
>
@param data2 the second parameter
>
@param front post to the front of the queue?
>
**/
>
public void postApplicationDefinedEvent(short subtype,
>
int data1,
>
int data2,
>
boolean front)
>
{
>
/* Thread safety is so 1993 */
>
NSEvent event =
>
NSEvent.otherEvent(NSEvent.ApplicationDefined,
>
new NSPoint(0, 0), 0, System.currentTimeMillis() *
>
1000.0,
>
0,
>
null, subtype, data1, data2);
>
NSApplication.sharedApplication().postEvent(event, front);
>
}
>
>
3. The subtype should be a short constant indicating the type of
>
event, data1 and data2 are whatever you want them to be, and front
>
would be whether or not you want the event posted to the front of the
>
>
responder's event queue. You might want to add a "responder"
>
parameter
>
if you're not sending to NSApplication.sharedApplication().
>
>
And that's it. It works. Great. Not great, actually, but "it
>
works."
>
>
Don't forget to change the class of your application from
>
"NSApplication" to your subclass in the Project->Edit Active
>
Target->Info.plist settings->Cocoa-Specific area. Otherwise, you
>
won't
>
get this new behavior.
>
>
Thanks to all who helped me out. Cocoa Team, it would be really cool
>
>
if you'd maintain parity between Java Cocoa and Objective-C Cocoa.
>
Those new 10.2 methods would be nice, as would Address Book API,
>
Rendezvous API, NSNet*, even NSThread (if possible).
>
>
Steve
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.