how to slim down view controllers?

[Juan Felipe Alvarez Saldarriaga]

Hi,

How you guys slim down your view controllers?, sometimes you end up 
implementing a lot of protocols in your view controller, so there’s a lot of 
code inside the controller itself. Reading about how to slim down view 
controllers in iOS I found that a common way is to move DataSources 
(http://www.objc.io/issue-1/lighter-view-controllers.html) to other class, but 
what about other delegates?, or if you create views by code?. First, I think 
about move each delegate to a NSObject class, so I try this:

self.locationManager.delegate = 
[[FRRYPetDescriptionViewControllerLocationDelegate alloc] init];

Then I ask in IRC and somebody suggest categories, so this is what I got so far:

// FRRYPetDescriptionViewController.h
@interface FRRYPetDescriptionViewController : UIViewController

@property (nonatomic) CLLocationManager *locationManager;

@property (nonatomic) TPKeyboardAvoidingScrollView *scrollView;
@property (nonatomic) UIView *contentView;

@end

// FRRYPetDescriptionViewController+Protocols.h
@interface FRRYPetDescriptionViewController (Protocols) 

@end

// FRRYPetDescriptionViewController+UIAdditions.h
@interface FRRYPetDescriptionViewController (UIAdditions)

- (void)createScrollView;
- (void)createContentView;

@end

// FRRYPetDescriptionViewController+Callbacks.h
@interface FRRYPetDescriptionViewController (Callbacks)

@end

// FRRYPetDescriptionViewController+LocationAdditions.h
@interface FRRYPetDescriptionViewController (LocationAdditions)

@end

This makes me think, what about “private” methods?, do I need to declare all 
properties in the view controller header file?. What you guys think about this 
approach or there’s some common pattern to follow to not end with a fat 
controller?.

Thank you.

--
Juan Felipe Alvarez Saldarriaga
http://juan.im
Twitter: @nebiros
Google Talk: nebi...@gmail.com
Skype: jfasaldarriaga



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: how to slim down view controllers?

[Michael Crawford]

I need to slim down mine as well.

Read the book "Refactoring" by Martin Fowler.

I'm not real sure how to proceed with mine; it grew organically.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, Apr 1, 2015 at 5:59 AM, Juan Felipe Alvarez Saldarriaga
 wrote:
> Hi,
>
> How you guys slim down your view controllers?, sometimes you end up 
> implementing a lot of protocols in your view controller, so there's a lot of 
> code inside the controller itself. Reading about how to slim down view 
> controllers in iOS I found that a common way is to move DataSources 
> (http://www.objc.io/issue-1/lighter-view-controllers.html) to other class, 
> but what about other delegates?, or if you create views by code?. First, I 
> think about move each delegate to a NSObject class, so I try this:
>
> self.locationManager.delegate = 
> [[FRRYPetDescriptionViewControllerLocationDelegate alloc] init];
>
> Then I ask in IRC and somebody suggest categories, so this is what I got so 
> far:
>
> // FRRYPetDescriptionViewController.h
> @interface FRRYPetDescriptionViewController : UIViewController
>
> @property (nonatomic) CLLocationManager *locationManager;
>
> @property (nonatomic) TPKeyboardAvoidingScrollView *scrollView;
> @property (nonatomic) UIView *contentView;
>
> @end
>
> // FRRYPetDescriptionViewController+Protocols.h
> @interface FRRYPetDescriptionViewController (Protocols)  UIActionSheetDelegate, MFMailComposeViewControllerDelegate, 
> UIGestureRecognizerDelegate, MKMapViewDelegate, 
> UIViewControllerTransitioningDelegate, CLLocationManagerDelegate>
>
> @end
>
> // FRRYPetDescriptionViewController+UIAdditions.h
> @interface FRRYPetDescriptionViewController (UIAdditions)
>
> - (void)createScrollView;
> - (void)createContentView;
>
> @end
>
> // FRRYPetDescriptionViewController+Callbacks.h
> @interface FRRYPetDescriptionViewController (Callbacks)
>
> @end
>
> // FRRYPetDescriptionViewController+LocationAdditions.h
> @interface FRRYPetDescriptionViewController (LocationAdditions)
>
> @end
>
> This makes me think, what about "private" methods?, do I need to declare all 
> properties in the view controller header file?. What you guys think about 
> this approach or there's some common pattern to follow to not end with a fat 
> controller?.
>
> Thank you.
>
> --
> Juan Felipe Alvarez Saldarriaga
> http://juan.im
> Twitter: @nebiros
> Google Talk: nebi...@gmail.com
> Skype: jfasaldarriaga
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: how to slim down view controllers?

[Alex Zavatone]

There was a great article on this just this on objc.io a while ago.

Certainly worth a few reads before it sinks in.

I'm a big fan of not lumping everything together in one class, but moving 
certain responsibilities in to other classes and moving the appropriate code 
there.

What's odd to me is that Apple preaches MVC, but then when we have the view 
controller class, all to often the delegate is lumped into the same class, 
fostering code bloat and sorta going against compartmentalization of tasks (at 
least in my book it seems strange).

Here's the link to the article I'm thinking about.

http://www.objc.io/issue-1/lighter-view-controllers.html

Hope this helps.  Cheers,
Alex Zavatone
 

On Apr 1, 2015, at 8:59 AM, Juan Felipe Alvarez Saldarriaga wrote:

> Hi,
> 
> How you guys slim down your view controllers?, sometimes you end up 
> implementing a lot of protocols in your view controller, so there’s a lot of 
> code inside the controller itself. Reading about how to slim down view 
> controllers in iOS I found that a common way is to move DataSources 
> (http://www.objc.io/issue-1/lighter-view-controllers.html) to other class, 
> but what about other delegates?, or if you create views by code?. First, I 
> think about move each delegate to a NSObject class, so I try this:
> 
> self.locationManager.delegate = 
> [[FRRYPetDescriptionViewControllerLocationDelegate alloc] init];
> 
> Then I ask in IRC and somebody suggest categories, so this is what I got so 
> far:
> 
> // FRRYPetDescriptionViewController.h
> @interface FRRYPetDescriptionViewController : UIViewController
> 
> @property (nonatomic) CLLocationManager *locationManager;
> 
> @property (nonatomic) TPKeyboardAvoidingScrollView *scrollView;
> @property (nonatomic) UIView *contentView;
> 
> @end
> 
> // FRRYPetDescriptionViewController+Protocols.h
> @interface FRRYPetDescriptionViewController (Protocols)  UIActionSheetDelegate, MFMailComposeViewControllerDelegate, 
> UIGestureRecognizerDelegate, MKMapViewDelegate, 
> UIViewControllerTransitioningDelegate, CLLocationManagerDelegate>
> 
> @end
> 
> // FRRYPetDescriptionViewController+UIAdditions.h
> @interface FRRYPetDescriptionViewController (UIAdditions)
> 
> - (void)createScrollView;
> - (void)createContentView;
> 
> @end
> 
> // FRRYPetDescriptionViewController+Callbacks.h
> @interface FRRYPetDescriptionViewController (Callbacks)
> 
> @end
> 
> // FRRYPetDescriptionViewController+LocationAdditions.h
> @interface FRRYPetDescriptionViewController (LocationAdditions)
> 
> @end
> 
> This makes me think, what about “private” methods?, do I need to declare all 
> properties in the view controller header file?. What you guys think about 
> this approach or there’s some common pattern to follow to not end with a fat 
> controller?.
> 
> Thank you.
> 
> --
> Juan Felipe Alvarez Saldarriaga
> http://juan.im
> Twitter: @nebiros
> Google Talk: nebi...@gmail.com
> Skype: jfasaldarriaga
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSCheckbox right click in an NSOutlineView

[Alex Kac]

I have an NSCheckbox in a view based NSOutlineView. I want to support
Control-click for the right click menu when a user control-clicks on the
cell. Right click works perfectly already per the standard NSOutlineView.
However because the NSCheckbox is eating the click, it doesn't do a right
click menu when you control-click.

https://www.dropbox.com/s/zjt5heg0mgotatd/Screenshot%202015-04-01%2008.34.26.png?dl=0

I've been trying different things, but via SO it seems like people subclass
NSButton to check for the control click:

- (void) mouseDown:(NSEvent *)theEvent

{

if ((theEvent.modifierFlags & NSControlKeyMask) == NSControlKeyMask)

{

// [[self nextResponder] rightMouseDown:theEvent];

}

else

[super mouseDown:theEvent];

}


However I now need to figure out how to get to the parent where a
rightMouseDown brings up the menu. I'm sure this can't be all that uncommon
- so what's the best way to handle this?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOpenPanel accessoryView clicks must hit pixels to work

[Karl Moskowski]

> On Mar 30, 2015, at 11:24 AM, sjmi...@mac.com wrote:
> 
> Yes. Great googly moogly, that's it! I made a test project; clicking white 
> space in the checkbox label works. I turned on sandboxing for that project, 
> and it no longer works. Hello, radar://20346986.

A few months back, we ran into a similar problem with accessory views in 
sandboxed apps, though it was with NSSavePanel. The Open & Cancel buttons 
weren’t clickable, but the keyboard shortcuts (esc & enter) worked.


Karl Moskowski 



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: how to slim down view controllers?

[Luther Baker]

> What's odd to me is that Apple preaches MVC, but then when we have the view 
> controller class, all to often the delegate is lumped into the same class,

Whoa, you're blaming Apple for this?

How is MVC, MVP or Apple forcing you to do this?

> fostering code bloat and sorta going against compartmentalization of tasks 
> (at least in my book it seems strange).

??? are you suggesting that how your code ends up is somehow not your 
responsibility?

I've seen a lot of complaints levied against Apple and product behaviors  but 
I've never seen someone complaining that Apple made them "do it" (put a 
delegate somewhere).

Massive View Controllers is a well-known anti-pattern. For one thing, it 
suggests you're not refactoring enough. Development 101 stuff. It is not 
anyone's fault but your own if you are bloating your view controllers. You 
still need to *think*


> Here's the link to the article I'm thinking about.
> 
> http://www.objc.io/issue-1/lighter-view-controllers.html
> 

Consider reading all the articles in issue 13. http://www.objc.io/issue-13

Take a look at reactive cocoa ... https://github.com/ReactiveCocoa/ReactiveCocoa

Dig into Martin Fowler's articles 
http://martinfowler.com/eaaDev/PresentationModel.html

And by all means, pick your fights with Apple wisely lest you blame them for 
everything. Development is hard work. At some point you've got to reflect on 
your own skills.

> Hope this helps.  Cheers,
> Alex Zavatone
> 

-Luther

> 
>> On Apr 1, 2015, at 8:59 AM, Juan Felipe Alvarez Saldarriaga wrote:
>> 
>> Hi,
>> 
>> How you guys slim down your view controllers?, sometimes you end up 
>> implementing a lot of protocols in your view controller, so there’s a lot of 
>> code inside the controller itself. Reading about how to slim down view 
>> controllers in iOS I found that a common way is to move DataSources 
>> (http://www.objc.io/issue-1/lighter-view-controllers.html) to other class, 
>> but what about other delegates?, or if you create views by code?. First, I 
>> think about move each delegate to a NSObject class, so I try this:
>> 
>> self.locationManager.delegate = 
>> [[FRRYPetDescriptionViewControllerLocationDelegate alloc] init];
>> 
>> Then I ask in IRC and somebody suggest categories, so this is what I got so 
>> far:
>> 
>> // FRRYPetDescriptionViewController.h
>> @interface FRRYPetDescriptionViewController : UIViewController
>> 
>> @property (nonatomic) CLLocationManager *locationManager;
>> 
>> @property (nonatomic) TPKeyboardAvoidingScrollView *scrollView;
>> @property (nonatomic) UIView *contentView;
>> 
>> @end
>> 
>> // FRRYPetDescriptionViewController+Protocols.h
>> @interface FRRYPetDescriptionViewController (Protocols) > UIActionSheetDelegate, MFMailComposeViewControllerDelegate, 
>> UIGestureRecognizerDelegate, MKMapViewDelegate, 
>> UIViewControllerTransitioningDelegate, CLLocationManagerDelegate>
>> 
>> @end
>> 
>> // FRRYPetDescriptionViewController+UIAdditions.h
>> @interface FRRYPetDescriptionViewController (UIAdditions)
>> 
>> - (void)createScrollView;
>> - (void)createContentView;
>> 
>> @end
>> 
>> // FRRYPetDescriptionViewController+Callbacks.h
>> @interface FRRYPetDescriptionViewController (Callbacks)
>> 
>> @end
>> 
>> // FRRYPetDescriptionViewController+LocationAdditions.h
>> @interface FRRYPetDescriptionViewController (LocationAdditions)
>> 
>> @end
>> 
>> This makes me think, what about “private” methods?, do I need to declare all 
>> properties in the view controller header file?. What you guys think about 
>> this approach or there’s some common pattern to follow to not end with a fat 
>> controller?.
>> 
>> Thank you.
>> 
>> --
>> Juan Felipe Alvarez Saldarriaga
>> http://juan.im
>> Twitter: @nebiros
>> Google Talk: nebi...@gmail.com
>> Skype: jfasaldarriaga
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com
> 
> This email sent to lutherba...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...

Re: NSOpenPanel accessoryView clicks must hit pixels to work

[Steve Mills]

On Apr 1, 2015, at 09:49:29, Karl Moskowski  wrote:
> 
> A few months back, we ran into a similar problem with accessory views in 
> sandboxed apps, though it was with NSSavePanel. The Open & Cancel buttons 
> weren’t clickable, but the keyboard shortcuts (esc & enter) worked.

Well, it's been reported now by me at least, so hopefully they'll get on it 
ASAP, because there's nothing more embarrassing than a "feature" to keep users' 
files and memory safe that has the side affect of breaking basic UI.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOpenPanel accessoryView clicks must hit pixels to work

[Karl Moskowski]

> On Apr 1, 2015, at 12:01 PM, Steve Mills  wrote:
> 
> On Apr 1, 2015, at 09:49:29, Karl Moskowski  wrote:
>> 
>> A few months back, we ran into a similar problem with accessory views in 
>> sandboxed apps, though it was with NSSavePanel. The Open & Cancel buttons 
>> weren’t clickable, but the keyboard shortcuts (esc & enter) worked.
> 
> Well, it's been reported now by me at least, so hopefully they'll get on it 
> ASAP, because there's nothing more embarrassing than a "feature" to keep 
> users' files and memory safe that has the side affect of breaking basic UI.

I reported ours too. In our case, it was the MAS reviewer that found the 
problem and rejected the app because “apps exhibiting bugs will be rejected”.
Even though it was an OS X bug, we removed the feature because we didn’t have 
time to go through another rejection cycle. Also, the UX was sub-optimal.


Karl Moskowski 



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOpenPanel accessoryView clicks must hit pixels to work

[Kyle Sluder]

On Mon, Mar 30, 2015, at 11:00 AM, Steve Mills wrote:
> On Mar 30, 2015, at 11:37:46, Mike Abdullah 
> wrote:
> > 
> > Slightly less ugly idea, how about filling the background of your accessory 
> > view with something like 1% alpha? Would that be enough to direct clicks to 
> > the right place, without being visible to the human eye?
> 
> 1% didn't work. I had to work my way up to 5% before it was deemed
> clickable. I ended up with [NSColor colorWithWhite:0.91 alpha:0.05],
> which exactly matches this particular background.

… on your current setup. Depending on whether the CPU or GPU is used for
compositing the open panel's contents and/or your own views, and what
color profile is assigned to the screen on which these windows believe
themselves to be hosted, you may wind up with accumulated
off-by-least-significant-bit errors in the final color components.

I'd recommend enclosing all your controls in an NSBox or other
opaque-enough superview.

> Hello, radar://20346986.

Thanks for filing.

--Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOpenPanel accessoryView clicks must hit pixels to work

[Steve Mills]

On Apr 1, 2015, at 11:14:43, Kyle Sluder  wrote:
> 
> … on your current setup. Depending on whether the CPU or GPU is used for
> compositing the open panel's contents and/or your own views, and what
> color profile is assigned to the screen on which these windows believe
> themselves to be hosted, you may wind up with accumulated
> off-by-least-significant-bit errors in the final color components.

Right. Like I said, it's a dirty hack to fix Apple's dirtier hack. I'm not 
shipping with this hack.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Number formatter errors

[Sean McBride]

On Wed, 1 Apr 2015 13:33:15 +1100, Shane Stanley said:

>I start a new project, then drag a text field with attached number
>formatter into the window. I set the formatter's minimum to 0 and
>maximum to 1. I run, then enter 3 and hit return. I get a beep, but no
>error dialog. Yet I have existing projects where a dialog appears. I'm
>sure I'm missing something simple, but it's escaping me. Any hints?

Do you have 'validates immediately' on?

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

View-based tableview and outlets to NSFormatters

[Sean McBride]

Hi all,

I swear this was discussed, but can't find it in the archives...

It seems Interface Builder won't let me connect the 'formatter' outlet of a 
textfield that's within a view-based tableview to a top-level formatter that 
lives in the same nib.  It complains:

 "Unsupported Configuration: Outlet 'formatter' of 'Text Field Cell - Table 
View Cell' is connected to 'Date Formatter,' an invalid destination (Objects 
inside view based table views may only be connected to the table view's 
delegate.)"

I often have top-level formatters in my nibs, ex: a number formatter configured 
to show exactly 2 decimal places.  Then I have a bunch of textfields (some in 
tables, some not) that connect to it.

How can I do this with view-based tables?

It seems I could:

1) drag a formatter in IB to each table cell.  Downsides: I risk their settings 
becoming out-of-sync with each other.  Also, formatters are supposedly 
expensive to create.

2) implement the tableView:viewForTableColumn:row: delegate method to set the 
formatter.  Downsides: need to write code; most of my tables use bindings and I 
often don't have a delegate; need to assign column identifiers and switch on 
them.

