UA-17470720-3

Jump to content


Photo
- - - - -

Prevent detail view from being editable


  • Please log in to reply
6 replies to this topic

#1 Laeger

Laeger

    Experienced Member

  • STV 5.0 Pro
  • PipPipPipPip
  • 59 posts
Reputation: 6
Good

Posted 25 November 2015 - 09:36 AM

Hello,

I'm learning interface builder with STV and am running into a few problems (previously used STV by code rather than the IB option).

 

I have a tableView with an SCArrayOfObjectsSection.  When the user selects a cell I want to be able to push a detail view but I do not want that detail view to be editable.  To accomplish this I thought I could select the SCArrayOfObjectsSection in IB and uncheck "Allow Edit Detail View".  Unfortunately when I do that, the section will no longer allow any of the cells to be selected (and thus will not push a detail view).

 

To work around I have attempted to override the navigationBarType to be SCNavigationBarTypeDoneLeft.  Unfortunately this still allows the individual cells to be selected and edited.  So then I set the data definition's requireEditingModeToEditPropertyValues to YES and this now works.  

 

My first question is if the checkbox "Allow Edit Detail View" should perhaps be renamed, or else is there a bug with the implementation?

 

Second question: is there a way to show the standard navigation "back" button rather than the "Done" on the left?



#2 wizgod

wizgod

    I'm what you guys call a User

  • STV 5.0 Pro
  • PipPipPipPipPipPipPip
  • 575 posts
  • LocationThe Grid
Reputation: 149
Popular

Posted 25 November 2015 - 12:49 PM

Greetings Program!

 

What I have done in the past is to disable the cells:

 

// You could also use cellActions.detailModelConfigured.
self.tableViewModel.sectionActions.detailModelConfigured = ^(SCTableViewSection *section, SCTableViewModel *detailModel, NSIndexPath *indexPath)
{
	detailModel.cellActions.willConfigure = ^(SCTableViewCell *cell, NSIndexPath *indexPath)
	{
		cell.enabled = NO;
	};
};

 

For your second question, the SCNavigationBarType doesn't have a Back button combination so you'd need to replace the button.

 

Here's Tarek's answer for custom buttons on the detail viewcontroller of a property: http://sensiblecocoa...uttons/?p=12359

 

To do it on the first detail view controller, just use the tableViewModel.detailViewController:

 

SCTableViewController *detailViewController = (SCTableViewController *)self.tableViewModel.detailViewController;

detailViewController.navigationBarType = SCNavigationBarTypeDoneLeftCancelRight;

id buttonTaget = detailViewController.doneButton.target;
SEL backAction = detailViewController.doneButton.action;
SEL cancelAction = detailViewController.cancelButton.action;

UIBarButtonItem *customBackButton = [[UIBarButtonItem alloc] initWithTitle:@"Back" style:UIBarButtonItemStylePlain target:buttonTaget action:backAction];
detailViewController.navigationItem.leftBarButtonItem = customBackButton;

UIBarButtonItem *customCancelButton = [[UIBarButtonItem alloc] initWithTitle:@"Cancel" style:UIBarButtonItemStylePlain target:buttonTaget action:cancelAction];
detailViewController.navigationItem.rightBarButtonItem = customCancelButton;

 

I should note that you can also use the detailModelConfigured or detailModelWillPresent sectionActions as well (instead of using tableViewModel.detailViewController above):

 

self.tableViewModel.sectionActions.detailModelConfigured = ^(SCTableViewSection *section, SCTableViewModel *detailModel, NSIndexPath *indexPath)
{
	SCTableViewController *detailViewController = (SCTableViewController *)detailModel.viewController;

	// Rest of code.
};

 

Wg


Edited by wizgod, 25 November 2015 - 01:30 PM.

  • Tarek likes this

P.S. I love Swift... talk Swift.. Never too old school to learn yet another programming language. LOL! ;-)


#3 Laeger

Laeger

    Experienced Member

  • STV 5.0 Pro
  • PipPipPipPip
  • 59 posts
Reputation: 6
Good

Posted 26 November 2015 - 07:53 AM

