NSWorkSpace performFileOperation (a)synchronousness

[Aandi Inston]

 have a requirement to copy files from my Mac OS app. I find:
success=[NSWorkSpace performFileOperation:NSWorkSpaceCopyOperation
 source:nsstring*  // source directory path
 destination:nsstring* // target directory path
 file:nsarray* // nsstring array containing short paths of files or
directories
 tag:nsinteger* // on return, <0 on failure, 0 if sync finish, >0 if async
]
My question relates to asynchronousness (is that a word)? It looks like a
synchronous method as it returns a success or failure. But the documentation
says of the tag variable "a positive integer if the operation was performed
asynchronously. If the value is a positive integer, the value is a tag that
identifies the requested file operation." This confuses me. The examples
I've
seen don't do anything special with the tag.

I may be just missing a document giving a context to this...

Its in the past tense.  If it said "has been started asynchronously" of
course I
would be looking for a method to wait for completion.

So what does "was performed asychronously" mean?
Do I need to care? In what sense was it asynchronous if my API is waiting
for completion? What is the requested file operation identifier and what API
might I use it with? Do I need to release it?

Thanks in advance
___

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: NSWorkSpace performFileOperation (a)synchronousness

[Jens Alfke]

> On Mar 5, 2015, at 2:36 AM, Aandi Inston  wrote:
> 
> My question relates to asynchronousness (is that a word)? It looks like a
> synchronous method as it returns a success or failure. But the documentation
> says of the tag variable "a positive integer if the operation was performed
> asynchronously. If the value is a positive integer, the value is a tag that
> identifies the requested file operation." This confuses me.

Yeah, that’s weird. I’ve never used that method; I just use NSFileManager to 
move/copy files. It’s a simple synchronous API (but of course you can invoke it 
on a background thread.)

—Jens

___

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: NSString stringByAbbreviatingWithTildeInPath and Sandboxing

[Jon Baumgartner]

That bug has gotten no response whatsoever from Apple. Any advice on how to 
proceed? 

> On Feb 4, 2015, at 1:19 PM, Jon Baumgartner  
> wrote:
> 
> I filed a radar: rdar://19716583
> 
> 
> On 1/29/2015 10:55 AM, Kyle Sluder wrote:
>> Even in a sandbox, you can get the user’s home directory using getpwuid(3) 
>> as mentioned in the docs: 
>> https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html
>> 
>> So you could just search through your string and replace occurrences of that 
>> with a tilde, but then you have to worry about encodings and all that muck. 
>> Since there’s no security risk here, it’s reasonable to ask that the 
>> existing API work in a sandbox too.
>> 
>> --Kyle Sluder
>> 
>>> On Jan 29, 2015, at 7:45 AM, Jon Baumgartner 
>>>  wrote:
>>> 
>>> I’m happy to do this, but is this really a bug? I was just thinking there 
>>> might be an alternate way to accomplish this.
>>> 
 On 1/27/2015 4:03 PM, Kyle Sluder wrote:
 Could you please file a Radar describing your use case and share the
 number here?
 
 
> 


___

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: NSString stringByAbbreviatingWithTildeInPath and Sandboxing

[Steve Mills]

On Mar 5, 2015, at 11:30:01, Jon Baumgartner  
wrote:
> 
> That bug has gotten no response whatsoever from Apple. Any advice on how to 
> proceed? 
> 
>> On Feb 4, 2015, at 1:19 PM, Jon Baumgartner  
>> wrote:
>> 
>> I filed a radar: rdar://19716583

You only filed it a month ago. It can take months or even years for a response 
for a bug. Or never.

--
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: NSString stringByAbbreviatingWithTildeInPath and Sandboxing

[Kyle Sluder]

On Thu, Mar 5, 2015, at 11:30 AM, Jon Baumgartner wrote:
> That bug has gotten no response whatsoever from Apple. Any advice on how
> to proceed? 

Patience. :) Internal activity on a bug is rarely reflected to the
external developer, unless they need to verify the fix or provide
additional information.

--Kyle Slude
___

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: NSString stringByAbbreviatingWithTildeInPath and Sandboxing

[Jens Alfke]

> On Mar 5, 2015, at 9:30 AM, Jon Baumgartner  
> wrote:
> 
> That bug has gotten no response whatsoever from Apple. Any advice on how to 
> proceed? 

I wouldn’t expect a response from Apple in ‘only’ a month, except perhaps to 
notify you that it’s a duplicate.

