TableView里面的tableview cell swift 3

Posted 2023-03-06

【中文标题】TableView里面的tableview cell swift 3

【英文标题】：TableView inside tableview cell swift 3

【发布时间】：2018-07-03 23:06:07

【问题描述】：

我正在尝试在 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

我做错了什么？

【问题讨论】：

你需要给你的子表视图高度限制

但我不希望这个表格视图在其父单元格内滚动我需要它来获取其子单元格的全部内容大小..

是的，当您重新加载表格时，我的回答相同，您可以设置 heightConstranint.constant = tableview.contentsize.height

是的，我这样做了，父表格视图单元格采用表格视图高度，但不是整个单元格高度

您找到解决方案了吗？

【参考方案1】：

-> Disable childtableview scrolling.        

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

【讨论】：

谢谢，但我不知道子表格视图单元格的大小，它们也有动态高度