Re: Mysterious crash with NSTableView

[Doug Hill]

> On Aug 26, 2016, at 9:20 PM, Jeff Szuhay  wrote:
> 
> 
>>> On Aug 26, 2016, at 8:44 PM, Sandor Szatmari  
>>> wrote:
>>> 
>>> 
>>> However, in your case I wonder what the static analyzer in Xcode tells you 
>>> about the bug you see?
>> 
>> I believe Andreas mentioned he does not use Xcode as his product is cross 
>> platform, but this is a good suggestion.
> 
> Any why not? 
> 
> Sure, build it without Xcode, but couldn’t you create a shell project where 
> the product doesn’t really matter, then build and use the tools in Xcode?

I believe you can also invoke the analyzer via the command-line tools.
___

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: Mysterious crash with NSTableView

[Jeff Szuhay]

> On Aug 26, 2016, at 8:44 PM, Sandor Szatmari  
> wrote:
> 
>> 
>> However, in your case I wonder what the static analyzer in Xcode tells you 
>> about the bug you see?
> 
> I believe Andreas mentioned he does not use Xcode as his product is cross 
> platform, but this is a good suggestion.

Any why not? 

Sure, build it without Xcode, but couldn’t you create a shell project where the 
product doesn’t really matter, then build and use the tools in Xcode?

___

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: length of file from NSFileHandle?

[Jeff Szuhay]

> On Aug 26, 2016, at 8:19 PM, Graham Cox  wrote:
> Apparently a simple task, but no obvious API for it: getting the length 
> (size) of a file I have a NSFileHandle for. This class has no -length 
> property, so how can I get it?
> 
> I need to know because I have a requirement to create a backup copy of a file 
> once it exceeds a certain size. This backup is created when I first open the 
> file as a NSFileHandle. I can read the content of the file and find out the 
> size that way, but I’d rather not first read it into memory if I’m just going 
> to create my backup copy and then start over with an empty file - reading it 
> all in just to find the length seems a bit wrong, is all.

Seems reasonable enough.

You may need to use the Unix C api,  fstat() defined in .
See the man page for 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: Mysterious crash with NSTableView

[Sandor Szatmari]

Doug,

> On Aug 26, 2016, at 17:58, Doug Hill  wrote:
> 
>> On Aug 26, 2016, at 1:52 PM, Jens Alfke  wrote:
>> 
>>> On Aug 26, 2016, at 8:42 AM, Andreas Falkenhahn  
>>> wrote:
>>> 
>>> But once again, I think it's a crime that there is no mentioning of this in 
>>> the class
>>> documentation of "setDelegate" and "setDatasource" :(
>> 
>> In the Xcode 8 docs for NSTableView.dataSource, it does:
>>"Note that in versions of OS X prior to v10.12, the table view did not 
>> retain the data source in a managed memory environment."
>> 
>> I’m sure I won’t be the first person to suggest that you switch to ARC. If 
>> you find ref-counting confusing, ARC will help you a lot.
>> 
>> —Jens
> 
> As usual, Jens speaks truthfully about using ARC.
> 
> However, in your case I wonder what the static analyzer in Xcode tells you 
> about the bug you see?

I believe Andreas mentioned he does not use Xcode as his product is cross 
platform, but this is a good suggestion.

Andreas,

If you add a static analysis phase to your Makefile does it help highlight 
these issues?

http://clang-analyzer.llvm.org

Sandor Szatmari

> Can it catch the bug? In manual ref-counting, the analyzer has saved my skin 
> more than once. :)
> 
> Doug
> ___
> 
> 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/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@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: length of file from NSFileHandle?

[Ken Thomases]

On Aug 26, 2016, at 10:19 PM, Graham Cox  wrote:
> 
> Apparently a simple task, but no obvious API for it: getting the length 
> (size) of a file I have a NSFileHandle for. This class has no -length 
> property, so how can I get it?

The reason it has no length property is because not all NSFileHandles have the 
concept of a length.  For example, a file handle associated with a pipe or 
socket.

For an on-disk file, you can seekToEndOfFile and get offsetInFile to determine 
the file length.  If you need to not perturb the file position, you can record 
the original offsetInFile and then seekToFileOffset:origOffset to restore it 
after measuring the length.