If they do fix the bug, you won’t get a notification until there’s a developer 
release of the OS update so you can test the fix. And since this is a pretty 
minor bug in the grand scheme of things, I wouldn’t expect a fix in a dot-dot 
release. So I’d be guessing the earliest you might hear back about a fix is 
around WWDC (June?) when there’s hypothetically a DP of 10.11.

Until then you’ll need to work around it.

—Jens
___

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: Mac OS X - Inter-Application Communications

[Dave]

Hi,

I’m really confused as it what type of a Application I need to create, from 
reading the "Daemons and Services Programming Guide", it lists:

Login Item.
XPC Service.
Launch Daemon.
Lauch Agent.

On the face of it, a LogIn Item seems to be what i am looking for, but its 
unclear (at least to me) if I can host an XPC service inside this type of 
application?

I noticed in XCode 6, you can create an XPC Service Application, so I created 
one, compiled it and placed the Application file in Startup Items, it seems to 
load up ok, at least I get a terminal window opened pointing to the App’s 
bundle.

I am not intending on Sandboxing this.

> I think as long as the OP is not intending to sandbox then using a 
> LaunchAgent or LoginItem for communicating with a XPC will work but I doubt 
> that using an XPC service will do this.

I’m not sure what you mean by this? 

Cheers
Dave


___

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: Mac OS X - Inter-Application Communications

[Kevin Meaney]

On 5 Mar 2015, at 19:29, Dave  wrote:
> 
> Hi,
> 
> I’m really confused as it what type of a Application I need to create, from 
> reading the "Daemons and Services Programming Guide", it lists:
> 
> Login Item.
> XPC Service.
> Launch Daemon.
> Lauch Agent.
> 
> On the face of it, a LogIn Item seems to be what i am looking for, but its 
> unclear (at least to me) if I can host an XPC service inside this type of 
> application?

I think you might need to provide some more info about your architecture and I 
also think you need to ask your questions in the xpc devforums list: 
https://devforums.apple.com/community/mac/coreos/xpc 
 because if you get an 
answer there it is more likely to be well informed.

I am a little confused by your terminology. I’d call an Application a process 
that a user interacts with (that displays the menu bar) but I wouldn’t call the 
four items listed above Applications.

The four items you listed above can all communicate using the XPC interprocess 
communication protocol but I doubt you’ll be able to install an XPC service 
within any of them and work with that as well. 

> 
> I noticed in XCode 6, you can create an XPC Service Application, so I created 
> one, compiled it and placed the Application file in Startup Items, it seems 
> to load up ok, at least I get a terminal window opened pointing to the App’s 
> bundle.
> 
> I am not intending on Sandboxing this.

I’m fairly certain that the XPC Service requires the Application that contains 
it has to be sandboxed. I would recommend for confirmation that you follow this 
up on the devforums list linked to above.

> 
>> I think as long as the OP is not intending to sandbox then using a 
>> LaunchAgent or LoginItem for communicating with a XPC will work but I doubt 
>> that using an XPC service will do this.
> 
> I’m not sure what you mean by this? 

OP is Original Poster which is you, and later on in that sentence I confused 
things. Let me rephrase:

I think as long as Dave is not intending to sandbox his Application then using 
a LaunchAgent or LoginItem for communicating via XPC will work but I doubt that 
an XPC service will do this.

I struggled badly with this about 20 months ago. The documentation is either 
directed at people writing XPC services in sandboxed applications or written 
for unix developers used to writing daemons and describes how to achieve 
similar goals on OSX using language unix developers would understand, whereas 
writing LaunchAgents or LoginItems fit somewhere between the two. Persistence 
does win out. I wish I could be more certain in my replies but 20 months is 
long enough for certain details to be forgotten.

Kevin

___

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

Bindings in view-based tables

[Shane Stanley]

I'm converting a cell-based table to a view-based table in an old project. It 
contains a pair of buttons, Big and Small, that set a value in user defaults to 
13 or 11. The same value was used via bindings to set the Font Size in the 
table. It worked fine with a cell-based table, but I'm having no luck with 
view-based tables. I presumed the text field in the table cell view was the 
thing to bind, but I've tried just about every combination I can think of.

Should it still work?

-- 
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: Bindings in view-based tables

[Quincey Morris]

On Mar 5, 2015, at 15:20 , Shane Stanley  wrote:
> 
> The same value was used via bindings to set the Font Size in the table.

Er, what exactly was bound to what?