Is there no better way?

Thanks,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Help Bundle Trouble...

[Alex Zavatone]

Is it showing up as part of the Copy Bundle Resources within your Target App's 
Build Phases build settings?

Within Copy Bundle Resources, I have 212 items that are being copied into my 
iOS project's bundle.  Anything and everything that's part of the project that 
is going in to the bundle is in there.



On Mar 27, 2015, at 10:39 PM, Peters, Brandon wrote:

> Jerry,
> 
> I found the .app bundle in the derived data folder. The help is not making it 
> into the resources folder for the bundle.
> 
>> On Mar 27, 2015, at 10:20 PM, Peters, Brandon  wrote:
>> 
>> Jerry,
>> 
>> In my project folder I am not seeing my .app bundle (this is embarrassing).
>> 
>>> On Mar 27, 2015, at 10:06 PM, Jerry Krinock  wrote:
>>> 
>>> 
 On 2015 Mar 27, at 16:26, Peters, Brandon  wrote:
 
 I copied the .help bundle into my project by right-clicking Supporting 
 Files > Add Files to , etc. Yet it seems my application 
 still cannot find the content. Any pointers from experience?
>>> 
>>> 1.  Look inside your product’s Contents/Resources and see if your 
>>> ArnoldTransformer.help bundle made it in to there.
>>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/bap04e%40my.fsu.edu
>> 
>> This email sent to bap...@my.fsu.edu
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

