I have a NSTableView where I wish to display a list of info.
Currently the viewForTableColumn method delegate never runs, but numberOfRowsInTableView does.
I have the NSTableViewDelegate and NSTableViewDataSource set in the ViewController head. And I set the tableview delegate and datasource to self. Does somebody know why it wouldn't run? I've added a screenshot and code below.
ViewController.h
#interface ViewController : NSViewController <NSTableViewDelegate, NSTableViewDataSource>
#property (strong) IBOutlet NSTableView *tableView;
#property (strong, nonatomic) NSMutableArray<App *> *installedApps;
#end
ViewController.m
- (void)viewDidLoad {
[super viewDidLoad];
_installedApps = [[NSMutableArray alloc] init];
_tableView.dataSource = self;
_tableView.delegate = self;
// Other stuff that populates the array
}
- (NSInteger)numberOfRowsInTableView:(NSTableView *)tableView {
return _installedApps.count;
}
-(NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
NSTableCellView *result = [tableView makeViewWithIdentifier:#"appCell" owner:self];
result.textField.stringValue = #"Hello world";
return result;
}
The view is in a container view, I have the 'appCell' identifier set to the Table Cell View.
The array _installedApps is empty and numberOfRowsInTableView: returns 0. Thus, tableView:viewForTableColumn: is not called because there is no row to show. No rows also means no columns.
You should also ensure that you have configured your table view as view based in attributed inspector of the table view.
I can't see it in the screenshots, but...is the highlighted row of the view hierarchy (Table Cell View) the one with the appCell identifier?
[minutes pass...]
Oops; sorry. I see you've noted that above.
The reason I ask is that I made a new project from your code, changing the array type from App to NSString, added a one-column table view to the storyboard, linked it to the code, added a couple enties to the array in -viewDidLoad, and -- once I put the appCell identifier in the right place (duh) -- it all worked fine.
This is super strange, but I had the very same issue, everything connected correctly, number of rows being called, but not viewForTableColumn... In the end the following Answer proved to be the solution:
https://stackoverflow.com/a/13091436/3963806
Basically, I had setup the tableview straight out of the Object library, no layout constraints etc... Once I added layout constraints, the method started to be called... Super strange as I could see and click on the "rows" but they weren't populated correctly... I think it's down to clipping as mention in the linked answer.
Related
I'm coding for iOS7.
I have a grouped UITableView, with 3 different sections, each one of them has multiple rows.
In every row there is an UITextField added as accessoryView:
UITextField *myTextField = [UITextField alloc] init];
cell.accessoryView = myTextField;
I need to retrieve the right cell/textField in other places of my code, for example this code was working up to iOS6:
-(void) textFieldValueDidChange: (UITextField*) sender
{
NSIndexPath *indexPath = [self.tableView indexPathForCell: (UITableViewCell*) sender.superview];
switch (indexPath.section){
case(SECTION_1):{
switch(indexPath.row){
case(ROW_1):{
//DO SOMETHING
}
}
}
}
}
This kind of code breaks in iOS7.
On another thread someone suggested to me to never retrieve my subviews like this but to assign the indexPath.row value to the tag property of the sender when the cell is created and then retrieve the right cell from it. This works perfectly when the table is a normal one and I am dealing just with the row number but here I have to keep track both of the row and the sections and there is only one tag property.
What would be my best option to deal with it? I thought about adding 1000, 2000, 3000 etc.. to keep track of the section, example: 2003 would mean indexPath.section = 2 and indexPath.row = 3 but this doesn't apper an elegant solution to me. Any idea?
Thanks
Nicola
What about creating a category on UIView with a property that will hold the indexPath?
.h:
#interface UIView (IndexPathTag)
#property (nonatomic, retain) NSIndexPath *indexPathTag;
.m
#implementation UIView(IndexPathTag)
Then, in your code, if you import UIView+IndexPath, you can do:
#import "UIView+IndexPathTag.h"
myView = [[UIView alloc] init];
myView.indexPathTag = indexPath;
I have a subclassed UITableView, 'subclassChild' which inherits from another subclass 'subclassParent'. 'subclassParent' then inherits from UITableView.
My view controller inherits from a custom View Controller 'GenericTableViewController', and contains my UITableViewController which has the class of 'subclassChild'.
'GenericTableViewController' customises my tables header and footers for all view controllers containing a table view.
My question is, how do I make it so that my UITableView can use 'subclassChild' and 'subclassParent' as its delegate and dataSource. Still making sure that 'GenericTableViewController' customises my tables header and footers.
Sorry if this is a bit confusing, I've tried to describe it as well as I can.
P.S I have added <UITabBarDelegate, UITableViewDataSource> in the header files.
And I have made sure that the table inherits from 'subclassChild' in IB.
Thanks in advance!
What you can do, is have your 'GenericTableViewController' have a delegate itself. It will do most of the work itself, but at the end it shall ask its delegate 'anything else to do'?
And when the delegate says 'Yes, there is something actually', that code will get executed, serving as data source, delegate or whatever you want it to be. As an example (please forgive me for code inaccuracies):
- (void) rowForIndex:(NSInteger)row {
if([delegate respondsToSelector:#selector("TVGetRow:")]) {
return [delegate TVGetRow:row]
} else return Rows[row];
}
This example assumes, that you have an array of tableview cells, but should give you a good idea. You don't need to implement UITableViewDataSource to that subclass header files, but instead use a custom protocol.
Edit: Since apparently I was unclear in what I was aiming to do, allow me to add a little information.
The basic idea is to use 'subclassChild' and through it 'subclassParent' as delegates for GenericTableViewController, instead of using 'subclassChild' as the type for the tableView. (You should never subclass a view, unless you intend to change it's drawing behaviour).
The general hierarchy would work like this:
subclassChild -> delegate -> GenericTableViewController <- DataSource/Delegate <- TableView
You'd need to create an init method, or a setter method, which sets this delegate, and a simple protocol, which allows you to call functions, like so:
#interface GenericTableViewController : UITableViewController <UITableViewDataSource, UITableViewDelegate> {
id theDelegate;
}
- (id) initWithDelegate:(id)delegate;
#end
#protocol GTVC
#optional
- (UITableViewCell *) getDataForRow:(NSIndexPath *)path;
- (void) rowSelected:(NSIndexPath *) path;
#end
In the .m file, this example would look like this:
#implementation GenericTableViewController
- (id) initWithDelegate:(id)delegate {
self = [super initWithNibName:#"TableView.nib" bundle:nil];
if(self) {
theDelegate = [delegate retain]; //The 'retain' is optional, really.
}
return self;
}
- (void) dealloc {
[theDelegate release]; //In case of retain -> release.
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
if([theDelegate respondsToSelector:#selector(getDataForRow:)])
return [theDelegate getDataForRow:indexPath];
else {
//Create general UITableViewCell
}
}
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
if([theDelegate respondsToSelector:#selector(rowSelected:)])
[theDelegate rowSelected:indexPath];
else {
//Do stuff
}
}
#end
This protocol/delegate 'game' can be expanded easily, giving you all levels of control you need...all the while with the GenericTableViewController as a 'backup', if any delegate isn't set, or 'not ready' to answer the request for further instructions.
I hope this helps.
I have a Nav controller that starts at a table view. Each row pushes to a detail UIView. I would like to have a next and previous button on the Detail UIView that would show next and previous views without going back to parent UITableView. All details are saved in an array. how can i access that array and its current index in DetailViewController.m .Thanx in advance.
Another clean (and elegant) way is to build some sort of connection between the table view datasource, which is normally the UIViewController that contains the table, and the detail view: this can be done using the Delegate pattern, typical of Cocoa framework.
In such case you can define a DetailViewDataDelegate protocol with two methods only:
-(id)nextTableObjectFrom:(id)referenceObject;
-(id)prevTableObject;(id)referenceObject;
where referenceObject is the calling object, that is the object detailed in the DetailView.
So DetailView will be defined in this way:
#interface DetailViewController:UIViewController {
}
#property (nonatomic,assign) id currentDetailedObject;
#property (nonatomic,assign) id dataDelegate;
and of course when you call the controller, typical from the tableView:didSelectElementWithIndexPath:animated: method, you will do something like this:
DetailViewController *dv = [[[DetailViewController alloc] initWithNibName:nil bundle:nil] autorelease];
dv.dataDelegate=self;
dv.currentDetailedObject=[mySourceArray objectAtIndexPath:indexPath.row];
[self.navigationController pushViewController:dv animated:YES];
Finally in the DetailViewController when you need the next (or prev) element from the table you will simply call:
-(IBAction)nextButtonPressed {
self.currentDetailedObject = [self.dataDelegate nextTableObjectFrom:self.currentDetailedObject];
}
Of course the implementation details may change, and in particular the delegate methods, to be implemented in the table's UIViewController, will depend on the data structure.
The advantage of this approach, which can be at first sight complicated, is quite elegant and avoids to pass objects along controllers, which is often a source of memory issues. Besides with the delegate approach you can implement any complicated feature (e.g.: you can even manipulate table view objects directly from the DetailViewController, at your own risk of course!)
The cleanest way is to create a custom initializer for DetailViewController:
#interface DetailViewController : UIViewController
{
NSArray* allObjects;
NSUInteger displayedObjectIndex;
}
- (id) initWithObjectAtIndex: (NSUInteger) index inArray: (NSArray *) objects;
#end
#implementation DetailViewController
- (id) initWithObjectAtIndex: (NSUInteger) index inArray: (NSArray *) objects
{
self = [super initWithNibName:nil bundle:nil];
if ( self ) {
allObjects = [objects copy];
displayedObjectIndex = index;
}
return self;
}
#end
That way, a DetailViewController always knows both what object it is displaying details for and the previous/next objects, if any.
I am loading new views for a small iphone app, and was wondering how to pass details from one to another?
I am loading a tableview full of data from and xml file, then once clicked a new view is brought in via:
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
SubInfoViewController *subcontroller = [[SubInfoViewController alloc] initWithNibName:#"SubInfoView" bundle:nil];
[self presentModalViewController:subcontroller animated:YES];
[subcontroller release];
}
Next step would be to tell the newly loaded view which row had just been loaded?
Any idea, thoughts more than welcome, and please be gentle big newbie...
I typically create my own init method to do things like this. I think it would likely be better to pass in the corresponding "model" object represented by the tableView row, rather than the row number itself, like this:
In SubInfoViewController.h
#interface SubInfoViewController : UIViewController {
YourObject *yourObject;
}
#property (nonatomic, retain) YourObject *yourObject;
Then in SubInfoViewController.m:
- (SubInfoViewController*)initWithYourObject:(YourObject*)anObject {
if((self = [super initWithNibName#"SubInfoView" bundle:nil])) {
self.yourObject = anObject;
}
return self;
}
You'd create and present it this way:
// assuming you've got an array storing objects represented
// in the tableView called objectArray
SubInfoViewController *vc = [[SubInfoViewController alloc] initWithYourObject:[objectArray objectAtIndex:indexPath.row]];
[self presentModalViewController:vc animated:YES];
[vc release];
This could be adapted pretty easily to allow you to pass in any type of object or value (such as a row number if you still want to do that).
Add an instance variable to your view controller and declare a property corresponding to it, so after you alloc, init it, set it like subcontroller.foo = Blah Blah.
I have a table view controller with multiple UISwitch controls in them. I set the delegate to the table view controller with the same action for all switches. I need to be able to determine what switch was changed, so I create an array of strings that contains the name of each switch. The indexes in the array will be put in the tag property of each UISwitch.
However, I'm ready using the tag property for something else, namely to find the right control in the cell in cellForRowAtIndexPath with viewWithTag! (There are several things I need to set within each cell.)
So, am I thinking along the right lines here? I feel I'm rather limited in how I find out exactly which UISwitch changed its value, so I can do something useful with it.
I fixed this by subclassing UISwitch like so:
#interface NamedUISwitch : UISwitch {
NSString *name;
}
It seems elegant (no index arrays required) and the tag property is free to do whatever it wants.
I read that you have to be careful with subclassing in Objective-C, though...
I have written a UISwitch subclass with a block based hander for value change control events which can help when trying to track which switch's value has changed. Ideally, we could do something similar with composition rather than subclassing, but this works well for my needs.
https://gist.github.com/3958325
You can use it like this:
ZUISwitch *mySwitch = [ZUISwitch alloc] init];
[mySwitch onValueChange:^(UISwitch *uiSwitch) {
if (uiSwitch.on) {
// do something
} else {
// do something else
}
}];
You can also use it from a XIB file, by dragging a switch onto your view, and then changing its class to ZUISwitch
You are close in your approach. What I have done in similar situations is create separate UITableViewCell subclasses, set the tag of the UISwitch to be the index.row of the index path, and only use that UITableViewCell subclass in a specific section of the table view. This allows you to use the tag of the cell to uniquely determine what cell has the event without maintaining a separate index list (as it sounds like you are doing).
Because the cell type is unique, you can than easily access the other elements of the cell by creating methods/properties on the UITableViewCell Subclass.
For example:
#interface TableViewToggleCell : UITableViewCell {
IBOutlet UILabel *toggleNameLabel;
IBOutlet UILabel *detailedTextLabel;
IBOutlet UISwitch *toggle;
NSNumber *value;
id owner;
}
#property (nonatomic, retain) UILabel *toggleNameLabel;
#property (nonatomic, retain) UILabel *detailedTextLabel;
#property (nonatomic, retain) UISwitch *toggle;
#property (nonatomic, retain) id owner;
-(void) setLable:(NSString*)aString;
-(void) setValue:(NSNumber*)aNum;
-(NSNumber*)value;
-(void) setTagOnToggle:(NSInteger)aTag;
-(IBAction)toggleValue:(id)sender;
#end
In:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
// ... prior iniitalization code for creating cell is assumed
toggleCell.owner = self;
[toggleCell setLable:#"some string value"];
[toggleCell setTagOnToggle:indexPath.row];
toggleCell.owner = self;
return toggleCell;
//... handle cell set up for other cell types as needed
}
Owner is the delegate for the cell and can then be used to initiate actions in your controller. Make sure you connect your UISwitch to the toggleValue Action, so that you can initiate actions in the delegate when the UISwitch changes state:
-(IBAction)toggleValue:(id)sender;
{
BOOL oldValue = [value boolValue];
[value release];
value = [[NSNumber numberWithBool:!oldValue] retain];
[owner performSelector:#selector(someAction:) withObject:toggle];
}
By passing the UISwitch with the method call, you can then access the index path for the cell. You could also bypass the use of the tag property by explicitly having an ivar to store the NSIndexPath of the cell and then passing the whole cell with the method call.
I realize I'm about three years late to the party but I've developed a solution without subclassing that I think is preferable (and simpler). I'm working with the exact same scenario as Thaurin's described scenario.
- (void)toggleSwitch:(id) sender
{
// declare the switch by its type based on the sender element
UISwitch *switchIsPressed = (UISwitch *)sender;
// get the indexPath of the cell containing the switch
NSIndexPath *indexPath = [self indexPathForCellContainingView:switchIsPressed];
// look up the value of the item that is referenced by the switch - this
// is from my datasource for the table view
NSString *elementId = [dataSourceArray objectAtIndex:indexPath.row];
}
Then you want to declare the method shown above, indexPathForCellContainingView. This is a seemingly needless method because it would appear at first glance that all you have to do is identify the switch's superview but there is a difference between the superviews of ios7 and earlier versions, so this handles all:
- (NSIndexPath *)indexPathForCellContainingView:(UIView *)view {
while (view != nil) {
if ([view isKindOfClass:[UITableViewCell class]]) {
return [self.myTableView indexPathForCell:(UITableViewCell *)view];
} else {
view = [view superview];
}
}
return nil;
}