Yes, this all makes sense to me. I'm not super advanced, but I do at least
understand the idea of keeping reads/writes temporally distinct.
Anyway, it looks like I found the problem. There was a somewhat unnecessary (or
at least easily avoidable call) happening to a method that **does** tamper w
On Sun, May 2, 2010 at 1:50 AM, James Maxwell
wrote:
>> On May 1, 2010, at 21:22, James Maxwell wrote:
>>
>>> If I drop into the debugger arbitrarily, before the crash, and check this
>>> same array, I noticed that it is nicely filled with NSCFNumbers. But,
>>> strangely, there are too many.
>>
>>
>
> This strongly suggests a memory management problem -- something is
> over-releasing the items in the array.
>
okay, this is what I figured, but I can't see anywhere where this could be
happening.
> On May 1, 2010, at 21:22, James Maxwell wrote:
>
>> If I drop into the debugger arbi
On May 1, 2010, at 20:42, James Maxwell wrote:
> So, looking more closely at the NSArray itself in the debugger, the items in
> the array come up as
>
> 0 NSCFNumber*
> 1 NSCFNumber*
> 2 NSObject*
> 3 _NSZombie_CFNumber*
> 4 NSObject*
This strongly suggests a memory management problem -- someth
Poking around some more...
If I drop into the debugger arbitrarily, before the crash, and check this same
array, I noticed that it is nicely filled with NSCFNumbers. But, strangely,
there are too many. The code that fills this array, is this:
- (void)
addCoincide
ugh... okay, so changing the logic cured the crashes, but also negatively
impacted the system (it's a machine-learning thing, and the old logic was
crucial to the predictive power of the system).
So, I'm back to the crash.
So, looking more closely at the NSArray itself in the debugger, the items
Actually this doesn't seem to scroll to footer view :(
Following is the code I have, i am continuously adding cells. Now I want to
scroll to bottom footer view. Following code doesn't seem to scroll to the
most bottom footer view.
[tableview beginUpdates];
[tableview insertRowsAtIndexPaths:[NSArr
On 1 May 2010, at 9:52 PM, Tharindu Madushanka wrote:
> How can I scroll to a UITableView footer all the time, while adding cells to
> table view content.
>
> Is there some way similar to scrollToRowAtIndexPath: , to scroll directly
> into my bottom footer view after adding new cells ?
What succ
UITableView is a subclass of UIScrollView. So, you can ask for its contentSize
and then call scrollRectToVisible:animated: with a rect that lies at the end of
the contentSize.
Luke
On May 1, 2010, at 7:52 PM, Tharindu Madushanka wrote:
> Hi,
>
> How can I scroll to a UITableView footer all th
Hi,
How can I scroll to a UITableView footer all the time, while adding cells to
table view content.
Is there some way similar to scrollToRowAtIndexPath: , to scroll directly
into my bottom footer view after adding new cells ?
Thank you and Kind Regards,
Tharindu Madushanak
just to call off the dogs, in case there are any, I solved the crash by
re-working the logic a little.
It's cleaner the new way anyway, though I don't know whether the concurrency
stuff is really fixed
(or whether it was "really" broken!)
It works, and I'm a tight deadline, so that's all that m
Okay, so let me give a little more info.
Here's the stack trace.
#0 0x7fff8578693c in __CFTypeCollectionRelease
#1 0x7fff85783e43 in __CFArrayReleaseValues
#2 0x7fff85764bc8 in _CFArrayReplaceValues
#3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
HSMM_Node.m:2
On May 1, 2010, at 5:04 PM, James Maxwell
wrote:
I'm having a crash when trying to remove the last item in an
NSMutableArray.
The app is a pretty complex system, and runs its two main processes
in consecutively executed blocks.
The blocks are run using dispatch_apply, on the global queue.
I'm having a crash when trying to remove the last item in an NSMutableArray.
The app is a pretty complex system, and runs its two main processes in
consecutively executed blocks.
The blocks are run using dispatch_apply, on the global queue. The operation
that's trying to
access the NSArray is, I
> Your response is appreciated! The main motivation for writing this
> application, is that existing linetesting software is typically buggy or
> awkward to use, so user friendliness is a huge point for me. Although I
> really would love to write something that matches Apples Quicktime player,
On May 1, 2010, at 15:57, Izak van Langevelde wrote:
> Although I really would love to write something that matches Apples Quicktime
> player, everything in Cocoa and everyone with a strong opinion on user
> interface design seems to scream "DON'T even think about it, unless you are
> absolutel
On 2010-05-01, at 6:04 PM, Flavio Donadio wrote:
> So, I ask you to think about your app and consider if even the HUD panels are
> needed. From the Apple Human Interface Guidelines:
>
>> In general, therefore, you should use transparent panels only when at least
>> one of the following stateme
Izak,
On 30/04/2010, at 17:48, Izak van Langevelde wrote:
> My problem is the difference in style between HUDS and 'normal' windows: I
> don't want my document windows to be transparent, I just want them to be
> black to match the style of a HUD. White and bright document windows really
> don
On Apr 30, 2010, at 5:50 PM, cocoa-dev-requ...@lists.apple.com wrote:
> Date: Fri, 30 Apr 2010 16:52:56 -0400
> From: Izak van Langevelde
> Subject: Re: Matching the style of a HUD?
> To: Murat Konar
> Cc: list-cocoa-dev List
> Message-ID: <09e1717e-7378-4704-99c3-6366c295e...@xs4all.nl>
> Con
It's inherited code from someone else, and am trying to work that out myself
too...luckily there are only 5-6 of them, so I should be able to sort it out.
Just looking at it now, I think a little refactoring should sort it out, and
remove the need for KVO.
On 02/05/2010, at 5:23 AM, Sean McBri
Gideon King (gid...@novamind.com) on 2010-05-01 09:42 said:
>Hi, I have some places in my code where I have managed objects that need
>to observe various key paths.
Why? (I'm curious... I've never used such a pattern.) Perhaps instead
you could override setters so that they perform other action
Thanks guys - will look into that.
On 02/05/2010, at 3:11 AM, Kyle Sluder wrote:
> On Sat, May 1, 2010 at 9:34 AM, Dave Fernandes
> wrote:
>> If you are observing something that is not part of your data model, you
>> might try using mechanisms other than KVO to keep your data model updated.
>>
On Sat, May 1, 2010 at 9:34 AM, Dave Fernandes
wrote:
> If you are observing something that is not part of your data model, you might
> try using mechanisms other than KVO to keep your data model updated. KVO can
> be a world of hurt when used the way you are using it. There are old threads
> o
It would be simpler to save the CGRect you calculate per word in an array and
just enumerate the rects for the point tapped.
--
Alex Kac
On my mobile device so please excuse the brevity.
On May 1, 2010, at 12:19 AM, Sasikumar JP wrote:
> Alex,
> I can draw the text using NSString's dr
There's no easy way to do this. But if you are observing other managed objects,
you might be able to use
+(NSSet*)keyPathsForValuesAffecting instead. (Search for "registering
dependent keys" in the docs.)
If you are observing something that is not part of your data model, you might
try using me
hi all,
i figured this one out.
when you initially create a scroll bar, that is when the horizontal or
vertical aspect of the bar is determined.
if you resize it later, that does not change the horizontal or vertical
setting.
so i was initializing my scroll bars with a square rectangle and call
Hi, I have some places in my code where I have managed objects that need to
observe various key paths. If one of these objects has been deleted by the
user, and then they undo, I need to re-establish the KVO.
As undo doesn't call awakeFromFetch, I need to do this somewhere else. I have
awakeFro
27 matches
Mail list logo