TextView : Shifting all text down to make room for a subview

[Seth Willits]

I have a text view where I added a subview at the top, and I want all of the 
text to be below this subview. You can think of it like having a horizontal 
ruler above the text view, but instead I want this view (it's not a ruler) _in_ 
the text view so that it scrolls with the text.

Here are two different strategies, neither of which I can quite get to work...



--

The simplest thing I could think of was to subclass NSTextView and override 
textContainerOrigin to push the Y value down a little. My little accessory view 
then becomes a direct subview of the text view. The first line of text is 
exactly in the right spot so it seems like it'll work perfectly, but if the 
text fills the entire text view, it won't start scrolling until the height of 
the *text* is greater than the height of the entire text *view*, which means 
that however many points I've shifted the text down by, that many points of 
text is cut off at the bottom of the text view before scrolling is allowed.

In other words, if the text view's could hold 10 lines of text, I shift all the 
text down by 1 line, and put 10 lines of text into the text view, I expect to 
see 9 lines and have to scroll to see the 10th, but instead, the scrollview 
doesn't allow scrolling at all, so that 10th line is completely inaccessible. 
If I add an 11th line, then I can scroll to the 10th line, but not the 11th, 
etc.


So whatever mechanism is calculating how much scrolling is needed, doesn't 
respect the text container's origin as returned by NSTextView 
-textContainerOrigin? I can't seem to figure out how to "fix" that.


---


A completely different approach would be to affect typesetting where the line 
fragments "flow" around this view, by just making sure the line fragments don't 
start until below it. I implemented this strategy with a custom text container, 
and it appears to work at first, but if the text is long enough that scrolling 
is required, then the first line fragment is just at 0,0 in the text container 
regardless of the fact that I explicitly told it to not be...


@implementation MyTextContainer

- (BOOL)isSimpleRectangularTextContainer
{
return NO;
}

- (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect 
sweepDirection:(NSLineSweepDirection)sweepDirection 
movementDirection:(NSLineMovementDirection)movementDirection 
remainingRect:(NSRectPointer)remainingRect
{
if (proposedRect.origin.y + proposedRect.size.height > 
self.containerSize.height) {
return [super lineFragmentRectForProposedRect:proposedRect 
sweepDirection:sweepDirection movementDirection:movementDirection 
remainingRect:remainingRect];
}


if (!NSIntersectsRect(NSMakeRect(0, 0, self.containerSize.width, 26), 
proposedRect)) {
return [super lineFragmentRectForProposedRect:proposedRect 
sweepDirection:sweepDirection movementDirection:movementDirection 
remainingRect:remainingRect];
}


NSRect reproposedRect;
reproposedRect.origin.x = proposedRect.origin.x;
reproposedRect.size.height = proposedRect.size.height;
reproposedRect.size.width = self.containerSize.width;
reproposedRect.origin.y = 26;
reproposedRect = [self lineFragmentRectForProposedRect:reproposedRect 
sweepDirection:sweepDirection movementDirection:movementDirection 
remainingRect:remainingRect];
return reproposedRect;
}


@end




So there are two different strategies, and I've hit a sizable enough wall that 
with both that I'm kinda stumped. 

Anyone had any luck doing something like this?



--
Seth Willits




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Display edit menu for non-editable UITextField?

[Steve Mills]

Is there a way to make a UITextField non-editable, but selectable and display 
the edit menu? I have a field that gets its value elsewhere, and it would be 
handy if the user could tap on it, which would show the edit menu with Copy 
enabled. I've tried… well, lots of stuff. Or at least prevent the keyboard from 
showing?

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: TextView : Shifting all text down to make room for a subview

[Jonathan Hull]

Have you tried just setting the textContentInset to make room for your subview?

I used that approach a couple of days ago to add room for a subview at the 
bottom of a UITextView and it worked like a charm. Worth a shot here too.

Thanks,
Jon


> On Apr 1, 2015, at 2:19 PM, Seth Willits  wrote:
> 
> I have a text view where I added a subview at the top, and I want all of the 
> text to be below this subview. You can think of it like having a horizontal 
> ruler above the text view, but instead I want this view (it's not a ruler) 
> _in_ the text view so that it scrolls with the text.
> 
> Here are two different strategies, neither of which I can quite get to work...
> 
> 
> 
> --
> 
> The simplest thing I could think of was to subclass NSTextView and override 
> textContainerOrigin to push the Y value down a little. My little accessory 
> view then becomes a direct subview of the text view. The first line of text 
> is exactly in the right spot so it seems like it'll work perfectly, but if 
> the text fills the entire text view, it won't start scrolling until the 
> height of the *text* is greater than the height of the entire text *view*, 
> which means that however many points I've shifted the text down by, that many 
> points of text is cut off at the bottom of the text view before scrolling is 
> allowed.
> 
> In other words, if the text view's could hold 10 lines of text, I shift all 
> the text down by 1 line, and put 10 lines of text into the text view, I 
> expect to see 9 lines and have to scroll to see the 10th, but instead, the 
> scrollview doesn't allow scrolling at all, so that 10th line is completely 
> inaccessible. If I add an 11th line, then I can scroll to the 10th line, but 
> not the 11th, etc.
> 
> 
> So whatever mechanism is calculating how much scrolling is needed, doesn't 
> respect the text container's origin as returned by NSTextView 
> -textContainerOrigin? I can't seem to figure out how to "fix" that.
> 
> 
> ---
> 
> 
> A completely different approach would be to affect typesetting where the line 
> fragments "flow" around this view, by just making sure the line fragments 
> don't start until below it. I implemented this strategy with a custom text 
> container, and it appears to work at first, but if the text is long enough 
> that scrolling is required, then the first line fragment is just at 0,0 in 
> the text container regardless of the fact that I explicitly told it to not 
> be...
> 
> 
> @implementation MyTextContainer
> 
> - (BOOL)isSimpleRectangularTextContainer
> {
>   return NO;
> }
> 
> - (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect 
> sweepDirection:(NSLineSweepDirection)sweepDirection 
> movementDirection:(NSLineMovementDirection)movementDirection 
> remainingRect:(NSRectPointer)remainingRect
> {
>   if (proposedRect.origin.y + proposedRect.size.height > 
> self.containerSize.height) {
>   return [super lineFragmentRectForProposedRect:proposedRect 
> sweepDirection:sweepDirection movementDirection:movementDirection 
> remainingRect:remainingRect];
>   }
>   
>   
>   if (!NSIntersectsRect(NSMakeRect(0, 0, self.containerSize.width, 26), 
> proposedRect)) {
>   return [super lineFragmentRectForProposedRect:proposedRect 
> sweepDirection:sweepDirection movementDirection:movementDirection 
> remainingRect:remainingRect];
>   }
>   
>   
>   NSRect reproposedRect;
>   reproposedRect.origin.x = proposedRect.origin.x;
>   reproposedRect.size.height = proposedRect.size.height;
>   reproposedRect.size.width = self.containerSize.width;
>   reproposedRect.origin.y = 26;
>   reproposedRect = [self lineFragmentRectForProposedRect:reproposedRect 
> sweepDirection:sweepDirection movementDirection:movementDirection 
> remainingRect:remainingRect];
>   return reproposedRect;
> }
> 
> 
> @end
> 
> 
> 
> 
> So there are two different strategies, and I've hit a sizable enough wall 
> that with both that I'm kinda stumped. 
> 
> Anyone had any luck doing something like this?
> 
> 
> 
> --
> Seth Willits
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jhull%40gbis.com
> 
> This email sent to jh...@gbis.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Number formatter errors

[Shane Stanley]

On 2 Apr 2015, at 3:41 am, Sean McBride  wrote:
> 
> Do you have 'validates immediately' on?

No -- I didn't actually have a binding at that stage, which is why I wasn't 
seeing the result I expected. I'd missed the fact that bindings were the driver 
of the error dialog.


-- 
Shane Stanley 



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: View-based tableview and outlets to NSFormatters

[Shane Stanley]

On 2 Apr 2015, at 5:05 am, Sean McBride  wrote:
> 
> I swear this was discussed, but can't find it in the archives...
> 
> It seems Interface Builder won't let me connect the 'formatter' outlet of a 
> textfield that's within a view-based tableview to a top-level formatter that 
> lives in the same nib.

I suspect this is what you are looking for, if not what you want to hear: 


-- 
Shane Stanley 



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: TextView : Shifting all text down to make room for a subview

[Seth Willits]

> On Apr 1, 2015, at 3:00 PM, Jonathan Hull  wrote:
> 
> Have you tried just setting the textContentInset to make room for your 
> subview?


The inset by definition affects both the top *and* bottom. I only want the top.


--
Seth Willits

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Swift: How to determine if a Character represents whitespace?

[Charles Jenkins]

Given this code:

let someCharacter = str[str.endIndex.predecessor()]

How can I determine if someCharacter is whitespace?

— 

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Charles Srstka]

On Apr 1, 2015, at 8:14 PM, Charles Jenkins  wrote:
> 
> Given this code:
> 
> let someCharacter = str[str.endIndex.predecessor()]
> 
> How can I determine if someCharacter is whitespace?

import Foundation

func isChar(char: Character, inSet set: NSCharacterSet) -> Bool {
// this function is from an answer on StackOverflow:
// 
http://stackoverflow.com/questions/27697508/nscharacterset-characterismember-with-swifts-character-type
var found = true
for ch in String(char).utf16 {
if !set.characterIsMember(ch) { found = false }
}
return found
}

let str = "foo "
let chr = str[str.endIndex.predecessor()]

let isWhitespace = isChar(chr, inSet: 
NSCharacterSet.whitespaceAndNewlineCharacterSet()) // true

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Charles Jenkins]

Thank you very much. :-) I had been trying to figure out how to use 
NSCharacterSet, but I didn’t know the bit about converting to UTF-16 string 
first.    

— 

Charles

On April 1, 2015 at 9:52:47 PM, Charles Srstka (cocoa...@charlessoft.com) wrote:

On Apr 1, 2015, at 8:14 PM, Charles Jenkins  wrote:  
>  
> Given this code:  
>  
> let someCharacter = str[str.endIndex.predecessor()]  
>  
> How can I determine if someCharacter is whitespace?  

import Foundation  

func isChar(char: Character, inSet set: NSCharacterSet) -> Bool {  
// this function is from an answer on StackOverflow:  
// 
http://stackoverflow.com/questions/27697508/nscharacterset-characterismember-with-swifts-character-type
  
var found = true  
for ch in String(char).utf16 {  
if !set.characterIsMember(ch) { found = false }  
}  
return found  
}  

let str = "foo "  
let chr = str[str.endIndex.predecessor()]  

let isWhitespace = isChar(chr, inSet: 
NSCharacterSet.whitespaceAndNewlineCharacterSet()) // true  

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Quincey Morris]

