Re: Cocoa really needs to be thread-safe
Re: Cocoa really needs to be thread-safe
- Subject: Re: Cocoa really needs to be thread-safe
- From: James DiPalma <email@hidden>
- Date: Sat, 9 Nov 2002 02:21:50 -0800
From: Ron Wilson <email@hidden>
So, although the exact problem expressed by the OP may be due to an
oversight in not adding the timer to the the run loops button tracking
mode,
The original poster was commenting about a child thread being unable to
update UI widgets while a button was depressed (his problem has nothing
to do with timers). I mentioned that a sample application written to
understand updating main thread ui widgets from a child thread had
similar problems; my sample application used a timer.
Neither of our problems are fixed by adding a timer to our run loops
NSEventTrackingRunLoopMode. My timer is running in a child thread whose
run loop never enters NSEventTrackingRunLoopMode, nor does adding my
timer to NSConnectionReplyRunLoopMode get my timer to continue firing
while a button is depressed.
What happens is that this line of code:
[proxyOfParentThread setNewTime:[NSDate date]];
never returns even though setNewTime is typed as a (oneway void)
method. Kind of a bummer. I think Steve Klingsporn is seeing a similar
problem. Both of our problems would be solved if AppKit where
thread-safe, but that is a hard problem to solve and won't likely
happen soon. I just want mouseDown: in NSButton and many other AppKit
widgets to not sit in an NSEventTrackingMode loop (i.e. call
nextEventMatchingMask:).
Google got me to
cocoa.mamasam.com, where someone had asked a different question and had
gotten somewhat the same answer as above (to use
NSEventTrackingRunLoopMode), and also that this still did nothing to
correct the problem during window resizing - NSWindow apparently uses
it's own event loop and does not honor NSEventTrackingRunLoopMode. The
docs for NSRunLoop say of NSEventTrackingRunLoopMode: "Use this mode
for
event tracking loops".
By testing with Cameron Hayne <email@hidden>'s test application,
I notice that NSWindow does use NSEventTrackingRunLoopMode, but somehow
his textfield is not updating with a count unless window resizes
actually happen (and then you'll see a large jump in count indicating
that his timer is actually firing while his window is resizing).
it sure looks like poor documentation contributed to the confusion.
While I'm glad to now remember that NSEventTrackingRunLoopMode is where
widgets spend their time, I don't think poor documentation has anything
to do with it. I just have a poor memory and didn't want to make
careless statements on cocoa-dev.
NSRunLoop clearly states that NSEventTrackingRunLoopMode is for event
tracking; so, when an NSButton is depressed and it highlights while
this mouse is within its borders, maybe NSButton is tracking events
(especially considering that all events go through an NSRunLoop that is
clearly not handling NSDefaultRunLoopMode events).
How would you know that NSButton calls is tracking events? well, there
is a document called, "Handling Mouse Events in Views" that you can get
to from reading NSView's documentation (which happens to be where
mouseDown: is defined). It states:
"NSViews that handle mouse clicks as a single event, from mouse down,
through dragging, to mouse up, must usually short-circuit the
application's normal event loop, entering a modal event loop to catch
and process only events of interest."
and includes some sample code that calls nextEventMatchingMask: on an
instance of NSWindow which is documented to use
NSEventTrackingRunLoopMode.
Being curious, I tried looking up NSEventTrackingRunLoopMode in the
Apple Cocoa docs, AppKiDo, Cocoa Browser and MTLibrarian. Not much
there. Nothing on Stepwise or Cocoa Dev Central. Google got me to
cocoa.mamasam.com
I don't use any of these tools that you mention, I typically program
with constant reference to Apple Cocoa docs which always contain enough
information for my needs (it took 2-3 minutes to find Handling Mouse
Events in Views". Using these tools you mention should have gotten you
from NSEventTrackingRunLoopMode to nextEventMatchingMask: in NSWindow
which should have lead you to "Handling Mouse Events in Views" too bad
it didn't work. I thought Cocoa Browser and MTLibrarian worked well
enough to find strings in cocoa documentation.
-jim
_______________________________________________
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.