Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to access an IBOutlet from another class

I want to know how to access an @IBOutlet declared in a class from another class

for example, I have a class named myfirstview

class MyFirstView: UIViewController {

    @IBOutlet var lblred: UILabel! = UILabel()
}

I want to change the text of the lblred from another class named MySecondView which is written in another .swift file:

class MySecondView: UIViewController {

    func modify() {
        let mfv = MyFirstView()
        mfv.lblred.text = "Hello"
    }
}

But nothing happens.
I have connected lblred with a storyboard label. I have searched a lot about this on the web but I can't find the one which can solve my problem. Please help me solve this problem.

Thank you.

like image 549
Daud 11 Avatar asked Feb 05 '15 12:02

Daud 11


People also ask

Why is IBOutlet weak?

In Mac development an IBOutlet is usually a weak reference: if you have a subclass of NSViewController only the top-level view will be retained and when you dealloc the controller all its subviews and outlets are freed automatically. UiViewController use Key Value Coding to set the outlets using strong references.

How do I unlink IBOutlet?

Select the view on the storyboard and then click the Connections Inspector. Then you can click the little x to remove an outlet reference.

What is IBOutlet and IBAction?

@IBAction is similar to @IBOutlet , but goes the other way: @IBOutlet is a way of connecting code to storyboard layouts, and @IBAction is a way of making storyboard layouts trigger code. This method takes one parameter, called sender . It's of type UIButton because we know that's what will be calling the method.


1 Answers

@Sheen is correct about your immediate problem, but your problem is deeper. No object should access another object's IBOutlets. It's not well defined what will happen. This has been a long source of bugs in ObjC code, and Swift escalates those common bugs to crashes.

IBOutlets are not assigned until the view is loaded. This means that if the view controller is allocated but has not been put on the screen yet, the IBOutlets are still nil. Accessing an implicitly unwrapped nil will crash Swift.

View controllers should only communicate with their children view controllers. They should not communicate with arbitrary view controllers in the system. Communication between arbitrary view controllers is done via the model. One view controller updates the model, and another view controller reads from the model. This is the Model-View-Controller pattern that most of Cocoa is built around.

View controllers may interact more directly with their children, but still should not modify IBOutlets directly. They should set properties. It is the child view controller's responsibility to move that data from the property to the label at the correct time (which may have to wait until viewDidLoad()). That's why it's called the "view controller." It is the one object responsible for its views. No one else should mess with them.

like image 65
Rob Napier Avatar answered Oct 04 '22 09:10

Rob Napier