Matthew Emerson's suggestion of using fstat() with the fileDescriptor is also 
reasonable.

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: length of file from NSFileHandle?

[R. Matthew Emerson]

> On Aug 26, 2016, at 11:32 PM, R. Matthew Emerson  
> wrote:
> 
> 
>> On Aug 26, 2016, at 11:19 PM, Graham Cox  wrote:
>> 
>> Hi all,
>> 
>> Apparently a simple task, but no obvious API for it: getting the length 
>> (size) of a file I have a NSFileHandle for. This class has no -length 
>> property, so how can I get it?
>> 
>> I need to know because I have a requirement to create a backup copy of a 
>> file once it exceeds a certain size. This backup is created when I first 
>> open the file as a NSFileHandle. I can read the content of the file and find 
>> out the size that way, but I’d rather not first read it into memory if I’m 
>> just going to create my backup copy and then start over with an empty file - 
>> reading it all in just to find the length seems a bit wrong, is all.
> 
> One way would be to read the NSFileHandle's fileDescriptor property, and then 
> use stat(2), e.g., like so:
> 
> #include 
> #include 
> 
> #include 
> 
> int main(int argc, char *argv[])
> {
>struct stat buf;
>stat("/etc/passwd", );
>printf("size = %lld\n", buf.st_size);
> }

Argh, I meant fstat(2).

#include 
#include 
#include 

#include 

