I have an app with a button.
I start the app, then put the iPhone to sleep.
I wake the phone up and press the button repeatedly, until something happens.
There is an NSLog() in applicationWillEnterForeground: and in the action method
of the button.
The time difference between these two is 1.1 ..
As far as I know (and I use this in my application) if you use the
NSUndoManager prepareWithInvocationTarget:
the proxy that wraps the NSInvocation retains the target. Thus using a
[[undoManager prepareWithInovationTarget:myObject] remove] call should
ensure the object lives as long as the und
On Jan 29, 2014, at 8:30 AM, Matthew LeRoy wrote:
> I *think* the right approach here is to not delete/dealloc the model objects
> when their corresponding records are removed/deleted, but instead just remove
> the objects from the collection of “live” objects and hold onto them
> somewhere els
I’m wondering if someone can provide some guidance or best practices on how I
might preserve actions on the undo/redo stack when the target of those actions
is deleted?
For example, say I have an application that allows me to add and remove records
to and from a list — employee records, items i
I have a project in which I want to take advantage of the C++ Standard library
(primarily because of the container classes - including the special ones).
FWIW the project has to traverse a directed acyclic graph (yes I know about
the boost lib).
For the rest of the project Obj-C and Cocoa is suf
Peter,
On Jan 29, 2014, at 12:02 PM, Peter Teeson
mailto:ptee...@icloud.com>> wrote:
I have a project in which I want to take advantage of the C++ Standard library
(primarily because of the container classes - including the special ones).
FWIW the project has to traverse a directed acyclic graph
On Jan 29, 2014, at 10:02 AM, Peter Teeson wrote:
> But other than a command line template, which is for C++, there does not seem
> to be one for ObjC++.
Yep. Never has been.
> Are there any current docs that my search didn't find and that you can point
> me to?
> Or advice you can offer to h
Matt, you have written a good essay illustrating the many twists, turns and
corners you get into when trying to track Undo yourself. Redo adds even more
complexity.
On 2014 Jan 29, at 07:30, Matthew LeRoy wrote:
> Am I on the right track, or is there some other recommended pattern here?
My r
Hello,
I am working on an app which for the present version, must be installed via an
installer package. The next version will be a Mac App Store app, so this won’t
be a concern then. But for the time being, the app has its own package
installer.
In Xcode (current version), when you create a
It was an endless series of compounding errors yesterday for some reason, but I
finally managed to get it to work. In retrospect it is easy, but not easily
discoverable.
Here's the finished demo project:
http://www.sethwillits.com/temp/CATest_PresentationLayerTracking.zip
In this project a
On Wed, Jan 29, 2014, at 11:44 AM, Seth Willits wrote:
>
> - ConnectionsLayer has a private property: @property int
> nodePositionsDidChange;
> - +needsDisplayForKey: returns YES for "nodePositionsDidChange" (calls
> super for anything else)
> - noteNodePositionsChanged calls:
> [self addAni
On Wed, Jan 29, 2014, at 12:14 PM, Kyle Sluder wrote:
> [connectionsAnimGroup addAnimation:[MyConnectionsAnimation
> animationOfLineNamed:sublayer.name
> fromPoint:oldConnectionEndpoint toPoint:newConnectionEndpoint];
> }
>
> // The connections layer returns YES for
> +needsDis
On Jan 29, 2014, at 9:02 AM, Peter Teeson wrote:
> I understand that the file extension needs to be .mm to mix Obj-C and C++.
> But other than a command line template, which is for C++, there does not seem
> to be one for ObjC++.
It's honestly not any different. You're writing Objective-C code
On Jan 29, 2014, at 10:27 AM, Jerry Krinock wrote:
> On 2014 Jan 29, at 08:07, Keary Suska wrote:
>
>> In my experience, manipulating NSUndoManager's stack is an exercise in
>> frustration, as NSUndoManager's gets itself into an inconsistent state. IMHO
>> this is largely due to the opacity o
I've seen behaviors like this with other apps, i.e. the Google Hangouts app.
The keyboard will be active from a chat, and I'll leave the app. Then I'll get
a notification that a message came in, go to the app, and there's some period
of time before the keyboard becomes responsive.
I think I onl
On Jan 29, 2014, at 11:07 AM, Keary Suska wrote:
> As the object of an action the "deleted" object should be retained by
> NSUndoManager, so you don't have to track it yourself.
*light bulb*
For whatever reason, I had it in my head that neither the target of the undo
action nor the parameter(s
On Jan 29, 2014, at 1:48 PM, Jens Alfke wrote:
>
> On Jan 29, 2014, at 9:02 AM, Peter Teeson wrote:
>
>> I understand that the file extension needs to be .mm to mix Obj-C and C++.
>> But other than a command line template, which is for C++, there does not
>> seem to be one for ObjC++.
All
On 30 Jan 2014, at 8:03 am, Keary Suska wrote:
> Absolutely, and I have found it invaluable to troubleshoot state issues, but
> unfortunately it is not App Store safe (read: basis for rejection), as it
> relies on a private method call for proper NSDocument change tracking...
It does?
I'm u
On 29 Jan 2014, at 18:02, Peter Teeson wrote:
> All the searching I've done has not turned up anything current about how
> things work
> these days with Xcode 5 and llvm. There is the 2005 ObjC++.pdf which I have
> but Xcode has changed a lot since those days.
I talked about ObjC++ on NSBrie
On 30 Jan 2014, at 3:03 am, Michael Starke
wrote:
> NSUndoManager prepareWithInvocationTarget:
>
> the proxy that wraps the NSInvocation retains the target. Thus using a
> [[undoManager prepareWithInovationTarget:myObject] remove] call should ensure
> the object lives as long as the undo sta
To those of you doing Objective-C++ apps, is there a difference in terms of
performance or memory usage?
I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less
memory than the Chocolat editor which seems to be done exclusively in Cocoa.
On 30 Jan 2014, at 00:04, Uli Kustere
On Jan 29, 2014, at 3:16 PM, Rui Pacheco wrote:
> To those of you doing Objective-C++ apps, is there a difference in terms of
> performance or memory usage?
> I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less
> memory than the Chocolat editor which seems to be done ex
On Jan 29, 2014, at 3:44 PM, Graham Cox wrote:
>
> On 30 Jan 2014, at 8:03 am, Keary Suska wrote:
>
>> Absolutely, and I have found it invaluable to troubleshoot state issues, but
>> unfortunately it is not App Store safe (read: basis for rejection), as it
>> relies on a private method call
On 30 Jan 2014, at 00:16, Rui Pacheco wrote:
> To those of you doing Objective-C++ apps, is there a difference in terms of
> performance or memory usage?
>
> I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less
> memory than the Chocolat editor which seems to be done excl
On Jan 29, 2014, at 6:41 PM, Uli Kusterer wrote:
> On 30 Jan 2014, at 00:16, Rui Pacheco wrote:
>> To those of you doing Objective-C++ apps, is there a difference in terms of
>> performance or memory usage?
>>
>> I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less
>> m
On 30 Jan 2014, at 04:05, Rick Mann wrote:
> I've seen behaviors like this with other apps, i.e. the Google Hangouts app.
> The keyboard will be active from a chat, and I'll leave the app. Then I'll
> get a notification that a message came in, go to the app, and there's some
> period of time
All I can say is to write a bug. I did, regarding the Hangouts keyboard delay.
On Jan 29, 2014, at 16:00 , Gerriet M. Denkmann wrote:
>
> On 30 Jan 2014, at 04:05, Rick Mann wrote:
>
>> I've seen behaviors like this with other apps, i.e. the Google Hangouts app.
>> The keyboard will be activ
On Jan 29, 2014, at 11:36 AM, Bradley O'Hearne
wrote:
> Hello,
>
> I am working on an app which for the present version, must be installed via
> an installer package. The next version will be a Mac App Store app, so this
> won’t be a concern then. But for the time being, the app has its own
On 30 Jan 2014, at 07:01, Rick Mann wrote:
> All I can say is to write a bug. I did, regarding the Hangouts keyboard delay.
I planned to do so (but was waiting for 7.1 to appear). But I might as well do
it now. Done: 15941951.
>
> On Jan 29, 2014, at 16:00 , Gerriet M. Denkmann wrote:
>
>>
On 1/29/14, Uli Kusterer wrote:
> On 30 Jan 2014, at 00:16, Rui Pacheco wrote:
>> To those of you doing Objective-C++ apps, is there a difference in terms
>> of performance or memory usage?
>>
>> I've noticed that TextMate 2, which is done in Objective-C++, consumes
>> less memory than the Chocol
On Jan 29, 2014, at 4:28 PM, Eric Wing wrote:
> - Additionally, C++ will typically increase your compile and link times.
Oh my yes. The C++ compiler generates huge amounts of symbolic data and nearly
chokes the linker. The last big C++ project I worked on (Chrome) took over a
minute just to l
On Jan 29, 2014, at 4:42 PM, Jens Alfke wrote:
>
>
> * except for a subset of NSNumbers which the runtime cleverly hides inside
> tagged pointers, a C++-like trick
Smalltalk did it first.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Plea
On Jan 29, 2014, at 4:57 PM, Lee Ann Rucker wrote:
> On Jan 29, 2014, at 4:42 PM, Jens Alfke wrote:
>>
>> * except for a subset of NSNumbers which the runtime cleverly hides inside
>> tagged pointers, a C++-like trick
>
> Smalltalk did it first.
Lisp probably did it before that.
--
Greg Par
On Jan 29, 2014, at 4:57 PM, Lee Ann Rucker wrote:
> Smalltalk did it first.
Actually LISP did it first, if you want to get pedantic…
(Wikipedia has let me down: the entry for Tagged Pointer is pretty lame and has
no discussion of the history.)
—Jens
_
On 30 Jan 2014, at 12:02 pm, Jens Alfke wrote:
> Wikipedia has let me down: the entry for
> is pretty lame
FTFY ;)
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the
On Jan 29, 2014, at 6:02 PM, Greg Parker wrote:
> Lisp probably did it before that.
Hell, Lisp machines did it in hardware ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
___
Cocoa-dev mailing list
On 2014 Jan 29, at 13:03, Keary Suska wrote:
> unfortunately it [GCUndoManager] is not App Store safe … as it relies on a
> private method call for proper NSDocument change tracking…
I just spent the last half hour studying this and wrote my own concise legal
opinion arguing why GCUndoManager
37 matches
Mail list logo