In the view-based version, the text field would typically be bound to 
‘objectValue.something’ (or possibly just to ‘objectValue’ if you took a 
shortcut). In effect, you now have a couple of extra keys in the path to the 
value, and my guess is that it’s no longer KVO compliant.

But it’s just guesswork without knowing where the value is coming from and how 
it’s bound.



___

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: Bindings in view-based tables

[Shane Stanley]

On 6 Mar 2015, at 10:32 am, Quincey Morris 
 wrote:
> 
> Er, what exactly was bound to what?

In the cell-based table, the table's (sole) column's Font Size is bound to the 
shared user defaults controller with a Controller Key of values and Model Key 
Path of tableTextSize.

The buttons are in a radio group, with the Selected Tag bound to the same 
thing. (The two buttons have tags of 11 and 13 respectively).

-- 
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: Bindings in view-based tables

[Quincey Morris]

On Mar 5, 2015, at 16:09 , Shane Stanley  wrote:
> 
> In the cell-based table, the table's (sole) column's Font Size is bound to 
> the shared user defaults controller with a Controller Key of values and Model 
> Key Path of tableTextSize.
> 
> The buttons are in a radio group, with the Selected Tag bound to the same 
> thing. (The two buttons have tags of 11 and 13 respectively).

Oh, I think I understand, finally. Then, yes, I would expect you to be able to 
bind the text field’s Font Size to user defaults.

Are you sure that the user defaults are being maintained properly? Does 
choosing from the radio buttons actually change the user defaults? Is the text 
field size getting set “manually” from somewhere else (perhaps as part of the 
standard behavior of this text field in a standard cell view)? Can you bind a 
freestanding text field, somewhere else in the window, to the user defaults 
font size?




___

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: Bindings in view-based tables

[Shane Stanley]

On 6 Mar 2015, at 11:42 am, Quincey Morris 
 wrote:
> 
> Are you sure that the user defaults are being maintained properly? Does 
> choosing from the radio buttons actually change the user defaults? Is the 
> text field size getting set “manually” from somewhere else (perhaps as part 
> of the standard behavior of this text field in a standard cell view)? Can you 
> bind a freestanding text field, somewhere else in the window, to the user 
> defaults font size?

Binding another text field was the first thing I tried, and yes, it behaves as 
expected. It's only for a text field within a table cell view that it doesn't 
seem to work. Table views and columns also have Font Size bindings, and I've 
tried various permutations, with no luck.

-- 
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: Bindings in view-based tables

[Ken Thomases]

On Mar 5, 2015, at 6:09 PM, Shane Stanley  wrote:

> On 6 Mar 2015, at 10:32 am, Quincey Morris 
>  wrote:
>> 
>> Er, what exactly was bound to what?
> 
> In the cell-based table, the table's (sole) column's Font Size is bound to 
> the shared user defaults controller with a Controller Key of values and Model 
> Key Path of tableTextSize.
> 
> The buttons are in a radio group, with the Selected Tag bound to the same 
> thing. (The two buttons have tags of 11 and 13 respectively).

The views within a table column for a view-based table view are weird.  They 
look like they are just part of NIB that you're working on, but they're really 
in a sub-NIB.  Basically, there's a NIB that's been archived to a data blob and 
stashed in the outer NIB.

This is sort of exposed in the way that -makeViewWithIdentifier:owner: takes an 
owner parameter and makes that object the owner of the cell view NIB.

Often, you don't need to know about this NIB-within-a-NIB business.  However, 
it becomes important when you try to establish connections (target-actions, 
outlets, and bindings) to objects outside of the sub-NIB.  Basically, it's not 
possible.

I _think_ connections to File's Owner are restored when the cell view NIB is 
loaded, but the File's Owner of the sub-NIB may not be the same as the File's 
Owner of the outer NIB.  It may not even be the same class.  It may also work 
to connect to the Application placeholder; haven't checked.

However, it doesn't seem to work to connect to the Shared User Defaults 
Controller, as you've discovered.  The connections are lost if you're lucky.  
If you're unlucky, maybe they end up connected to some other object if object 
IDs in the NIB collide.  (Object IDs as shown in IB seem to be generated in a 
way that makes it unlikely they'll collide, although I don't know if the IDs 
shown in IB and stored in the .xib file are carried over to the compiled .nib.  
Compiling may convert the IDs to sequentially assigned integers starting at 1, 
for example.)

Unfortunately, the solution is clumsy.  You have to use a separate view NIB for 
the table cell view.  That means you can't really design the view-based table 
in the NIB that contains the table view.  The table view is in one NIB and the 
cell views are in other NIBs.

