Search results

You must compile the file SDLMain.m along with test.cpp. SDLMain.m contains glue code that you need to run SDL apps on Mac OS X. The SDL development libraries for Mac OS X contain SDL Xcode project templates. Building a project from the templates is going to be easier for a novice than...

An Xcode target creates a specific application, library, or framework. Because of this, there is not much use in separating the target from the project. Xcode targets can have direct dependencies. Suppose you're writing a library and you want to write an application to test the library. You...

Create a C++ Tool project (or Standard Tool project if you're using C instead of C++) in Xcode. Add the OpenGL and GLUT frameworks to your project. That should be enough to compile GLUT code on Mac OS X.

I don't understand why you wouldn't use Interface Builder and nib files if you're writing Cocoa applications. Interface Builder is one of the reasons why writing Cocoa applications is easier than writing applications with other frameworks. You can easily add an item to the application menu in...

Create a C++ Tool project. Doing so will let you write command-line C++ applications that let you concentrate on learning C++ without having to worry about the Cocoa and Carbon GUI frameworks. If you want to create GUI applications in C++, you're going to have to use Carbon or a...

Have you tried Automator? Automator comes with a Build Xcode Project action. Xcode has project templates to create your own Automator actions. Apple has an article on automating Xcode on their developer site.

On Mac OS X 10.2 Xcode is called Project Builder. Apple changed the name in 10.3. You should have a Developer Tools CD with Mac OS 10.2 that contains Project Builder. You should be able to write standard C and C++ programs with Project Builder without having to worry about compile time...

Since your goal is to learn Cocoa, you have no reason to learn C++. There is no C++ in Cocoa. Learn C, then move on to Objective C/Cocoa.

I have an article on my book's site that walks you through creating your first Xcode project. The article creates a C++ command-line program, but you can use the article to create a C command-line program. Create a Standard Tool project instead of a C++ Tool project.

Mac OS X has two functions you can use for high precision timing: Microseconds() and UpTime(). These are C functions so you don't have to use Objective C or Cocoa. I wrote an article that shows you how to use Microseconds() and UpTime().

The linker can't find the nsl, socket, and resolv libraries. Use the -L option and supply the path to the libraries. -L/path/to/nsl/library

If you're running Mac OS X 10.4.3 and later, doing a Get Info on the executable file will tell you the architectures the executable was built for. The architecture information is in the More Info section.

Using gcc 4 is the easiest way to build a universal binary. But you can build a universal binary that uses gcc 4 to build the Intel version and uses gcc 3.3 to build the PowerPC version. You have to add the build setting GCC_VERSION_ppc to your project and give it the value 3.3.

If you want to build an Intel version of your program, you must use gcc 4. But there's still a place for gcc 3.3 if you are writing C++ programs. C++ programs compiled with gcc 4 will not run on anything earlier than Mac OS X 10.3.9. Compiling with gcc 3.3 allows you to support earlier versions...

Not true. Apple has added a lot to Carbon that will not run on Mac OS 9. Xcode wouldn't have a Carbon application project template if Carbon was meant only for Mac OS 9 because Xcode creates only Mac OS X applications. Not true. Both Cocoa and Carbon applications are compatible with Mac OS X...

If you don't want to use timers, you could use QuickDraw. It's been deprecated in Mac OS X 10.4 so you'll get a bunch of warnings if you compile QuickDraw code on 10.4, but the code will compile. I wouldn't recommend QuickDraw for new code, but you apparently have old QuickDraw code that works...

It depends on how often you're running the simulation and displaying the results. If you run the simulation once and display the results as the simulation runs, event timers won't help you a lot. If the simulation is going to be running for a long time, placing your calls to runModel() and...

If you need something to happen periodically, you should use an event timer. Call your model simulation in the event timer. You control how often the timer fires. I have an article on event timers at my website, which you can reach by clicking the link in my signature.

No because your doCommand loop handles only command events. Other events won't get handled. You need to call the function HIViewSetNeedsDisplay(). This function tells the operating system that the view needs to be drawn. The operating system will generate a kEventControlDraw event for you...

To handle menu selections in Carbon, you must write an event handler. The event handler calls GetEventParameter() to determine the menu command (menu item) the user selected. The event handler's third argument is a pointer to data the event handler needs to do its job. You supply the data...