What's the modern equivalent of GetNextEvent in Cocoa?

I'm porting an archaic C++/Carbon program to Obj-C and Cocoa. The curre开发者_JAVA技巧nt version uses asynchronous usb reads and GetNextEvent to read the data.

When I try to compile this in Objective C, GetNextEvent isn't found because it's in the Carbon framework.

Searching Apple support yields nothing of use.

EDIT TO ADD:

Ok, so what I'm trying to do is run a document scanner through USB. I have set up the USBDeviceInterface and the USBInterfaceInterface (who came up with THAT name???) and I call (*usbInterfaceInterface)->WritePipeTO() to ask the scanner to scan. I believe this works. AT least the flatbed light moves across the page...

Then I try to use *(usbInterfaceInterface))->ReadPipeAsyncTO() to read data. I give this function a callback function, USBDoneProc().

The general structure is:

StartScan()
WaitForScan()

StartScan() calls the WritePipeTO and the ReadPipeAsyncTO

WaitForScan() has this:

while (deviceActive) {
    EventRecord event;
    GetNextEvent(0,&event);
    if (gDataPtr != saveDataPtr) { // more data up the timeout    
        timeoutTicks = TickCount() + 60 * 60;
        saveDataPtr = gDataPtr;
    }
    if (TickCount() > timeoutTicks) {
        deviceActive = false;
    }
}

Meanwhile, USBDoneProc incrementing gDataPtr to be the end of the data that we've read so far. It gets called several times during the asynchronous read, called automatically by the callback, as far as I can tell.

If I cake out the GetNextEvent() call in the WORKING code the USBDoneProc doesn't get called until the asynchronous readpipe timesout.

So it looks to me that I need something to give control back to the event handler so that the USBRead interrupts can actually interrupt and make the USBDoneProcget called...

Does that make any sense?

thanks.

I suppose the nearest thing to a Cocoa equivalent would be -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]. But bear in mind that GetNextEvent is archaic even for Carbon. The preferred way of handing events is the "don't call us, we'll call you" scheme, where the app calls NSApplicationMain or RunApplicationEventLoop and events are dispatched to you.

EDIT to add: Does you app have a normal event loop? If so, maybe WaitForScan could start a Carbon timer and return to the event loop. Each time the timer fires, do what you did in the WaitForScan loop.

there is a USB hidapi that works for mac on windows. http://www.signal11.us/oss/hidapi/

may this could be of help to you?

It works fine (I can list the connected USB devices and connect/write/read to a device); however, if i USB device is connected/disconnected during the runtime of the application, I don't see the new connected/disconnected devices.

See: https://github.com/signal11/hidapi/issues/14

If I add the following code to hidapi, then hidapi detects the new USB devices.

#include <Carbon/Carbon.h>
void check_apple_events() {
    printf("check_apple_events\n");
    RgnHandle cursorRgn = NULL; 
    Boolean gotEvent=TRUE; 
    EventRecord event; 
    while (gotEvent) { 
        gotEvent = WaitNextEvent(everyEvent, &event, 0L, cursorRgn); 
    }
}

I need to compile this on OSX10.5 because it uses Carbon instead of Cocoa. I am currently looking how to transform this to Cocoa.

you are also trying to move your code to cocoa, right? let me know if you find out; I'll post it here if I get it.

regards, David

Have you considered throwing the whole thing out and using Image Kit's new-in-10.6 scanner support instead? Even if it's custom, writing a TWAIN driver for it might be easier (and is certainly better) than trying to twist Cocoa into a GetNextEvent shape.