int main(int argc, char *argv[])
{
struct stat buf;
int fd = open("/etc/passwd", O_RDONLY);

fstat(fd, );
printf("size = %lld\n", buf.st_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: length of file from NSFileHandle?

[R. Matthew Emerson]

> On Aug 26, 2016, at 11:19 PM, Graham Cox  wrote:
> 
> Hi all,
> 
> Apparently a simple task, but no obvious API for it: getting the length 
> (size) of a file I have a NSFileHandle for. This class has no -length 
> property, so how can I get it?
> 
> I need to know because I have a requirement to create a backup copy of a file 
> once it exceeds a certain size. This backup is created when I first open the 
> file as a NSFileHandle. I can read the content of the file and find out the 
> size that way, but I’d rather not first read it into memory if I’m just going 
> to create my backup copy and then start over with an empty file - reading it 
> all in just to find the length seems a bit wrong, is all.

One way would be to read the NSFileHandle's fileDescriptor property, and then 
use stat(2), e.g., like so:

#include 
#include 

#include 

int main(int argc, char *argv[])
{
struct stat buf;
stat("/etc/passwd", );
printf("size = %lld\n", buf.st_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

length of file from NSFileHandle?

[Graham Cox]

Hi all,

Apparently a simple task, but no obvious API for it: getting the length (size) 
of a file I have a NSFileHandle for. This class has no -length property, so how 
can I get it?

I need to know because I have a requirement to create a backup copy of a file 
once it exceeds a certain size. This backup is created when I first open the 
file as a NSFileHandle. I can read the content of the file and find out the 
size that way, but I’d rather not first read it into memory if I’m just going 
to create my backup copy and then start over with an empty file - reading it 
all in just to find the length seems a bit wrong, is all.

—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: Mysterious crash with NSTableView

[Doug Hill]

On Aug 26, 2016, at 1:52 PM, Jens Alfke  wrote:
> 
> On Aug 26, 2016, at 8:42 AM, Andreas Falkenhahn  
> wrote:
>> 
>> But once again, I think it's a crime that there is no mentioning of this in 
>> the class
>> documentation of "setDelegate" and "setDatasource" :( 
> 
> In the Xcode 8 docs for NSTableView.dataSource, it does:
>   "Note that in versions of OS X prior to v10.12, the table view did not 
> retain the data source in a managed memory environment."
> 
> I’m sure I won’t be the first person to suggest that you switch to ARC. If 
> you find ref-counting confusing, ARC will help you a lot.
> 
> —Jens

As usual, Jens speaks truthfully about using ARC.

However, in your case I wonder what the static analyzer in Xcode tells you 
about the bug you see? Can it catch the bug? In manual ref-counting, the 
analyzer has saved my skin more than once. :)

Doug
___

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: Mysterious crash with NSTableView

[Jens Alfke]

> On Aug 26, 2016, at 8:42 AM, Andreas Falkenhahn  
> wrote:
> 
> But once again, I think it's a crime that there is no mentioning of this in 
> the class
> documentation of "setDelegate" and "setDatasource" :( 

In the Xcode 8 docs for NSTableView.dataSource, it does:
"Note that in versions of OS X prior to v10.12, the table view did not 
retain the data source in a managed memory environment."

I’m sure I won’t be the first person to suggest that you switch to ARC. If you 
find ref-counting confusing, ARC will help you a lot.

—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: Mysterious crash with NSTableView

[Quincey Morris]

On Aug 26, 2016, at 11:39 , Andreas Falkenhahn  wrote:
> 
> From a logical point of view I'd expect this call
> 
>[win release];
> 
> to kill off the NSTableView and its associates completely. So I'd consider
> it safe to  …

Welcome to the latest episode of “It’s Deja Vu All Over Again!”. We used to 
have these sorts of discussions on this list all the time, until ARC, at which 
point they pretty much stopped.

Reasoning about retain counts is extremely difficult, and common sense will 
lead you astray.

In particular, you’re confusing “release” with “deallocate”, which is something 
we all did back in the days when we didn’t use ARC. The concept of releasing 
the “last” reference to an object, the “one” that’s “keeping it alive” is going 
to get you in all sorts of trouble.

>  I mean, who the heck is referencing those delegates after the call to [win 
> release]?

A careful reading of the documentation will tell you that windows are managed 
by a window manager process that’s separate from yours. It will keep windows 
alive until it gets a chance to remove them from its own data structures, which 
may not happen until the next iteration of your run loop.

But even if that weren’t true, the assumption that the table view object won’t 
outlive the window object is invalid.

___

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: Mysterious crash with NSTableView

[Andreas Falkenhahn]

On 26.08.2016 at 20:12 Kyle Sluder wrote:

> On Fri, Aug 26, 2016, at 12:25 PM, Gary L. Wade wrote:
>> I'm talking about exchanging release for autorelease on your list
>> delegate, which happens after runModal finishes. Since you now do an
>> orderOut, your table view should not need its data source/delegate, so it
>> should be safe keeping them set and using an autorelease, but clearing
>> them is the safest.

> Neither autorelease nor release on its own is sufficient here; Andreas
> should clear out his delegates. 

So should I also clear the button delegates or is NSTableView an exception
here?

Side note:

What I find really weird in this whole thing is the fact that it crashed
although the delegates are clearly released *after* the window. I wouldn't
be surprised to get crashes if I released the delegates *before* the window.
That would be natural behaviour but from a logical point of view it's really
weird to see it crash with the delegate/data source being released *after*
the window, i.e. when one would expect NSTableView to have been fully 
deallocated
already.

From a logical point of view I'd expect this call

[win release];

to kill off the NSTableView and its associates completely. So I'd consider
it safe to release the delegate/data source after that, but apparently they
need to be cleared out before. It's good to know but from a logical point
of view I still think it's weird. I mean, who the heck is referencing those
delegates after the call to [win release]? Everything should be gone by
that call but there's probably some advanced wizardry going on that I'm
unaware of.

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Mysterious crash with NSTableView

[Kyle Sluder]

On Fri, Aug 26, 2016, at 12:25 PM, Gary L. Wade wrote:
> I'm talking about exchanging release for autorelease on your list
> delegate, which happens after runModal finishes. Since you now do an
> orderOut, your table view should not need its data source/delegate, so it
> should be safe keeping them set and using an autorelease, but clearing
> them is the safest.

Neither autorelease nor release on its own is sufficient here; Andreas
should clear out his delegates. This is true either in ARC or non-ARC,
whether the delegate property is declared `unsafe_unretained` (née
`assign`) or `weak`.

You don’t know when an object will be deallocated. While it would be
unexpected (and arguably an error) for NSTableView to hand off its
delegate to something that will take a long-lived strong +1 reference to
it, it is perfectly legal for the delegate to wind up in the autorelease
pool for an indefinite period of time. Delegates are most likely not
written to handle being called in that limbo state where they’re still
alive and assigned to the delegate property, but the object that created
them has disavowed them by releasing its last strong reference to them.

`weak` prevents retain cycles. It does not ensure program correctness.

> 
> This kind of exercise in understanding the MRC rules is precisely why ARC
> was created. If you need to use MRC, you probably should do what lots of
> others did and draw lots of pictures in timeframes with tally counts on
> objects to understand what happens when. If you go with ARC, this
> clearing should happen for you—I'm pretty sure the data source and
> delegate are weak, but I don't have the headers in front of me right now.

Automatic clearing of zeroing weak references is dependent on the
*implementor* being compiled with ARC. Non-ARC clients will still see
another object’s zeroing weak ref go to nil when the last strong ref to
the referent is released.

Here’s some sample code:

/* WeakRefHolder.h
 * This file is transcluded twice: once with ARC enabled, once with ARC
 disabled.
 */
#import 

@interface WeakRefHolder : NSObject

@property(weak) id weakRef;

@end
/* WeakRefHolder.m
 * clang -c -o WeakRefHolder.o -fobjc-arc WeakRefHolder.m
 */

#if !__has_feature(objc_arc)
#error WeakRefHolder implementation must be compiled with ARC
#endif

#import "WeakRefHolder.h"

@implementation WeakRefHolder
// Automatically synthesize implementation of .weakRef property
@end

/* main.m
 * Compile: clang -o main -framework Foundation -fno-objc-arc main.m
 WeakRefHolder.o
 */

#if __has_feature(objc_arc)
#error Main file should not be compiled with ARC
#endif

#import "WeakRefHolder.h"
#import 

@interface SquealOnDealloc : NSObject
@end

@implementation SquealOnDealloc
- (void)dealloc {
printf("<%p> deallocating!\n", self);
[super dealloc];
}
@end

int main(int argc, char **argv)
{
WeakRefHolder *holder = [[WeakRefHolder alloc] init];
id referent;
@autoreleasepool {
printf(">> Pushing autorelease pool\n");
referent = [[SquealOnDealloc alloc] init];
printf("Assigning <%p> to .weakRef property\n",
referent);
holder.weakRef = [referent autorelease];
printf("<< Popping autorelease pool\n");
}

printf(".weakRef = %p\n", holder.weakRef);
return 0;
}

--Kyle Sluder

> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/
> 
> > On Aug 26, 2016, at 9:38 AM, Andreas Falkenhahn  
> > wrote:
> > 
> >> On 26.08.2016 at 17:52 Gary L. Wade wrote:
> >> 
> >> You would not see this if you hid or removed the table view first
> >> since it would not need its data source or delegate then. Try going
> >> with ARC or at least use autorelease on your delegate/data source.
> > 
> > I'm not using autorelease on the delegate/data source on purpose because
> > AFAIU autoreleased objects are (potentially) killed whenever the application
> > is in an event loop and this is the case with runModalForWindow(). AFAIU
> > if I used autorelease on the delegate/data source then both would be
> > killed in the run loop started by runModalForWindow() because both 
> > setDelegate()
> > and setDatasource() don't retain. So using autorelease doesn't make sense
> > to me here. Is this right or did I get anything wrong here?
> > 
> > -- 
> > Best regards,
> > Andreas Falkenhahnmailto:andr...@falkenhahn.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: Mysterious crash with NSTableView

[Gary L. Wade]

I'm talking about exchanging release for autorelease on your list delegate, 
which happens after runModal finishes. Since you now do an orderOut, your table 
view should not need its data source/delegate, so it should be safe keeping 
them set and using an autorelease, but clearing them is the safest.

This kind of exercise in understanding the MRC rules is precisely why ARC was 
created. If you need to use MRC, you probably should do what lots of others did 
and draw lots of pictures in timeframes with tally counts on objects to 
understand what happens when. If you go with ARC, this clearing should happen 
for you—I'm pretty sure the data source and delegate are weak, but I don't have 
the headers in front of me right now.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Aug 26, 2016, at 9:38 AM, Andreas Falkenhahn  
> wrote:
> 
>> On 26.08.2016 at 17:52 Gary L. Wade wrote:
>> 
>> You would not see this if you hid or removed the table view first
>> since it would not need its data source or delegate then. Try going
>> with ARC or at least use autorelease on your delegate/data source.
> 
> I'm not using autorelease on the delegate/data source on purpose because
> AFAIU autoreleased objects are (potentially) killed whenever the application
> is in an event loop and this is the case with runModalForWindow(). AFAIU
> if I used autorelease on the delegate/data source then both would be
> killed in the run loop started by runModalForWindow() because both 
> setDelegate()
> and setDatasource() don't retain. So using autorelease doesn't make sense
> to me here. Is this right or did I get anything wrong here?
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.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: Mysterious crash with NSTableView

[Andreas Falkenhahn]

On 26.08.2016 at 17:52 Gary L. Wade wrote:

> You would not see this if you hid or removed the table view first
> since it would not need its data source or delegate then. Try going
> with ARC or at least use autorelease on your delegate/data source.

I'm not using autorelease on the delegate/data source on purpose because
AFAIU autoreleased objects are (potentially) killed whenever the application
is in an event loop and this is the case with runModalForWindow(). AFAIU
if I used autorelease on the delegate/data source then both would be
killed in the run loop started by runModalForWindow() because both setDelegate()
and setDatasource() don't retain. So using autorelease doesn't make sense
to me here. Is this right or did I get anything wrong here?

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Mysterious crash with NSTableView

[Gary L. Wade]

You would not see this if you hid or removed the table view first since it 
would not need its data source or delegate then. Try going with ARC or at least 
use autorelease on your delegate/data source.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Aug 26, 2016, at 8:42 AM, Andreas Falkenhahn  
> wrote:
> 
>> On 26.08.2016 at 17:35 Gary L. Wade wrote:
>> 
>> Try clearing your table view's data source and delegate before
>> releasing their object. It appears the pointer gets reassigned to an
>> NSRectSet before your table view completely goes away but after its delegate 
>> and data source have.
> 
> Great, that solves it. Thanks a lot!
> 
> But once again, I think it's a crime that there is no mentioning of this in 
> the class
> documentation of "setDelegate" and "setDatasource" :( 
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.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: runModalForWindow() doesn't re-activate former window upon return

[Andreas Falkenhahn]

On 26.08.2016 at 17:24 Keary Suska wrote:


>> On Aug 26, 2016, at 8:36 AM, Andreas Falkenhahn  
>> wrote:

>> Thanks, that's what I was looking for. I just wish such essential 
>> information wouldn't
>> be hidden in the accompanying documentation. This should really be mentioned 
>> in the
>> documentation of runModalForWindow() or stopModal()/stopModalWithCode() 
>> IMHO. Here
>> it is again:

>> "It is important to call orderOut: when finished with your dialog, or it is 
>> not removed
>> from the screen."

> Apple used to cross reference the documentation, but apparently do
> not anymore. May be worth filing a radar on the subject.

I think I'll do so. The class documentation really leaves a lot to be desired.
I think the DRY paradigm shouldn't be applied to documentation :) It doesn't 
hurt to
include such essential information in both documents, class and programming 
reference.

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Mysterious crash with NSTableView

[Andreas Falkenhahn]

On 26.08.2016 at 17:35 Gary L. Wade wrote:

> Try clearing your table view's data source and delegate before
> releasing their object. It appears the pointer gets reassigned to an
> NSRectSet before your table view completely goes away but after its delegate 
> and data source have.

Great, that solves it. Thanks a lot!

But once again, I think it's a crime that there is no mentioning of this in the 
class
documentation of "setDelegate" and "setDatasource" :( 

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Mysterious crash with NSTableView

[Gary L. Wade]

Try clearing your table view's data source and delegate before releasing their 
object. It appears the pointer gets reassigned to an NSRectSet before your 
table view completely goes away but after its delegate and data source have.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Aug 26, 2016, at 8:15 AM, Andreas Falkenhahn  
> wrote:
> 
> Does anybody have an idea why the following code causes a "Segmentation 
> fault" and thus
> an immediate program termination? Interestingly, the code runs just fine and 
> the
> NSTableView appears correctly and is functional. The "Segmentation fault" 
> occurs when
> buttonPressed() is left and control returns to the main run loop. Thus, I 
> suspect that
> the error is probably related to autoreleasing, e.g. releasing a resource 
> twice or
> something. But I don't really see anything that's wrong with my code. 
> Sometimes I also
> get this message instead of the segmentation fault:
> 
>   [NSRectSet tableView:objectValueForTableColumn:row:]:unrecognized 
> selector sent to instance 0x100153060
> 
> But most of the time it just crashes with a segmentation fault. The code 
> itself is
> really simple and straightforward, here it is:
> 
> - (void)buttonPressed
> {
>NSRect rect = NSMakeRect(100, 100, 320 + 2 * 20, 78 + 200 + 20);
>
>NSWindow *win = [[NSWindow alloc] initWithContentRect:rect 
> styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered defer:NO];
> 
>id listDelegate = [[MyListDelegate alloc] init];
> 
>NSScrollView *scrollview = [[NSScrollView alloc] 
> initWithFrame:NSMakeRect(20, 52, rect.size.width - 2 * 20, 200)];
>NSTableView *tableview = [[NSTableView alloc] initWithFrame:NSMakeRect(0, 
> 0, rect.size.width - 2 * 20 - 16, 200)];
>NSTableColumn *column = [[NSTableColumn alloc] 
> initWithIdentifier:@"Column"];
>
>[tableview addTableColumn:column];
>[tableview setDelegate:listDelegate];
>[tableview setDataSource:listDelegate];
>[scrollview setDocumentView:tableview];
>[[win contentView] addSubview:scrollview];
>[scrollview release];
>[tableview release];
>[column release];
> 
>id buttonDelegateOK = [[MyButtonDelegate alloc] init];
>NSButton *ok = [[NSButton alloc] initWithFrame:NSMakeRect(rect.size.width 
> - 82 - 14, 12, 82, 32)];
>[ok setTitle:@"OK"];
>[ok setButtonType:NSMomentaryPushInButton];
>[ok setBezelStyle:NSRoundedBezelStyle];
>[ok setKeyEquivalent:@"\r"];
>[ok setTarget:buttonDelegateOK];
>[ok setAction:@selector(buttonPressed)];
>[[win contentView] addSubview:ok];
>[ok release];
>
>[NSApp runModalForWindow:win];
>
>[win orderOut:nil];
>[win release];
>
>[listDelegate release];
>[buttonDelegateOK release];
> } 
> 
> ---
> 
> The list delegate is also minimal and looks like this:
> 
> @interface MyListDelegate : NSObject
> @end
> 
> @implementation MyListDelegate
> - (int)numberOfRowsInTableView:(NSTableView *)_tableView
> {
>return 3;
> }
> 
> - (id)tableView:(NSTableView *)_tableView 
> objectValueForTableColumn:(NSTableColumn *) tableColumn row:(int)row
> {
>return @"Foobar";
> }
> @end
> 
> ---
> 
> I've already spent several hours trying to find out why this particular code 
> results
> in a "Segmentation fault" but I just don't see it.
> 
> Can anybody help? Thanks in advance!
> 
> Full minimal demo program is attached for reference.
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.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: runModalForWindow() doesn't re-activate former window upon return

[Keary Suska]

> On Aug 26, 2016, at 8:36 AM, Andreas Falkenhahn  
> wrote:
> 
> Thanks, that's what I was looking for. I just wish such essential information 
> wouldn't
> be hidden in the accompanying documentation. This should really be mentioned 
> in the
> documentation of runModalForWindow() or stopModal()/stopModalWithCode() IMHO. 
> Here
> it is again:
> 
> "It is important to call orderOut: when finished with your dialog, or it is 
> not removed
> from the screen."

Apple used to cross reference the documentation, but apparently do not anymore. 
May be worth filing a radar on the subject. In any case, you will miss large 
chunks of necessary information if you only refer to the class documentation. 
The “programming topics” docs are required reading.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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

Mysterious crash with NSTableView

[Andreas Falkenhahn]

Does anybody have an idea why the following code causes a "Segmentation fault" 
and thus
an immediate program termination? Interestingly, the code runs just fine and the
NSTableView appears correctly and is functional. The "Segmentation fault" 
occurs when
buttonPressed() is left and control returns to the main run loop. Thus, I 
suspect that
the error is probably related to autoreleasing, e.g. releasing a resource twice 
or
something. But I don't really see anything that's wrong with my code. Sometimes 
I also
get this message instead of the segmentation fault:

   [NSRectSet tableView:objectValueForTableColumn:row:]:unrecognized 
selector sent to instance 0x100153060

But most of the time it just crashes with a segmentation fault. The code itself 
is
really simple and straightforward, here it is:

- (void)buttonPressed
{   
NSRect rect = NSMakeRect(100, 100, 320 + 2 * 20, 78 + 200 + 20);

NSWindow *win = [[NSWindow alloc] initWithContentRect:rect 
styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered defer:NO];

id listDelegate = [[MyListDelegate alloc] init];

NSScrollView *scrollview = [[NSScrollView alloc] 
initWithFrame:NSMakeRect(20, 52, rect.size.width - 2 * 20, 200)];
NSTableView *tableview = [[NSTableView alloc] 
initWithFrame:NSMakeRect(0, 0, rect.size.width - 2 * 20 - 16, 200)];
NSTableColumn *column = [[NSTableColumn alloc] 
initWithIdentifier:@"Column"];

[tableview addTableColumn:column];
[tableview setDelegate:listDelegate];
[tableview setDataSource:listDelegate];
[scrollview setDocumentView:tableview];
[[win contentView] addSubview:scrollview];
[scrollview release];
[tableview release];
[column release];

id buttonDelegateOK = [[MyButtonDelegate alloc] init];
NSButton *ok = [[NSButton alloc] 
initWithFrame:NSMakeRect(rect.size.width - 82 - 14, 12, 82, 32)];
[ok setTitle:@"OK"];
[ok setButtonType:NSMomentaryPushInButton];
[ok setBezelStyle:NSRoundedBezelStyle];
[ok setKeyEquivalent:@"\r"];
[ok setTarget:buttonDelegateOK];
[ok setAction:@selector(buttonPressed)];
[[win contentView] addSubview:ok];
[ok release];

[NSApp runModalForWindow:win];

[win orderOut:nil];
[win release];

[listDelegate release];
[buttonDelegateOK release];
} 

---

The list delegate is also minimal and looks like this:

@interface MyListDelegate : NSObject
@end

@implementation MyListDelegate
- (int)numberOfRowsInTableView:(NSTableView *)_tableView
{
return 3;
}

- (id)tableView:(NSTableView *)_tableView 
objectValueForTableColumn:(NSTableColumn *) tableColumn row:(int)row
{
return @"Foobar";
}   
@end

---

I've already spent several hours trying to find out why this particular code 
results
in a "Segmentation fault" but I just don't see it.

Can anybody help? Thanks in advance!

Full minimal demo program is attached for reference.

-- 
Best regards,
 Andreas Falkenhahn  mailto:andr...@falkenhahn.com

main.m
Description: Binary data
___

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: runModalForWindow() doesn't re-activate former window upon return

[Andreas Falkenhahn]

On 26.08.2016 at 16:19 Keary Suska wrote:


>> On Aug 25, 2016, at 12:51 PM, Andreas Falkenhahn  
>> wrote:

>>> What happens if you add -orderOut: to the button action method?

>> Ok, this solves the problem. But still, shouldn't this be handled 
>> automatically
>> by runModalForWindow()? Why does it activate a window that doesn't belong to
>> my application when it returns? That doesn't look reasonable to me at all...

> Apparently not:

> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Sheets/Tasks/UsingAppModalDialogs.html

Thanks, that's what I was looking for. I just wish such essential information 
wouldn't
be hidden in the accompanying documentation. This should really be mentioned in 
the
documentation of runModalForWindow() or stopModal()/stopModalWithCode() IMHO. 
Here
it is again:

"It is important to call orderOut: when finished with your dialog, or it is not 
removed
from the screen."

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: runModalForWindow() doesn't re-activate former window upon return

[Andreas Falkenhahn]

On 25.08.2016 at 22:36 Kyle Sluder wrote:

> -mainWindow and -keyWindow don’t return pointers to windows outside of
> your application. (How could they? Other applications have their own
> address spaces.) They either return pointers to windows in your app
> (which might be windows owned by the framework), or they return nil.

Oops, right, the window that they return after runModalForWindow() has
finished is the window which was passed to runModalForWindow().

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: runModalForWindow() doesn't re-activate former window upon return

[Keary Suska]

> On Aug 25, 2016, at 12:51 PM, Andreas Falkenhahn  
> wrote:
> 
>> What happens if you add -orderOut: to the button action method?
> 
> Ok, this solves the problem. But still, shouldn't this be handled 
> automatically
> by runModalForWindow()? Why does it activate a window that doesn't belong to
> my application when it returns? That doesn't look reasonable to me at all...

Apparently not:

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Sheets/Tasks/UsingAppModalDialogs.html

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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