On Apr 1, 2015, at 21:17 , Charles Jenkins  wrote:
> 
> for ch in String(char).utf16 {  
> if !set.characterIsMember(ch) { found = false }  
> }  

Except that this code can’t possibly be right, in general. 

1. A ‘unichar’ is a UTF-16 code value, but it’s not a Unicode code point. Some 
UTF-16 code values have no meaning as “characters” by themselves. I think you 
could mitigate this problem by using ‘longCharacterIsMember’, which takes a 
UTF-32 code value instead (and enumerating the string as UTF-32 instead of 
UTF-16).

2. A Swift ‘Character’ isn’t a Unicode code point, but rather a grapheme. That 
is, it might be a sequence of code points (and I mean code points, not code 
values). It might be such a sequence either because there’s no way of 
representing the grapheme by a single code point, or because it’s a composed 
character made up of a base code points and some combining characters.

In this case, you can’t validly test the individual code points for membership 
of the character set.

I’m not sure, but I suspect the underlying obstacle is that NSCharacterSet is 
at best a set of code points, and you cannot test a grapheme for membership of 
a set of code points.

In your particular application, if it’s true that all** Unicode whitespace 
characters are represented as a single code point (via a single UTF-32 code 
value), or a single UTF-16 code value, then you can get away with one of the 
above solutions. Otherwise you’re going to need a more complex solution, that 
doesn’t involve NSCharacterSet at all.



** Or at least the ones you happen to care about, but ignoring the others may 
be a perilous proceeding.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com