Re: length of file from NSFileHandle?

> 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

Re: length of file from NSFileHandle?

> 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

length of file from NSFileHandle?

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.

Re: length of file from NSFileHandle?

> 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

Re: Mysterious crash with NSTableView

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

Re: length of file from NSFileHandle?

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

Re: Mysterious crash with NSTableView

> 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

Re: Mysterious crash with NSTableView

> 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

Re: runModalForWindow() doesn't re-activate former window upon return

> 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

Re: runModalForWindow() doesn't re-activate former window upon return

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

Re: Mysterious crash with NSTableView

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

Re: Mysterious crash with NSTableView

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

Re: Mysterious crash with NSTableView

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

Re: Mysterious crash with NSTableView

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

Mysterious crash with NSTableView

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

Re: Mysterious crash with NSTableView

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

Re: runModalForWindow() doesn't re-activate former window upon return

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

Re: runModalForWindow() doesn't re-activate former window upon return

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

Re: runModalForWindow() doesn't re-activate former window upon return

> 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

Re: Mysterious crash with NSTableView

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

Re: Mysterious crash with NSTableView

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,

Re: Mysterious crash with NSTableView

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

Re: Mysterious crash with NSTableView

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

Re: Mysterious crash with NSTableView

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