本文介绍了TableView内部tableview单元格迅速3的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
我正在尝试在tableview单元格中显示tableView，而父级和子级tableview都具有动态单元格高度。
I'm tring to display tableView inside tableview cell while both parent and child tableview have dynamic cell height.
第一个问题是，并非所有单元格都显示子tableview。
在显示childTableView的单元格中，childTableView的高度不正确。
First problem is not all cells show child tableView.In cells that show childTableView, childTableView height is not right.
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;
}
}
并在Parent tableview单元格内，我只注册childTableView单元格，重新加载tableview
and inside Parent tableview cell I just register childTableView cell and reloading 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
}
我在做什么错？
推荐答案
-> Disable childtableview scrolling.
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
return CGFloat((ChildTableviewCellItem.count) * Height_childtableviewcell+Height_MainTableviewcell)
}
这篇关于TableView内部tableview单元格迅速3的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！