Simple carbon question.



I am porting a simple app to MacOS at the moment. It is a command line program which needs a single window for output.

At the moment I have a test harness which does the following:

I have created a window with CreateNewWindow (document class, standard attributes).

Then I make it visible.

Then I install the standard event handler and add my own handler for mouse events.

Finally I run a simple event loop which dispatches events to the window.

The window is appearing and my mouse click handler is being called, but for some reason it is impossible to give the window focus or move it. I was under the impression that the standard event handler took care of that.

Am I missing something obvious?
I tried that. It doesn't seem to make any difference.

Code is pasted in below:

#include <stdio.h>
#include <stdlib.h>
#include <Carbon/Carbon.h>

const EventTypeSpec kEvents[] =
{ kEventClassMouse, kEventMouseDown },

* Event handler
static OSStatus
event_handler( EventHandlerCallRef inHandlerCallRef,
EventRef inEvent,
void *inUserData )
OSStatus result = 0;

UInt32 class;
UInt32 kind;

class = GetEventClass( inEvent );
kind = GetEventKind( inEvent );

case kEventClassMouse:
printf("mouse event\n");
result = CallNextEventHandler(inHandlerCallRef, inEvent);
return result;

* Main
int main(int argc, char **argv)
WindowRef window;
EventHandlerRef handler;

Rect rect; = rect.left = 0;
rect.bottom = 480;
rect.right = 640;

window = NULL;

* Create window

if(CreateNewWindow( kDocumentWindowClass,
kWindowStandardDocumentAttributes |
&window ))
fprintf(stderr, "failed to create window.\n");
return -1;

* Show window
MoveWindow( window, 100, 100, true );
ShowWindow( window );
SelectWindow( window );

if( InstallStandardEventHandler( GetWindowEventTarget( window ) ) )
fprintf(stderr, "failed to install std event handler.\n");
return -1;

if( InstallEventHandler( GetWindowEventTarget( window ),
GetEventTypeCount( kEvents ),
&handler) )
fprintf(stderr, "failed to install event handler.\n");
return -1;

* Event loop.
EventRef theEvent;
EventTargetRef theTarget;
//theTarget = GetEventDispatcherTarget();
theTarget = GetWindowEventTarget( window );

while( ReceiveNextEvent( 0,
&theEvent ) == noErr)

SendEventToEventTarget (theEvent, theTarget);
DisposeWindow( window );

return 0;
I would start over by creating a Carbon application in Xcode. If you build the project and run the program, it opens a blank window that you can move, resize, minimize, and zoom. The program does all that just by calling RunApplicationEventLoop(). From that base you can install the standard window event handler and add your own event handler.
Do you absolute have to use Carbon?? If you're starting Mac development, and working with command line apps from other OS's (or even the Mac), Cocoa apps are the way to go. 10x easier to create a window and initialize it (no code necessary!).

Anyways, just a thought to make your life easier.. (I can whip up an example if you want to throw me some code) :D
OK, I go back to your question.

I'm learning Carbon since some days and I have had the same problem like you. I could solve it by changing the attributes passed to CreateNewWindow():
   kWindowStandardDocumentAttributes | kWindowStandardHandlerAttribute | kWindowInWindowMenuAttribute, 
   &windowRect, &window);

Can this help?

squart> I will give that a try, thanks.

kainjow> I would prefer to use cocoa if I was writing a new application. The software I am trying to port is a command line app at heart - the window is pretty much optional & mainly for output. Carbon seemed a better fit for the existing architecture.
Fixed it (kind of).

Moving the executable into a carbon bundle seemed to sort the messaging issue out.

Unfortunately the whole point of the exercise was to add an output window to a command line application, but it is better than nothing I suppose.

It took me a total of 25 minutes to get my first win32 API program running. It took me about an hour to do the same thing with X-11.

I have wasted about 6 hours over the last 3 weeks trying to get a simple empty window to work with MacOS-X.


Because it apparently didn't occur to anyone at Apple that a programmer could be so perverse as to build a program using make, and then have the nerve to try to run it from the command line as well.

Why bother to handle such an improbable use case it when everyone in the world uses Xcode? After all, nobody is going to be porting code from other operating systems, particularly not those funny UNIX things, they will want to rewrite it all instead.

This is doubly true of people who want to do number crunching, because they just love spending their time writing GUIs when they could be doing work.