Xcode: difference between "Build and Run" and "Build and Go"?

The "Build and Go" icon in your toolbar is actually sort of a pop-up menu (notice the small black triangle in it's lower right corner).

If you just click "Build and Go" it's the same as "Build and Run"... any modified files are compiled and linked then your application is executed.

But if you click-and-hold on the "Build and Go" icon then after a second or so you should see a pop-up appear that allows you to "Build and Run", "Build and Debug", "Run Executable" or "Debug Executable".

In fact the "Build" icon in the toolbar is similar (notice it too has a small black triangle). Click-and-hold on the "Build" icon allows you to "Build", "Clean All" or "Clean".

I don't know of a way that's built_into Xcode to tell it to execute your app in Terminal, but you could probably add a script to Xcode's script menu that did this for you.

Steve

Miguel,

I was wondering: When I do a new project in Xcode
and select Comand Line Utility>Stadard Tool. What
about the other choices? Does any of these work as a
standalone C that creates its own windows (not
terminal - comand line directed)? (<-Eventually
leading to a double clickable C application)</div>

All of the selections listed under "Applications" should result in double-clickable GUI applications. In fact, each of those project types will allow you to create a new project and immediately Build and Run a sort of "do nothing" GUI application without adding any code of your own.

However, each of the above app types will require some knowledge of their associated frameworks in order to add GUI elements to the windows and make the apps do what you want it to do.

The "Carbon Application" might be the one that would be easiest to use for plain vanilla C code. However, you'll have to learn about the Carbon APIs. These are "above and beyond" the standard C functions and typically will not be covered in a beginning C programming book.

Cocoa applications are what Apple recommends for new Macintosh apps. Cocoa uses Objective-C which is an object oriented extension to the C language... so you'll need to understand not only the Objective-C syntax but also the Cocoa frameworks/APIs. I use Cocoa whenever I can because I enjoy it much more than plain C or C++. I also prefer the Cocoa APIs over Carbon.

Cocoa and Carbon code can be mixed by the way. If needed you can call Carbon APIs from with a Cocoa application and vise versa.

Core Data is built upon Cocoa and provides database functionality and the ability to establish database entities and relationships using special Core Data tools within Xcode.

AppleScript Applications make use of what's also called "AppleScript Studio". They are written in the AppleScript language but also give you access to all the various Cocoa user interface elements (buttons, checkboxes, text fields, etc.). Once you're familiar with the AppleScript language and the AS Studio extensions you can easily and quickly create fairly sophisticated GUI apps. But AS Studio may not be suitable for large scale complex applications. I use AS Studio fairly frequently for small utilities that I want to create nice GUI interfaces for. AppleScript Studio is a lot of fun but the language is significantly different from C.

All of the above application types also allow you to use Interface Builder to create and configure the user interface elements of your application.

Some of the selections under the Java section probably allow you to build GUI java apps as well. But I'm not a java programmer so I'm not familiar with all those options.

If you're just learning the C language you may need to stick with the Standard Tool until you understand the basics. Once you feel more adventurous I'd suggest moving to a Carbon or Cocoa application and begin learning about those APIs.

Also, are there C interpreters for OS X out there?

Possibly, but none that I'm aware of.

Finally, why does the final file which is created
(the double clickable inside the debug that runs in
the terminal) not get saved in the Project folder?
Id like to know the logic, becuase this seems to be
the eventual objective of the application, yet it is
treated in a way I would not expect?

Your build products are kept in separate subfolders because by default you get two different "targets" with Xcode... a "Debug" target and a "Release" target. As the name implies the "Debug" target builds your app with debugging information so that you can run and test the app within Xcode's debugger. The "Release" target strips out the debugging information and optimizes the code so the resulting application is suited for distribution to other users. You can also create additional "targets" that have your own customized build options.

The subfolders are used primarily so you can have multiple versions of your built application, each built with their own set of build options.

Steve