Thank you for your help WG.  I can play around with this approach.  However I was really hoping to be able to use the standard UINavigationBar back button, which also provides the built-in "swipe back" functionality that users tend to expect when navigating a hierarchy of this type.  I suppose I can initialize a gesture recognizer and manually implement that behavior but it seems like reinventing the wheel as iOS already provides this.

I'll play around with creating that button and assigning it to backBarButtonItem and see if that accomplishes my goal.

Thanks again!



#4 Tarek

Tarek

    Forum Admin

  • Administrators
  • 3670 posts
Reputation: 452
Popular

Posted 01 December 2015 - 03:05 PM

Hi Laeger:

 

a. Re disabled cells: This is not an implementation bug... STV disables all cells by default, and you could customize what kind of cells you wish to be enabled in case you want to. For instance, the following code will only enable the 'Task Steps' cell in our bundled TasksApp sample:

 

self.tableViewModel.sectionActions.detailModelConfigured = ^(SCTableViewSection *section, SCTableViewModel *detailModel, NSIndexPath *indexPath)
    {
        detailModel.cellActions.willDisplay = ^(SCTableViewCell *detailCell, NSIndexPath *detailIndexPath)
        {
            if([detailCell isKindOfClass:[SCArrayOfObjectsCell class]])
                detailCell.enabled = YES;
        };
    };

 

 

b. To have the regular back button, simply set your desired view controller's navigationBarType to 'SCNavigationBarTypeNone'.

 

Hope this helps.


  • Laeger likes this

#5 Laeger

Laeger

    Experienced Member

  • STV 5.0 Pro
  • PipPipPipPip
  • 59 posts
Reputation: 6
Good

Posted 04 December 2015 - 08:40 AM

Hello Tarek!
Thanks for replying. A couple thoughts:

a. Ok, I see your point here but I still think that at a minimum the label for this option should be changed. The label "Allow Edit Detail View", to me anyway, sounds like it will tell STV to do just that: allow the user to edit the detail view. It is not at all intuitive that STV will suppress access to the detail view altogether if this is not checked. It sounds like this option actually encompasses 2 different options: allow edit detail view AND allow VIEWING detail view. In order to be able to present the detail view, but NOT allow the user to edit that detail view, I had to:
  • Check "Allow Edit Detail View" (again, very counter-intuitive because I actually DON'T want the user to be able to edit)
  • In code, grab a reference to the data definition and set "dataDefinition.requireEditingModeToEditPropertyValues = YES", AND
  • Suppress the display of any edit button, which I accomplish by using your suggestion of setting the VC's bar type to "SCNavigationBarTypeNone".
All of that, just to "lock" a detail view. And as far as I can tell there is no way to do that strictly in IB.

b. This works perfectly! Thank you for this tip. And if I may make a suggestion, you should update the documentation to let others know that using "SCNavigationBarTypeNone" will revert the nav bar buttons to the iOS style. Currently it says "Navigation bar with no buttons"

edit: accidental emoji's

Edited by Laeger, 04 December 2015 - 08:40 AM.


#6 Tarek

Tarek

    Forum Admin

  • Administrators
  • 3670 posts
Reputation: 452
Popular

Posted 05 December 2015 - 09:31 AM

Hey Laeger,

 

a. I see where the confusion is coming from. To us, the option reads: "Allow 'Edit Detail View'", where 'Edit Detail View' refers to the automatically generated detail view controller that you use to edit the object's details. When you disable this option, tapping a cell will not generate any detail views. Perhaps we should think of another name to avoid confusion. The original naming followed the "Allow Delete", "Allow Move", etc. naming convention.

 

b. Will do, thank you very much for the suggestion!


  • Laeger likes this

#7 Laeger

Laeger

    Experienced Member

  • STV 5.0 Pro
  • PipPipPipPip
  • 59 posts
Reputation: 6
Good

Posted 05 December 2015 - 11:05 AM

a. A-ha!  Ok, when broken up like that it *does* make sense!  Maybe just change to be "Allow Detail View"?

 

Thanks,

Larger






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users