TableView里面的tableview cell swift 3

Question

我正在尝试在 tableview 单元格中显示 tableView，而父 tableview 和子 tableview 都具有动态单元格高度。

第一个问题不是所有单元格都显示子tableView。 在显示childTableView的单元格中，childTableView高度不对。

 class ViewController: UIViewController {

@IBOutlet weak var tableView: UITableView!
var items = ["Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front !"

    ,"Consider, though, that Swift us a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!"  ,"ccc", "ddd","Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!","fff", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!","hhhh","Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!","jjj", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!"]
override func viewDidLoad() {
    super.viewDidLoad()
    setUpTableView();
}

func setUpTableView(){
    tableView.register(UINib(nibName: "MCQCell", bundle: nil), forCellReuseIdentifier: "MCQCell");
    tableView.estimatedRowHeight = 100;
    tableView.rowHeight = UITableViewAutomaticDimension;
}
override func didReceiveMemoryWarning() {
    super.didReceiveMemoryWarning()
    // Dispose of any resources that can be recreated.
 }
}   

  extension ViewController: UITableViewDelegate, UITableViewDataSource{
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    if(tableView == self.tableView){
        let cell = tableView.dequeueReusableCell(withIdentifier: "MCQCell", for:indexPath) as! MCQCell
        let row = indexPath.row
        cell.lblTxt.text = items[row];
        cell.tableView.tag = row;
        cell.tableView.dataSource = self;
        cell.tableView.delegate = self;
        cell.tableView.estimatedRowHeight = 60;
        cell.tableView.rowHeight = UITableViewAutomaticDimension;
        cell.setNeedsLayout()
        return cell;
    }else{
        let cell = tableView.dequeueReusableCell(withIdentifier: "ChoiceCell", for:indexPath) as! ChoiceCell
        let row = indexPath.row
        cell.lblTxt.text = items[row];
        return cell;
    }
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    if(tableView == self.tableView){
        return items.count;
    }else{
        return 5;
    }
}


func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
    return UITableViewAutomaticDimension;
}
}

在父 tableview 单元格中，我只是注册 childTableView 单元格并重新加载 tableview

  override func systemLayoutSizeFitting(_ targetSize: CGSize,
                             withHorizontalFittingPriority horizontalFittingPriority: UILayoutPriority,
                             verticalFittingPriority: UILayoutPriority) -> CGSize{

    tableView.reloadData()
    let size = CGSize(width: targetSize.width,
                      height: tableView.frame.origin.y + tableView.contentSize.height)
    return size

}

我做错了什么？

Answer 1

-> Disable childtableview scrolling.        

    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
                return CGFloat((ChildTableviewCellItem.count) * Height_childtableviewcell+Height_MainTableviewcell)
            }