Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Accessing user interface from ioProc
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accessing user interface from ioProc

You could always set up an NSTimer that fires at what ever interval you need - then in the callback check the global value to see if the UI needs updating. The NSTImer callback runs on the same thread that the timer was created - so create it in your main thread.

Robert.



On Nov 22, 2003, at 11:30 AM, Michael Bonnice wrote:

performSelectorOnMainThread does not work as it still gives the message about memory leak due to not having an autorelease pool. My problem is fixed when I create an autorelease pool at the start of the ioproc then release it at the end. However, given the warnings that this will eat time, I'd like to avoid it.

I just want something simple. I can just store the value that I want my interface to display into a global variable. Then, if I could figure out how to create an object that gets called during the main run loop, I'll have that object look for that global variable and send the message to the interface to display it. I don't need to pass messages, or us NSConnections or NSPorts or anything tricky.

How do I get a piece of my own code called from the main run loop? In the old days (GetNextEvent!) I would wait for an idle event and do my processing at that time.

Mike

On Nov 21, 2003, at 4:48 PM, James McCartney wrote:

On Nov 20, 2003, at 12:05 AM, Michael Thornburgh wrote:

from your IOProc, you can queue up something to happen in the main thread to actually do your UI updating, see -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:] for more information (and you _don't_ want to waitUntilDone, of course!).

I'm not an expert on the Cocoa side so I am just guessing, but I would question whether this is safe in the ioProc. In order to send this selector to the main thread, it is probably putting something on a message queue and that queue is probably protected with a lock. Taking a lock in the ioProc is not good.

When I want to do some messaging from the ioProc I use a lock free FIFO, or a pthread_cond_signal() or a combination of both.

James McCartney email@hidden
Apple CoreAudio
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
References: 
 >Accessing user interface from ioProc (From: Michael Bonnice <email@hidden>)
 >Re: Accessing user interface from ioProc (From: Michael Thornburgh <email@hidden>)
 >Re: Accessing user interface from ioProc (From: James McCartney <email@hidden>)
 >Re: Accessing user interface from ioProc (From: Michael Bonnice <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.