Build a view NIB that contains your cell view.  Set the identifier of the table 
column in the table view NIB and set the identifier of the cell view in the 
cell view NIB to the same value.  You can no longer rely on Xcode setting those 
up to match automatically.

It seems you can't delete the cell view that's under the table column in the 
first NIB.  Or, rather, you can, but Xcode will replace it with a new basic 
cell view the next time you open the NIB.  You can ignore it or, if you're 
paranoid, set its identifier to something that doesn't match the column's 
identifier.

In the cell view NIB, you can bind the text field within the cell view to the 
Shared User Defaults Controller.  This binding will survive, because the object 
that you've connected to really is in the same NIB as the text field, as 
opposed to just looking like it is.

Now, in your table view delegate, you need to add some code.  At some point 
before the first call to the table view's -makeViewWithIdentifier:owner: method 
with your column identifier, you need to load your cell view NIB as an NSNib 
object and pass it to -registerNib:forIdentifier:.  So, something like:

if (!self.registeredNib)
{
NSNib* nib = [[NSNib alloc] initWithNibNamed:@"TableCellView" 
bundle:nil];
[tableView registerNib:nib forIdentifier:@"MyColumn"];
self.registeredNib = YES;
}

You only need to do this once for any given column identifier/cell view NIB 
combination.  Actually, your cell view NIB can contain multiple cell views, 
each with a different identifier.  You can register that one NIB repeatedly, 
with each identifier, and the table view will pick the appropriate top-level 
view out of the NIB based on the view's identifier.

Putting that code in your -tableView:viewForTableColumn:row: just before you 
call -makeViewWithIdentifier:owner:  on the table view is fine, if that's the 
only place you call that.

Hopefully that works for you.  It worked for me in a test app where I had a 
text field outside of the table and one inside a cell view, both bound to the 
same key in the user defaults.  Editing one changed the value in the other, as 
desired.

Regards,
Ken


___

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: Bindings in view-based tables

[Quincey Morris]

On Mar 5, 2015, at 17:06 , Ken Thomases  wrote:
> 
> Unfortunately, the solution is clumsy.  You have to use a separate view NIB 
> for the table cell view.  That means you can't really design the view-based 
> table in the NIB that contains the table view.  The table view is in one NIB 
> and the cell views are in other NIBs.

I was just coming to the conclusion that you described in the rest of your 
response. However, I think there’s an easier workaround. It ought to be fairly 
straightforward to give the object that’s being used as the cell’s 
“objectValue” a KVO-compliant “fontSize" derived property that tracks the user 
defaults value, and to bind the text field font size to that.



___

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: Bindings in view-based tables

[Shane Stanley]

On 6 Mar 2015, at 12:06 pm, Ken Thomases  wrote:
> 
> I _think_ connections to File's Owner are restored when the cell view NIB is 
> loaded, but the File's Owner of the sub-NIB may not be the same as the File's 
> Owner of the outer NIB.  It may not even be the same class.  It may also work 
> to connect to the Application placeholder; haven't checked.
> 
> However, it doesn't seem to work to connect to the Shared User Defaults 
> Controller, as you've discovered.  

So you're saying it's a bug?

> Unfortunately, the solution is clumsy.  You have to use a separate view NIB 
> for the table cell view.  That means you can't really design the view-based 
> table in the NIB that contains the table view.  The table view is in one NIB 
> and the cell views are in other NIBs.
> 

> 
> Hopefully that works for you.

It does, thanks. It certainly makes something that was relatively simple a lot 
more complex.


On 6 Mar 2015, at 12:13 pm, Quincey Morris 
 wrote:

> However, I think there’s an easier workaround. It ought to be fairly 
> straightforward to give the object that’s being used as the cell’s 
> “objectValue” a KVO-compliant “fontSize" derived property that tracks the 
> user defaults value, and to bind the text field font size to that.

Thanks, Quincey. That sounds much easier, but alas I got your email after I'd 
started implementing Ken's suggestion.

-- 
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: Bindings in view-based tables

[Shane Stanley]

On 6 Mar 2015, at 12:06 pm, Ken Thomases  wrote:
> 
> It seems you can't delete the cell view that's under the table column in the 
> first NIB.

It also seems that the row height is based on its height.

-- 
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: Bindings in view-based tables

[Ken Thomases]

On Mar 5, 2015, at 8:15 PM, Shane Stanley  wrote:

> On 6 Mar 2015, at 12:06 pm, Ken Thomases  wrote:
>> 
>> I _think_ connections to File's Owner are restored when the cell view NIB is 
>> loaded, but the File's Owner of the sub-NIB may not be the same as the 
>> File's Owner of the outer NIB.  It may not even be the same class.  It may 
>> also work to connect to the Application placeholder; haven't checked.
>> 
>> However, it doesn't seem to work to connect to the Shared User Defaults 
>> Controller, as you've discovered.  
> 
> So you're saying it's a bug?

I think the bug is that IB hides the existence of the sub-NIB.  If IB presented 
the sub-NIB with all of the usual placeholders and put a Shared User Defaults 
Controller into it when you set a binding on it, etc., that would help make 
this clear.

Also, it's a bug that IB will blithely let you create connections from objects 
in the sub-NIB to objects outside the sub-NIB when those connections won't 
survive to runtime.


>> Hopefully that works for you.
> 
> It does, thanks.

You're welcome.


On Mar 5, 2015, at 9:02 PM, Shane Stanley  wrote:

> On 6 Mar 2015, at 12:06 pm, Ken Thomases  wrote:
>> 
>> It seems you can't delete the cell view that's under the table column in the 
>> first NIB.
> 
> It also seems that the row height is based on its height.

How so?  To my knowledge, Cocoa doesn't yet support determining row height 
automatically based on the height of cell views (presumably determined by auto 
layout).  UIKit has that, but AppKit does not.  And it's not clear to me if it 
makes sense for a table that can have multiple columns, since each column's 
cell view can be different.

You set the table view's row height on the table view itself, on the Size 
inspector.  There is an Automatic mode, but that uses the row size style from 
System Preferences.

I guess I do see that when you first switch from Automatic to Custom, IB uses 
the tallest of the cell views of the table's columns to pick the new default 
value for the row height, but you can just change it from that value.

Anyway, the table view gets its row and cell views from the delegate. It is 
true that -makeViewWithIdentifier:owner: will consult the registered cell view 
NIB for the identifier and, when the table view is loaded from its NIB, the 
mapping of identifiers to NIBs is pre-populated with the cell view sub-NIBs 
embedded in the table view NIB.  But if you modify that mapping early enough, 
the table view should never know anything about the vestigial cell view in its 
NIB.

Regards,
Ken


___

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: Bindings in view-based tables

[Graham Cox]

> On 6 Mar 2015, at 4:25 pm, Ken Thomases  wrote:
> 
>> So you're saying it's a bug?
> 
> I think the bug is that IB hides the existence of the sub-NIB.  If IB 
> presented the sub-NIB with all of the usual placeholders and put a Shared 
> User Defaults Controller into it when you set a binding on it, etc., that 
> would help make this clear.
> 
> Also, it's a bug that IB will blithely let you create connections from 
> objects in the sub-NIB to objects outside the sub-NIB when those connections 
> won't survive to runtime.


I got well and truly confused by all this first time I did anything with 
view-based tables.

The way IB has been "adapted" to handle this architecture is one collosal 
kludge. I wonder if any of us would be happy to release code that bad?

--Graham



___

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: Bindings in view-based tables

[Shane Stanley]

On 6 Mar 2015, at 4:25 pm, Ken Thomases  wrote:

>> So you're saying it's a bug?
> 
> I think the bug is that IB hides the existence of the sub-NIB.  If IB 
> presented the sub-NIB with all of the usual placeholders and put a Shared 
> User Defaults Controller into it when you set a binding on it, etc., that 
> would help make this clear.
> 
> Also, it's a bug that IB will blithely let you create connections from 
> objects in the sub-NIB to objects outside the sub-NIB when those connections 
> won't survive to runtime.

That's what I was getting at, I guess. There's no indication that one is doing 
anything wrong (other than failure to work, of course).
> 
>> It also seems that the row height is based on its height.
> 
> How so?  To my knowledge, Cocoa doesn't yet support determining row height 
> automatically based on the height of cell views (presumably determined by 
> auto layout).  UIKit has that, but AppKit does not.  And it's not clear to me 
> if it makes sense for a table that can have multiple columns, since each 
> column's cell view can be different.
> 
> You set the table view's row height on the table view itself, on the Size 
> inspector.  There is an Automatic mode, but that uses the row size style from 
> System Preferences.

I had it set to automatic mode, and the unused table cell view was set to X 
points high. Each time I changed its height and ran it again, the height of the 
rows changed accordingly. No big deal because I needed to implement the 
delegate method anyway, but I was surprised.

-- 
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