I did change the loop yesterday. and now its working ok...
> The rest of the discussion was off on a bit of a tangent - how best to write
> that loop.
the same was with me in todays post. . ;-)
Still Im having problems when dragging I need to be very precise when clicking
the first time.. mus
On 29/12/2009, at 7:37 PM, Gustavo Pizano wrote:
> Yes, the view is the only one adding the TA, when I resize the view by
> dragging, as far as I understand, the updateTrackingAreas method its called,
> so I overwrote that method deleting the old ones and calculating the new
> ones. Maybe wha
Yes, the view is the only one adding the TA, when I resize the view by
dragging, as far as I understand, the updateTrackingAreas method its called, so
I overwrote that method deleting the old ones and calculating the new ones.
Maybe what graham says must be done, copy the collection and iterate
On Dec 28, 2009, at 18:41, Graham Cox wrote:
> I was wondering if fast enumeration operated on a copy internally. I'm
> thinking 'no', since ...
The implementation of the fast enumeration protocol is different in every class
that conforms to it, but typically it would be expected not to copy an
On 28 dec 2009, at 09.22, Gustavo Pizano wrote:
> I cant use the last option because it may happen that I will have not just 2
> TA but N..
Perhaps you should still maintain your own array of tracking areas? I'm not
sure if anyone else should ever add tracking areas to your view, but it might
On 28 dec 2009, at 18.41, Graham Cox wrote:
> So, if -trackingAreas returns the actual array (rather than a copy), and
> -removeTrackingArea: is basically a wrapper for -removeObject: on that same
> array then the loop will fail with this exception. Since we don't know if
> either of these thi
On 29/12/2009, at 1:03 PM, Henry McGilton (Boulevardier) wrote:
>> Wouldn't this fall foul of the usual problem with deleting items from the
>> collection being iterated, in that it will skip every other object? (Or
>> perhaps fast enumeration has a built-in protection against that?)
>
> Yes,
On Dec 28, 2009, at 3:27 PM, Graham Cox wrote:
>
> On 29/12/2009, at 4:00 AM, Joar Wingfors wrote:
>
>>> NSInteger i = 0;
>>> while ([[self trackingAreas] count]==0) {
>>> [self removeTrackingArea:[[self trackingAreas]
>>> objectAtIndex:i]];
>>> i++;
>>> }
>
On 29/12/2009, at 10:27 AM, Graham Cox wrote:
> or iterate it by index backwards.
Or of course, just repeatedly delete item '0' until the count is 0. No need for
an index, though it might not be all that efficient, if the internal
implementation moves elements > removed index down one using
On 29/12/2009, at 4:00 AM, Joar Wingfors wrote:
>> NSInteger i = 0;
>> while ([[self trackingAreas] count]==0) {
>> [self removeTrackingArea:[[self trackingAreas]
>> objectAtIndex:i]];
>> i++;
>> }
>
>
> That loop seems all kinds of wrong... ;-)
>
>
aha mmm thanks...
that loop was the first thing came into my mind.
I cant use the last option because it may happen that I will have not just 2 TA
but N..
G.
On Dec 28, 2009, at 6:00 PM, Joar Wingfors wrote:
>
> On 28 dec 2009, at 07.55, Gustavo Pizano wrote:
>
>> NSInteger i = 0;
>>
On 28 dec 2009, at 07.55, Gustavo Pizano wrote:
> NSInteger i = 0;
> while ([[self trackingAreas] count]==0) {
> [self removeTrackingArea:[[self trackingAreas]
> objectAtIndex:i]];
> i++;
> }
That loop seems all kinds of wrong... ;-)
How about:
Hello again.
Im overriding this method :
-(void) updateTrackingAreas{
[super updateTrackingAreas];
NSInteger i = 0;
while ([[self trackingAreas] count]==0) {
[self removeTrackingArea:[[self trackingAreas]
objectAtIndex:i]];
i++;
}
Hello all.
I have this simple thing to do, but I can't find how to.
Im declaring tracking areas for my view to be the a small portion of the
bottom part of it, this is to allow resizing of the view, and be able to
updateCursor when the mouse is over it.. now.. when I set the view for first
tim
14 matches
Mail list logo
