Working With Carbon
Post: #1
Hi Guys,
I'm entirely new to developing with Carbon, and I'm experiencing some difficulty. I wrote a short bit of code I expected to work, but found that the window would not take the focus, move, resize or appear in the dock. It's my understanding that the standard handler will take care of all of this for you, unless you need to specialize the behaviour - which I don't need to do for this simple example. I've tried code from Apple's developer site and it seems to have the same issue. I'm trying to use CreateNewWindow, and I'm avoiding .nibs.
Here's a really short example of something I can't make work properly.
I believe I'm missing something very simple, but I can't seem to track down what. Any advice at all would be appreciated.
Andrew.
I'm entirely new to developing with Carbon, and I'm experiencing some difficulty. I wrote a short bit of code I expected to work, but found that the window would not take the focus, move, resize or appear in the dock. It's my understanding that the standard handler will take care of all of this for you, unless you need to specialize the behaviour - which I don't need to do for this simple example. I've tried code from Apple's developer site and it seems to have the same issue. I'm trying to use CreateNewWindow, and I'm avoiding .nibs.
Here's a really short example of something I can't make work properly.
I believe I'm missing something very simple, but I can't seem to track down what. Any advice at all would be appreciated.
Andrew.
Code:
/******/
#include <Carbon/Carbon.h>
#define kWindowTop 100
#define kWindowLeft 50
#define kWindowRight 250
#define kWindowBottom 250
void Initialize (void)
{
WindowRef theWindow;
WindowAttributes windowAttrs;
Rect contentRect;
windowAttrs = kWindowStandardDocumentAttributes | kWindowStandardHandlerAttribute;
SetRect (&contentRect, kWindowLeft, kWindowTop, kWindowRight, kWindowBottom);
CreateNewWindow (kDocumentWindowClass, windowAttrs, &contentRect, &theWindow);
ShowWindow (theWindow);
}
int main (void)
{
Initialize ();
RunApplicationEventLoop ();
return 0;
}
Post: #2
You need an application bundle to get focus. Are you using Xcode? If so, are you using the Carbon Application template? If you're not using Xcode, you'll need to construct the bundle yourself in your Makefile or whatever other build system you're using.
BTW, don't avoid nibs
BTW, don't avoid nibs
Post: #3
Your code appears fine. Just to be sure I copied your code and compilied it as is. It worked just fine creating a new little document window with the standard window handlers working.
Did you create your project using the "Carbon Application" template? Create a new project using the "Carbon Application" template, then replace the code in the main.c file it creates for your with your code. Better yet, just #ifdef it out and paste your code after it. Then you can reference the default main code later to see how to use nibs and event handlers. Don't worry about the nib (and other files) it creates for you. Just leave them there til you're ready to do something with them as well. They will be harmless and do nothing until you do.
Did you create your project using the "Carbon Application" template? Create a new project using the "Carbon Application" template, then replace the code in the main.c file it creates for your with your code. Better yet, just #ifdef it out and paste your code after it. Then you can reference the default main code later to see how to use nibs and event handlers. Don't worry about the nib (and other files) it creates for you. Just leave them there til you're ready to do something with them as well. They will be harmless and do nothing until you do.
Post: #4
Hey guys.
Thanks, the problem was that I didn't have it in a bundle. I had built it using the Standard Tool selection, as that was how I had originally built it with GLut. Now it works.
The next problem I'm having is something that's probably fairly out of the ordinary.
I have two implementations of my code, one done with glut, one I'm moving to Carbon.
What I need is to have the message pump (RAEL) in a second thread. (This has been mandated to me, and I don't have the ability to change it.) The main thread just issues a create window, and drawing routines while the second thread manages the window events in the background. Here's an example of what a program written in this way would look like.. (Very Logo-esque).
I managed to get this working with glut, simply by putting glutMainLoop in a new thread. RAEL in a separate thread doesn't work at all however, and while the window does draw, I'm once again unable to interact with it.
Any thoughts? Besides this being a bad idea?...
Andrew.
Thanks, the problem was that I didn't have it in a bundle. I had built it using the Standard Tool selection, as that was how I had originally built it with GLut. Now it works.
The next problem I'm having is something that's probably fairly out of the ordinary.
I have two implementations of my code, one done with glut, one I'm moving to Carbon.
What I need is to have the message pump (RAEL) in a second thread. (This has been mandated to me, and I don't have the ability to change it.) The main thread just issues a create window, and drawing routines while the second thread manages the window events in the background. Here's an example of what a program written in this way would look like.. (Very Logo-esque).
Code:
Window w = CreateMyWindow();
SetViewport(w, 0, 0, 300, 300);
SetCoordinateSystem(w, 0, 0, 10, 10);
DrawLine(w, 0, 0, 500, 500);
DrawRect(w, 30, 30, 500, 500);
getchar();I managed to get this working with glut, simply by putting glutMainLoop in a new thread. RAEL in a separate thread doesn't work at all however, and while the window does draw, I'm once again unable to interact with it.
Any thoughts? Besides this being a bad idea?...
Andrew.
Post: #5
Events on Mac OS X must be handled on the main thread. I'm very surprised that GLUT worked for you. You can do your OpenGL stuff on a secondary thread if you like, though you'll need synchronization around window resizing, etc.
Post: #6
I've found the documentation on this now, and from what I understand although RAEL won't work, I may be able to write my own message handling routines that will, is that true?
Perhaps I should explain a little further. I've got a toolkit written in a variety of different languages that all play nice with each other. They are simulations running on the command line. The idea is that the simulation should be able to spawn a window and display itself without having to rewrite all of the simulation toolkit to allow for this. The hope was that by offloading the message proccessing to a second thread, this could be done without altering any of the toolkit code. As this toolkit is widely used, this sort of alteration just isn't possible.
We were trying to avoid having a separate process running the windowing code and connecting to it in a client-server fashion, but if we have to do that we could.
Are there any sort of facilities for off-main-thread message processing at all on OS X? The old WaitNextEvent perhaps? It doesn't even need to be Carbon I suppose, as long as I could wrap it all up with a C interface afterwards.
Andrew.
Perhaps I should explain a little further. I've got a toolkit written in a variety of different languages that all play nice with each other. They are simulations running on the command line. The idea is that the simulation should be able to spawn a window and display itself without having to rewrite all of the simulation toolkit to allow for this. The hope was that by offloading the message proccessing to a second thread, this could be done without altering any of the toolkit code. As this toolkit is widely used, this sort of alteration just isn't possible.
We were trying to avoid having a separate process running the windowing code and connecting to it in a client-server fashion, but if we have to do that we could.
Are there any sort of facilities for off-main-thread message processing at all on OS X? The old WaitNextEvent perhaps? It doesn't even need to be Carbon I suppose, as long as I could wrap it all up with a C interface afterwards.
Andrew.
