macOS Newbie question about IBOutlets access

[jivaro]

How can I access IBOutlets from my graphic interface in main.c ?? I would like to read and change NSTextFields from my interface in my main program, but I have access to the IBOutlets only within the interface class implementation, not in my main program.... :-((

I understand that what I want to do is something quite "natural" but i have been googling this issue without any success so far.

Thanks for your help.

Joan

 

[Senor Cuete]

It sounds like you are attempting to communicate between two .xibs - MainMenu.xib and another one - perhaps one that's a panel.

This is done with notifications.

 

[Sydde]

You typically do not write GUI code in main.c but let the nib create the objects that effect your program. IBOutlets give those objects consistent connections to each other when the nib is loaded. main() simply starts the runtime process and is usually not even touched by Cocoa GUI programmers.

 

[jivaro]

You typically do not write GUI code in main.c but let the nib create the objects that effect your program. IBOutlets give those objects consistent connections to each other when the nib is loaded. main() simply starts the runtime process and is usually not even touched by Cocoa GUI programmers.

You are probably right: perhaps I could manage to do what I want to do without touching at the interface objects in my main.c. But let's realize that I want to display the result of some iterative process in a NSTextField: is it really necessary that I have this iterative process in my controller interface and not in my main program in order to access the NSTextField ?

Joan

----------

It sounds like you are attempting to communicate between two .xibs - MainMenu.xib and another one - perhaps one that's a panel.

This is done with notifications.

I have seen something about notifications related to this issue in

http://stackoverflow.com/questions/1936185/access-iboutlet-from-other-class-objc

but it looks like an awkward way of doing something that I think that should be easier.... Anyway following your suggestion I'll explore this option more in depth. Thanks for the suggestion.

Joan

 

[Oligarch]

is it really necessary that I have this iterative process in my controller interface and not in my main program in order to access the NSTextField ?

Yes.

Sydde put it well. Unless you are writing a console app, nothing goes in main.c. Console apps are small programs launched from the command line that perform one task, like your iterative process, without user interaction, and then terminate.

GUI apps (apps with a graphical user interface) are the opposite: after you launch them, they sit idle and wait, until ordered to quit by the user. In between, they burst into (mostly imperceptibly short) bouts of activity, but only in response to some user action.

You need at least one class which you might call AppController and which you instantiate in your main nib or xib file. Give it IBOutlet instance variables to your user interface elements, and an IBAction instance method which you might call -iterativeProcess:. This is where you put your code. Pure C code works just fine in Objective-C .m source files, and here it can directly read and change the text fields. Now the only thing still missing is a way to trigger its execution. This is done by making your AppController the target of a control (a menu item, a button, or your text field) and selecting -iterativeProcess: as the action. Now every time you push the button or hit return in your text field, your code gets executed, with the parameters it reads from the text fields. This is what you want, no?

 

[Sydde]

You are probably right: perhaps I could manage to do what I want to do without touching at the interface objects in my main.c. But let's realize that I want to display the result of some iterative process in a NSTextField: is it really necessary that I have this iterative process in my controller interface and not in my main program in order to access the NSTextField ?

Joan

It is possible, but it is kind of a pain. Nibs are designed to connect with Cocoa objects, the main() function is not a Cocoa object (which typically all descend in an ownership tree from NSApplication). You could create an appropriate object to serve as your nib's owner, load the nib manually, and communicate with that object to achieve what you want, but it sure is a lot easier to work with the built-in application architecture.

 

[jivaro]

Ok, understood. I must change my way of doing things. I'm coming from original -that i, old- times of C (yes, I learned with Kernighan & Ritchie), I'm not used at all at objects, I'm coming from procedural world, and I must learn the miriads of things related with Cocoa.... The first thing to learn is how to organize things with the new environment. Thanks for your replies.

Joan

 

[Sydde]

XCode makes the OOP process really easy to start. With the application template, you can immediately build a useless working program that shows a window and does nothing. To that, you add your features and code to make it useful.

In your case, it might get tricky because the paradigm is kind of inside out. Procedurally, you might write a loop that includes a check at the end of the pass to see if the user wants to quit or whatever. In Cocoa, the main runloop is in the background from the programmer's perspective, so the code you write has to exit to allow for such checks or you will freeze the app's UI ("rainbow pizza") and the user will only be able to force-quit.

You could run your process in a separate thread, and that might be the best choice if it really has to run continuously, but if it can run periodically instead, if pauses of a hundred milliseconds or so are acceptable, you would probably be better off using a timer to run interval passes on the main thread.

OS X fully supports procedural style programming alongside Objective-C. If that is what you are comfortable with, you only need to learn enough OOP to make a GUI work, then graft your procedural code onto it. Both styles have their place, sometimes side-by-side in the same program.

 

[jivaro]

I think that I grasp the idea. Still a lot to learn. Thanks for your help.

Joan