Delaying touchesMoved

[Eric E. Dolecki]

I've built a iOS simulation and I have been asked to provide a variable
delay between touchesMoved and it's actual code running - to simulate
latency. I imagine I'll be asked to provide this "system wide" - all
touches and interactions.

Since the delays would be anywhere from 5-30ms, I think I could almost get
away with performSelector with delay... but that feels messy. I could have
a Boolean and flip it after a timer and do that...

but I am asking the crowd here what the easiest to maintain and introduce
might be.

Thanks,
Eric
___

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: [Obj-C] if (self) vs. if (self != nil)

[Wade Tregaskis]

> if(self == nil)...
> if(self = nil)...
> if(nil == self)...
> if(nil = self)...
> 
> The 1st & 3rd are the correct conditions, the 2nd & 4th are typos. But the 
> 2nd compiles and gives incorrect behavior, while the 4th fails to compile.
> 
> Of course if(self) is not subject to that kind of typo, but if you're going 
> to insist on the verbose version, you might as well use if(nil == self).

Scott makes an excellent point.  I just want to emphasise it by saying how 
useful that has been to me over the years - countless bugs killed at birth.

I will admit it took me a while to get used to it, but the sooner you stop 
thinking about it the sooner it's natural.  You may run into people who dislike 
it on religious grounds, however.  For example, Google's internal style rules 
forbid it.  Try to make sure you're paid by bug count, if you find yourself in 
that situation. ;)
___

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: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 24, 2012, at 12:47 PM, Kyle Sluder wrote:

> But I'm not sure the integer conversion is necessarily relevant. The
> semantics of the if statement are defined by §6.8.4.1 ¶2: "the first
> substatement is executed if the expression compares unequal to 0." It
> is left unspecified if '0' is an integer constant expression or an
> arithmetic expression with an integer value of zero. If the former,
> then the pointer is compared against the null pointer constant per
> §6.3.2.3 ¶4. If the latter, the pointer is converted to integer per
> implementation-defined behavior and the comparison is performed, which
> might itself result in undefined behavior per §6.5 ¶5 since the
> conversion is not guaranteed to produce a value within range of any
> integer type.

Thing is: if(foo) is equivalent to if(foo != 0), which I think results in 0 
being treated as a pointer, not the pointer being cast to int, anyway if 
if(foo) could fail, so could if(foo != 0)... Also I think "Except as previously 
specified..." covers the case that NULL pointers convert to int 0...


-- 
Scott Ribe
scott_ribe@elevated-dev.comhttp://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 24, 2012, at 10:52 AM, Wade Tregaskis wrote:

> Though technically speaking it's true, and is thus an argument for actually 
> using NULL rather than 0

No, it's not such an argument at all. The compiler guarantees that null 
pointers converted to int become 0, that constant 0 assigned to a pointer makes 
it null, and that null pointer compared to 0 is true--regardless of whether the 
underlying hardware/OS representation of a null pointer is all 0 bits or not.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 24, 2012, at 2:47 PM, Ben Kennedy wrote:

> Fortunately the compiler (nowadays) warns in these situations, and suggests 
> that one either fix the operator or enclose the expression in extra 
> parentheses to clarify the intent. 

Sometimes. I've found that various warnings come & go with Xcode versions, 
without my changing project settings.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Ben Kennedy]

On 24 Feb 2012, at 9:52 am, Scott Ribe wrote:

> Now there is one style that is worth defending, which is when comparing a 
> variable to a constant, put the constant first. Consider the following:
> 
> if(self == nil)...
> if(self = nil)...
> if(nil == self)...
> if(nil = self)...
> 
> The 1st & 3rd are the correct conditions, the 2nd & 4th are typos. But the 
> 2nd compiles and gives incorrect behavior, while the 4th fails to compile.

Fortunately the compiler (nowadays) warns in these situations, and suggests 
that one either fix the operator or enclose the expression in extra parentheses 
to clarify the intent.  Personally I enjoy the latter.

b

--
Ben Kennedy, chief magician
Zygoat Creative Technical Services
http://www.zygoat.ca


___

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: [Obj-C] if (self) vs. if (self != nil)

[Marco S Hyman]

>> I also heard that generally speaking NULL is not necessarily always
>> equal to 0 on all architectures.
> 
> 
> I don't believe this is the case. There can be funny issues with BOOL types, 
> such that BOOL == YES is an inadvisable construct, since your BOOL could be 
> an integer of any value.

In the C language an integral constant expression with the value 0 will always
translate to a null pointer.  The actual representation of a null pointer in
memory may not be 0.   Different pointer types may have different internal
values.   The compiler will know how to translate "0" to the appropriate value
IF it knows the value is being used as a pointer.

See http://c-faq.com/null/index.html for lots more on the subject.  It explains
thing like why func(x, 0) may not generate the same code as func(x, (char*) 0).

Marc
___

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: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 24, 2012, at 10:36 AM, Keary Suska wrote:

>> I also heard that generally speaking NULL is not necessarily always
>> equal to 0 on all architectures.
> 
> 
> I don't believe this is the case.

Actually it is--in fact there can even be multiple representations that are 
null, but again the language is specified to take care of making NULL pointers 
equivalent to 0 for comparing pointers to 0 and assigning constant 0 to 
pointers. It's not something most of us need to worry about: obscure embedded 
stuff, ancient segmented architectures, different size pointers to different 
data types, and other such madness.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: Semi-Transient NSPopover disappearing when it shouldn't (10.7.3)

[Antonio Nunes]

On 24 Feb 2012, at 16:55, Corbin Dunn wrote:

>> I have a few popovers that, as far as I'm aware of, were working fine up to 
>> 10.7.2. Now, in 10.7.3, when the popover appears, if a user clicks on it, it 
>> often disappears, whether the click is on the background or on a UI item. I 
>> haven't figured out the trick exactly of the way in which clicking makes the 
>> popover go away, but it appears to be sensitive to how you click. A popover 
>> should never go away though when it is clicked upon. I think this is a bug 
>> in 10.7.3. Various internet searches for this issue did not return any 
>> results, nor did searching Apple's developer forums.
>> 
>> Any ideas what might be causing this, or how to work around the issue? Has 
>> anyone else even encountered this issue?
> 
> I don't believe we changed NSPopover in 10.7.3, but it is possible that 
> something else is affecting this.
> 
> It sounds like something outside of the popover is becoming the first 
> responder, and that causes the popover to go away.

It was a bit as if there was a prolonged period where the underlying window (or 
an element of it) was first responder. If we waited long enough before clicking 
anywhere on the popover, or if we pressed tab to activate another text field in 
the popover then clicking would function normally.

As I wrote in answer to Seth Willis, I was able to fix the issue (the email 
still hasn't shown up on the list, so I'll repeat it here):
> On 23 Feb 2012, at 21:52, Seth Willits wrote:
> 
>>> I have a few popovers that, as far as I'm aware of, were working fine up to 
>>> 10.7.2. Now, in 10.7.3, when the popover appears, if a user clicks on it, 
>>> it often disappears, whether the click is on the background or on a UI item.
>> 
>> Can you replicate this in a test project?
> 
> I couldn't replicate it in Apple's sample "Popover" project, but since it had 
> a somewhat different implementation than what I had devised, I changed my 
> strategy to one more similar with that of the sample, and, for now, it looks 
> like it fixed the issue.
> 
> I had my popovers in separate nibs, which each had a popover and the file's 
> owner was the popover view controller (not the one the IB automatically 
> creates when you drag in a popover, since I needed the file's owner to be the 
> popover controller, so I had deleted the one IB creates).
> 
> Now I changed strategy to have one popover in the view controller that 
> controls and displays the popovers, and the nibs have only the popover view 
> controller and the the view. Now the popover is created on the fly in the 
> parent view controller, instead of residing in the nib. This appears to work 
> better in 10.7.3.

-António


I try to take one day at a time, but sometimes, several days attack me all at 
once!




___

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: [Obj-C] if (self) vs. if (self != nil)

[Sean McBride]

On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said:

>I don't believe this is the case. There can be funny issues with BOOL
>types, such that BOOL == YES is an inadvisable construct, since your
>BOOL could be an integer of any value.

Indeed, and it's extremely frustrating.  I encourage you to file bugs on this, 
or maybe add a comment here:



-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: [Obj-C] if (self) vs. if (self != nil)

[Greg Parker]

On Feb 24, 2012, at 6:50 AM, Oleg Krupnov  wrote:
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.

In practice, NULL is always 0. Any exceptions were ancient historical oddities 
that you can ignore.

In principle, the C language says that NULL must behave as if it were zero, but 
that the bit pattern of a null pointer in memory is not necessarily zero.

http://c-faq.com/null/machnon0.html
http://c-faq.com/null/varieties.html
http://c-faq.com/null/machexamp.html


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: [Obj-C] if (self) vs. if (self != nil)

[Erik Stainsby]

And what does the list feel about the following form (which I think I picked up 
from a Wil Shipley article):

if(nil != (self = [super init]))

Myself I find it elegantly brief and imminently readable. 


Time Dwarf,
Roaring Guy

On 2012-02-24, at 9:30 AM, David Duncan  wrote:

> On Feb 24, 2012, at 6:50 AM, Oleg Krupnov wrote:
> 
>> So basically, nil is of type "void*", so the expression "self != nil"
>> compares two pointers and the result is "boolean", which is perfect
>> for testing in the "if" statement. But the "self" alone is of type
>> "pointer" and so when it is tested by the "if" statement, it's
>> implicitly cast to the type "boolean".
> 
> In C any non-zero value is 'true', as such if (self) vs if (self != nil) is a 
> pure stylistic choice, neither is more correct than the other in terms of the 
> language itself.
> --
> David Duncan
> 
> 
> ___
> 
> 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/erik.stainsby%40roaringsky.ca
> 
> This email sent to erik.stain...@roaringsky.ca

___

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: [Obj-C] if (self) vs. if (self != nil)

[Nick Zitzmann]

On Feb 24, 2012, at 7:50 AM, Oleg Krupnov wrote:

> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
> 
> self = [super init];
> if (self)
> {
> }
> return self;
> 
> self = [super init];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?

It isn't. Both are valid methods of checking to see if some object is non-zero.

> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?

Where in the world did you hear that? From the C99 standard, 6.3.2.3 paragraph 
3:

"An integer constant expression with the value 0, or such an expression cast to 
type void *, is called a null pointer constant. If a null pointer constant is 
converted to a pointer type, the resulting pointer, called a null pointer, is 
guaranteed to compare unequal to a pointer to any object or function."

I suppose some compilers can ignore the standard and do their own thing, but 
the compilers that come with Xcode are pretty good with standards compliance.

Nick Zitzmann



___

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: [Obj-C] if (self) vs. if (self != nil)

[Oleg Krupnov]

Yes, I'm aware that in practice it doesn't matter, but when I code, I have to 
choose one or the other way, anyway. My current choice is (self != nil) for the 
sake of explicitness.

Thanks everyone for an interesting discussion, especially Kyle for such an 
exhaustive reference :)  

P.S. Sorry for posting the question into the wrong list. I'm a bit shaky in the 
classification of apple lists.



On Friday, February 24, 2012 at 9:47 PM, Kyle Sluder wrote:

> On Fri, Feb 24, 2012 at 6:50 AM, Oleg Krupnov  (mailto:oleg.krup...@gmail.com)> wrote:
> > An interesting question. The following samples are equivalent in terms
> > of compiled code, but which one is more correct from the language's
> > point of view?
> >  
> > self = [super init];
> > if (self)
> > {
> > }
> > return self;
> >  
> > self = [super init];
> > if (self != nil)
> > {
> > }
> > return self;
> >  
> > The Xcode samples promote the first variant, but I'm wondering if the
> > second one is more correct?
> >  
> > The "nil" is defined as follows (jumped to definition)
> >  
> > #define nil NULL
> > #define NULL ((void*)0)
> >  
> > So basically, nil is of type "void*", so the expression "self != nil"
> > compares two pointers and the result is "boolean", which is perfect
> > for testing in the "if" statement. But the "self" alone is of type
> > "pointer" and so when it is tested by the "if" statement, it's
> > implicitly cast to the type "boolean".
> >  
> > I also heard that generally speaking NULL is not necessarily always
> > equal to 0 on all architectures.
> >  
>  
>  
> §6.3.2.3 ¶3 defines the null pointer constant as "an integer constant
> expression with the value 0, or such an expression cast to type void
> *". A null pointer is one that has been assigned the value of the null
> pointer constant, or has been assigned the value of another null
> pointer.
>  
> But you are correct that conversion of a null pointer to integer is
> NOT defined to compare equal to an integer expression with a value of
> zero. §6.3.2.3 ¶6 makes that clear: "Any pointer type may be converted
> to an integer type. Except as previously specified, the result is
> implementation-defined." However, footnote 56 states that "The mapping
> functions for converting a pointer to an integer or an integer to a
> pointer are intended to
> be consistent with the addressing structure of the execution environment."
>  
> But I'm not sure the integer conversion is necessarily relevant. The
> semantics of the if statement are defined by §6.8.4.1 ¶2: "the first
> substatement is executed if the expression compares unequal to 0." It
> is left unspecified if '0' is an integer constant expression or an
> arithmetic expression with an integer value of zero. If the former,
> then the pointer is compared against the null pointer constant per
> §6.3.2.3 ¶4. If the latter, the pointer is converted to integer per
> implementation-defined behavior and the comparison is performed, which
> might itself result in undefined behavior per §6.5 ¶5 since the
> conversion is not guaranteed to produce a value within range of any
> integer type.
>  
> In practice, it's a moot point since on all architectures that Apple's
> Objective-C runtime runs on use identical bit patterns for null
> pointers as they do for integer zero.
>  
> But absent any information I'm unaware of, the explicit comparison is
> "more correct" in the sense that it doesn't leave any room for
> implementation-defined behavior.
>  
> --Kyle Sluder  

___

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: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

Also, this question is much more appropriate for the objc-language
list than it is for cocoa-dev.

--Kyle Sluder

On Fri, Feb 24, 2012 at 6:50 AM, Oleg Krupnov  wrote:
> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
>
> self = [super init];
> if (self)
> {
> }
> return self;
>
> self = [super init];
> if (self != nil)
> {
> }
> return self;
>
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
>
> The "nil" is defined as follows (jumped to definition)
>
> #define nil NULL
> #define NULL ((void*)0)
>
> So basically, nil is of type "void*", so the expression "self != nil"
> compares two pointers and the result is "boolean", which is perfect
> for testing in the "if" statement. But the "self" alone is of type
> "pointer" and so when it is tested by the "if" statement, it's
> implicitly cast to the type "boolean".
>
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
>
> Thoughts?
___

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: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

On Fri, Feb 24, 2012 at 6:50 AM, Oleg Krupnov  wrote:
> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
>
> self = [super init];
> if (self)
> {
> }
> return self;
>
> self = [super init];
> if (self != nil)
> {
> }
> return self;
>
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
>
> The "nil" is defined as follows (jumped to definition)
>
> #define nil NULL
> #define NULL ((void*)0)
>
> So basically, nil is of type "void*", so the expression "self != nil"
> compares two pointers and the result is "boolean", which is perfect
> for testing in the "if" statement. But the "self" alone is of type
> "pointer" and so when it is tested by the "if" statement, it's
> implicitly cast to the type "boolean".
>
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.

§6.3.2.3 ¶3 defines the null pointer constant as "an integer constant
expression with the value 0, or such an expression cast to type void
*". A null pointer is one that has been assigned the value of the null
pointer constant, or has been assigned the value of another null
pointer.

But you are correct that conversion of a null pointer to integer is
NOT defined to compare equal to an integer expression with a value of
zero. §6.3.2.3 ¶6 makes that clear: "Any pointer type may be converted
to an integer type. Except as previously specified, the result is
implementation-defined." However, footnote 56 states that "The mapping
functions for converting a pointer to an integer or an integer to a
pointer are intended to
be consistent with the addressing structure of the execution environment."

But I'm not sure the integer conversion is necessarily relevant. The
semantics of the if statement are defined by §6.8.4.1 ¶2: "the first
substatement is executed if the expression compares unequal to 0." It
is left unspecified if '0' is an integer constant expression or an
arithmetic expression with an integer value of zero. If the former,
then the pointer is compared against the null pointer constant per
§6.3.2.3 ¶4. If the latter, the pointer is converted to integer per
implementation-defined behavior and the comparison is performed, which
might itself result in undefined behavior per §6.5 ¶5 since the
conversion is not guaranteed to produce a value within range of any
integer type.

In practice, it's a moot point since on all architectures that Apple's
Objective-C runtime runs on use identical bit patterns for null
pointers as they do for integer zero.

But absent any information I'm unaware of, the explicit comparison is
"more correct" in the sense that it doesn't leave any room for
implementation-defined behavior.

--Kyle Sluder

___

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: [Obj-C] if (self) vs. if (self != nil)

[David Rowland]

I usually prefer the more explicit form (of any expression) because it more 
obviously describes what is happening. That is your second example. However, 
anyone who works with any variant of C quickly becomes comfortable with the 
first form, so I consider it quite acceptable.

There is another form you will see,

if (self = [super init])  .

It compacts the assignment into the boolean. It works, but putting an 
assignment into a boolean is treading close to the edge of being misleading. 
Too clever by half, as the British say.

David







On Feb 24, 2012, at 6:50 AM, Oleg Krupnov wrote:

> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
> 
> self = [super init];
> if (self)
> {
> }
> return self;
> 
> self = [super init];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
> 
> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)
> 
> So basically, nil is of type "void*", so the expression "self != nil"
> compares two pointers and the result is "boolean", which is perfect
> for testing in the "if" statement. But the "self" alone is of type
> "pointer" and so when it is tested by the "if" statement, it's
> implicitly cast to the type "boolean".
> 
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?
> ___
> 
> 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/rowlandd%40sbcglobal.net
> 
> This email sent to rowla...@sbcglobal.net


___

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: [Obj-C] if (self) vs. if (self != nil)

[Wade Tregaskis]

> self = [super init];
> if (self)
> {
> }
> return self;
> 
> self = [super init];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?

No.  The more common convention in (Apple's) ObjC is to use implicit boolean 
values, though an explicit test against nil is fine if that's your preference.

> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)

I'd hazard to say that's an implementation detail.  While you can compare 
object pointers against NULL, it's strongly against convention - you use nil 
for pointers to ObjC objects, NULL for other types of pointers.  Hypothetically 
this protects you from any future changes in how objects are distinguished from 
"regular" pointers.

> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.


That definition is quite archaic.  Though technically speaking it's true, and 
is thus an argument for actually using NULL rather than 0, it's not the only 
such argument by far*, and in any case there's enough momentum behind NULL == 0 
that this will almost certainly never change.

* = For example, more important arguments are for readability in code, and 
because 0 is an integer whereas pointers are not.  And that a test against zero 
is faster than a test against any other specific integer on all modern hardware.
___

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: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 24, 2012, at 7:50 AM, Oleg Krupnov wrote:

> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?

Yeah, don't worry about it. The if(self) form is idiomatic C, by which I mean 
it's the way that C code has been written since the dawn of time, not that it's 
quirky. The if(self != nil) is perfectly correct as well, but adds nothing 
except satisfying some people's personal preference--the only people I've ever 
seen argue strongly in favor of it are ones who learned Pascal before C...

Yes, the underlying value of the NULL pointer may not be 0 on some 
architectures, but the language guarantees that if(self) will evaluate as you 
expect if self is the null pointer (and that assigning constant 0 to a pointer 
will set it to the null pointer). The few people who argue that if(self) is not 
portable are simply wrong.

Now there is one style that is worth defending, which is when comparing a 
variable to a constant, put the constant first. Consider the following:

if(self == nil)...
if(self = nil)...
if(nil == self)...
if(nil = self)...

The 1st & 3rd are the correct conditions, the 2nd & 4th are typos. But the 2nd 
compiles and gives incorrect behavior, while the 4th fails to compile.

Of course if(self) is not subject to that kind of typo, but if you're going to 
insist on the verbose version, you might as well use if(nil == self).

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Thomas Davie]

Neither is more correct.

The main distinction is whether you are happy with C's (very weak) type system 
or not.

If you are satisfied that if simply checks if some integer typed value is equal 
to 0 or not, and uses the first branch if it isn't, then the former is more 
concise and "better" for you.

If you on the other hand like to hold a stronger type system than C's in your 
head, and like to think of if statements as things that accept boolean 
arguments, and execute the first branch if the boolean is true, then clearly if 
(self) is an "in head" type error - you need to compare against nil to get a 
boolean out.

Hope that clarifies things.

Bob
if (*ra4 != 0xffc78948) { return false; }

On 24 Feb 2012, at 14:50, Oleg Krupnov wrote:

> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
> 
> self = [super init];
> if (self)
> {
> }
> return self;
> 
> self = [super init];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
> 
> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)
> 
> So basically, nil is of type "void*", so the expression "self != nil"
> compares two pointers and the result is "boolean", which is perfect
> for testing in the "if" statement. But the "self" alone is of type
> "pointer" and so when it is tested by the "if" statement, it's
> implicitly cast to the type "boolean".
> 
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?
> ___
> 
> 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/tom.davie%40gmail.com
> 
> This email sent to tom.da...@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: [Obj-C] if (self) vs. if (self != nil)

[Keary Suska]

On Feb 24, 2012, at 7:50 AM, Oleg Krupnov wrote:

> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
> 
> self = [super init];
> if (self)
> {
> }
> return self;
> 
> self = [super init];
> if (self != nil)
> {
> }
> return self;

It may really boil down to a stylistic issue, but I believe that the "self != 
nil" syntax is the most canonical.

> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.


I don't believe this is the case. There can be funny issues with BOOL types, 
such that BOOL == YES is an inadvisable construct, since your BOOL could be an 
integer of any value.

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

Re: [Obj-C] if (self) vs. if (self != nil)

[Fritz Anderson]

On 24 Feb 2012, at 8:50 AM, Oleg Krupnov wrote:

> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
> 
> self = [super init];
> if (self)
> {
> }
> return self;
> 
> self = [super init];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?

It's a matter of style; neither is "more correct." C has always guaranteed that 
in source (if not necessarily in the target architecture), NULL pointers can be 
treated as 0.

if (self)
and
if (self != nil)

should produce identical code. Some people find the second easier to read. I 
find the first to be so fundamental an idiom that anyone who can't understand 
it has no business working with C.

> So basically, nil is of type "void*", so the expression "self != nil"
> compares two pointers and the result is "boolean", which is perfect
> for testing in the "if" statement. But the "self" alone is of type
> "pointer" and so when it is tested by the "if" statement, it's
> implicitly cast to the type "boolean".

C, earlier than C99, has no concept of a Boolean. Conditionals are not false or 
true, but zero (or NULL) or non-zero. C99 has a bool (_Bool) type, but has to 
conform to the 0/non-0 rule. Boolean operators reduce true expressions to 1, 
but code that relies on 1 (or true, or YES) being the only non-false value is 
incorrect.

— F


___

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: [Obj-C] if (self) vs. if (self != nil)

[David Duncan]

On Feb 24, 2012, at 6:50 AM, Oleg Krupnov wrote:

> So basically, nil is of type "void*", so the expression "self != nil"
> compares two pointers and the result is "boolean", which is perfect
> for testing in the "if" statement. But the "self" alone is of type
> "pointer" and so when it is tested by the "if" statement, it's
> implicitly cast to the type "boolean".

In C any non-zero value is 'true', as such if (self) vs if (self != nil) is a 
pure stylistic choice, neither is more correct than the other in terms of the 
language itself.
--
David Duncan


___

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: [Obj-C] if (self) vs. if (self != nil)

[Howard Moon]

Really, this belongs in the Objective-C mailing list, but...

If the language provides a feature, then it is "correct" in terms of the 
language.

That said, I always use the long form, just to be sure I'm always specifying a 
boolean condition. This helps me when I'm combining or separating multiple 
conditions or simply trying to read my code later. I'm a big believer in using 
parentheses around sub-conditions as well, and never simply relying on order of 
evaluation.

I know there are many (esp. C programmers) who prefer the most abbreviated 
format possible, but I go the opposite way, always wanting to be able to easily 
read what I've written. After all, the symbols themselves will go away once 
compiled, and the extra time and space for the characters is inconsequential 
(these days) when compared to the need to easily identify what the heck you've 
written! :-)

-Howard


On Feb 24, 2012, at 6:50 AM, Oleg Krupnov wrote:

> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the language's
> point of view?
> 
> self = [super init];
> if (self)
> {
> }
> return self;
> 
> self = [super init];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
> 
> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)
> 
> So basically, nil is of type "void*", so the expression "self != nil"
> compares two pointers and the result is "boolean", which is perfect
> for testing in the "if" statement. But the "self" alone is of type
> "pointer" and so when it is tested by the "if" statement, it's
> implicitly cast to the type "boolean".
> 
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?
> ___


___

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: What to use instead of operatingSystemVersionString

[Sean McBride]

On Fri, 24 Feb 2012 13:56:08 +0700, Gerriet M. Denkmann said:

>The documentation says of NSProcessInfo operatingSystemVersionString:
>"This string is not appropriate for parsing". But if fails to mention
>what to use instead.
>
>So what should I use? Gestalt? Or is there some more convenient Cocoa
>alternative?
>
>(I need this info for a bug workaround which occurs only in 10.6.)

Depending on what your needs/purpose is, as Stephane says, 
NSAppKitVersionNumber may be your best choice.  Weak linking and 
doesRespondToSelector: are also useful.  If you use Gestalt, you should do this:

SInt32 major = 0;
(void)Gestalt (gestaltSystemVersionMajor, &major);

SInt32 minor = 0;
(void)Gestalt (gestaltSystemVersionMinor, &minor);

SInt32 fix = 0;
(void)Gestalt (gestaltSystemVersionBugFix, &fix);

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: Semi-Transient NSPopover disappearing when it shouldn't (10.7.3)

[Corbin Dunn]

On Feb 23, 2012, at 9:28 AM, Antonio Nunes  wrote:

> I have a few popovers that, as far as I'm aware of, were working fine up to 
> 10.7.2. Now, in 10.7.3, when the popover appears, if a user clicks on it, it 
> often disappears, whether the click is on the background or on a UI item. I 
> haven't figured out the trick exactly of the way in which clicking makes the 
> popover go away, but it appears to be sensitive to how you click. A popover 
> should never go away though when it is clicked upon. I think this is a bug in 
> 10.7.3. Various internet searches for this issue did not return any results, 
> nor did searching Apple's developer forums.
> 
> Any ideas what might be causing this, or how to work around the issue? Has 
> anyone else even encountered this issue?

I don't believe we changed NSPopover in 10.7.3, but it is possible that 
something else is affecting this.

It sounds like something outside of the popover is becoming the first 
responder, and that causes the popover to go away.

-corbin


> 
> -António
> 
> -
> Accepting others as they are
> brings a wonderful freedom
> to your own mind.
> 
> --The Peace Formula
> -
> 
> 
> 
> 
> 
> ___
> 
> 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/corbind%40apple.com
> 
> This email sent to corb...@apple.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

Recommendation: Turn on NSApplicationShowExceptions on your development machines

[Corbin Dunn]

Hi Cocoa Developers,

I really recommend turning on this new default that was introduced in Lion:

 defaults write NSGlobalDomain NSApplicationShowExceptions YES

It will let you catch exceptions in your app even when not running under the 
debugger. See the AppKit release notes for more information.

--corbin dunn



___

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: I added an exception breakpoint to my app...

[R]

Thanks Ken

On Feb 24, 6:04 am, Ken Thomases  wrote:
> Kyle misunderstood what you were asking.
>
> The debugger is simply reporting that it found the proper place to set the 
> breakpoint.  It resolved from a symbol to an address.
>
> Nothing has actually happened.  No exception was raised or caught.  The 
> breakpoint has not yet been hit.  The debugger is just preparing things.
>
> Regards,
> Ken
>
> On Feb 24, 2012, at 12:55 AM, R wrote:
>
>
>
>
>
>
>
>
>
> > Note that the exception was "resolved"... nothing to continue or log
> > as far as I can tell
>
> > On Feb 22, 11:17 pm, Kyle Sluder  wrote:
> >> On Wed, Feb 22, 2012 at 7:53 AM, R  wrote:
> >>> and now see:
>
> >>> Catchpoint 2 (throw)Pending breakpoint 1 - "objc_exception_throw"
> >>> resolved
>
> >>> No further details.  The app appears to be fine with no errors or
> >>> warnings.  Is this a problem?
>
> >>> (SnowLeopard Xcode 4)
>
> >> This the result of some non-obvious changes made between Xcode 3 and Xcode 
> >> 4.
>
> >> 1. "Break on Objective-C exceptions" is on by default, which will
> >> cause the debugger to break on objc_exception_throw.
> >> 2. "Show Disassembly When Debugging" is off by default, meaning that
> >> when you break in the debugger Xcode will select the first frame on
> >> the stack that contains _your_ code; often times this is the call to
> >> NSApplicationMain().
>
> >> The frequency of this question leads me to believe the defaults are
> >> confusing and should be changed. But for now, the upshot is that you
> >> can hit Continue and let the exception remain uncaught and logged to
> >> the console, or you can examine the exception object directly using
> >> gdb (`po $rsi` on 64-bit Intel).
>
> >> --Kyle Sluder
>
> >> ___
>
> >> Cocoa-dev mailing list (cocoa-...@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/cocoa-dev-garchive-...
>
> >> This email sent to cocoa-dev-garchive-98...@googlegroups.com
>
> > ___
>
> > Cocoa-dev mailing list (cocoa-...@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/ken%40codeweavers.com
>
> > This email sent to k...@codeweavers.com
>
> ___
>
> Cocoa-dev mailing list (cocoa-...@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/cocoa-dev-garchive-...
>
> This email sent to cocoa-dev-garchive-98...@googlegroups.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: What to use instead of operatingSystemVersionString

[Gerriet M. Denkmann]

On 24 Feb 2012, at 22:11, Jean-Daniel Dupas wrote:

> 
> Le 24 févr. 2012 à 07:56, Gerriet M. Denkmann a écrit :
> 
>> The documentation says of NSProcessInfo operatingSystemVersionString:
>> "This string is not appropriate for parsing". But if fails to mention what 
>> to use instead.
>> 
>> So what should I use? Gestalt? Or is there some more convenient Cocoa 
>> alternative?
>> 
>> (I need this info for a bug workaround which occurs only in 10.6.)
>> 
> 
> A bug in what framework.
Don't know. But the bug was first seen in 10.6 and I just tested 10.6.8 and 
it's still there.
But no more in 10.7.3, and not before 10.6 either.

Just looked at NSApplication.h and there is just one entry for 10.6.
So probably this will cover all versions of 10.6.
No, it does not. But:
BOOL needFix =  NSAppKitVersionNumber <= NSAppKitVersionNumber10_6  && 
NSAppKitVersionNumber <  
NSAppKitVersionNumber10_7;
seems to work.

> 
> Each framework provide constants and a version global to help you determine 
> the version.
> 
> kCFCoreFoundationVersionNumber, NSFoundationVersionNumber , 
> NSAppKitVersionNumber, NSCoreDataVersionNumber, …

___

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: text field question

[Kyle Sluder]

On Feb 23, 2012, at 5:38 PM, "Rick C."  wrote:

> Thanks Jan.  What method do you call to make it accept the text?  That's 
> maybe what I'm looking for...

As I mentioned before, and is explained in the documentation, you use 
-[NSWindow makeFirstResponder:] or -[NSObject(NSEditor) commitEditing].

--Kyle Sluder
___

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: What to use instead of operatingSystemVersionString

[Jean-Daniel Dupas]

Le 24 févr. 2012 à 07:56, Gerriet M. Denkmann a écrit :

> The documentation says of NSProcessInfo operatingSystemVersionString:
> "This string is not appropriate for parsing". But if fails to mention what to 
> use instead.
> 
> So what should I use? Gestalt? Or is there some more convenient Cocoa 
> alternative?
> 
> (I need this info for a bug workaround which occurs only in 10.6.)
> 

A bug in what framework.

Each framework provide constants and a version global to help you determine the 
version.

kCFCoreFoundationVersionNumber, NSFoundationVersionNumber , 
NSAppKitVersionNumber, NSCoreDataVersionNumber, …


> 
> Kind regards,
> 
> Gerriet.
> 
> 
> ___
> 
> 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/devlists%40shadowlab.org
> 
> This email sent to devli...@shadowlab.org

-- Jean-Daniel





___

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

[Obj-C] if (self) vs. if (self != nil)

[Oleg Krupnov]

An interesting question. The following samples are equivalent in terms
of compiled code, but which one is more correct from the language's
point of view?

self = [super init];
if (self)
{
}
return self;

self = [super init];
if (self != nil)
{
}
return self;

The Xcode samples promote the first variant, but I'm wondering if the
second one is more correct?

The "nil" is defined as follows (jumped to definition)

#define nil NULL
#define NULL ((void*)0)

So basically, nil is of type "void*", so the expression "self != nil"
compares two pointers and the result is "boolean", which is perfect
for testing in the "if" statement. But the "self" alone is of type
"pointer" and so when it is tested by the "if" statement, it's
implicitly cast to the type "boolean".

I also heard that generally speaking NULL is not necessarily always
equal to 0 on all architectures.

Thoughts?
___

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: ImageCapture + ImageKit problem...

[Eric Matecki]

Hi Fritz,

On 23/02/12 21:26, Fritz Anderson wrote:

On 23 Feb 2012, at 2:12 AM, Eric Matecki wrote:


Oh, something that may be part of the problem (or of the solution...):

I don't call run on my app for multiplatform portability reasons.
Instead I call this in a customized event loop:


Alas, you are writing an application for Mac OS X. Cocoa's event loop handler 
is probably more than two lines long, and ImageCapture/ImageKit may depend on 
things your event loop does not do.

Narrow your problem down by seeing whether your app works when run as an 
application.

— F


I really can't call run...
Our app runs on macosx, win, linux, android, and even on macrosystem's 
casablanca (if you ever heard about it).
They all have different philosophies about event handling, and we have to find 
some common ground.

In NSApplication's doc, it is said :
Subclassing Notes
...
Methods to Override
...
Override run if you want the application to manage the main event loop differently than it does by default. (This a critical and 
complex task, however, that you should only attempt with good reason.)

...

I think my reason is a good one, or at least a valid one, I can't just rewrite 
everything, that wouldn't make any economic sense.

So where can I find pointers as to how to override the run methods (google 
wasn't my friend this time...) ?
After all, it is explicitly allowed by Apple.

Thanks.

--
Eric M.
http://www.tvpaint.fr
___

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: What to use instead of operatingSystemVersionString

[Stephane Sudre]

If this is an AppKit related bug then you could check the
NSAppKitVersionNumber if a newer version was released for 10.6.1 that
solved the issue.

On Fri, Feb 24, 2012 at 7:56 AM, Gerriet M. Denkmann
 wrote:
> The documentation says of NSProcessInfo operatingSystemVersionString:
> "This string is not appropriate for parsing". But if fails to mention what to 
> use instead.
>
> So what should I use? Gestalt? Or is there some more convenient Cocoa 
> alternative?
>
> (I need this info for a bug workaround which occurs only in 10.6.)
>
>
> Kind regards,
>
> Gerriet.
>
>
> ___
>
> 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/dev.iceberg%40gmail.com
>
> This email sent to dev.iceb...@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: I added an exception breakpoint to my app...

[Ken Thomases]

Kyle misunderstood what you were asking.

The debugger is simply reporting that it found the proper place to set the 
breakpoint.  It resolved from a symbol to an address.

Nothing has actually happened.  No exception was raised or caught.  The 
breakpoint has not yet been hit.  The debugger is just preparing things.

Regards,
Ken

On Feb 24, 2012, at 12:55 AM, R wrote:

> Note that the exception was "resolved"... nothing to continue or log
> as far as I can tell
> 
> 
> On Feb 22, 11:17 pm, Kyle Sluder  wrote:
>> On Wed, Feb 22, 2012 at 7:53 AM, R  wrote:
>>> and now see:
>> 
>>> Catchpoint 2 (throw)Pending breakpoint 1 - "objc_exception_throw"
>>> resolved
>> 
>>> No further details.  The app appears to be fine with no errors or
>>> warnings.  Is this a problem?
>> 
>>> (SnowLeopard Xcode 4)
>> 
>> This the result of some non-obvious changes made between Xcode 3 and Xcode 4.
>> 
>> 1. "Break on Objective-C exceptions" is on by default, which will
>> cause the debugger to break on objc_exception_throw.
>> 2. "Show Disassembly When Debugging" is off by default, meaning that
>> when you break in the debugger Xcode will select the first frame on
>> the stack that contains _your_ code; often times this is the call to
>> NSApplicationMain().
>> 
>> The frequency of this question leads me to believe the defaults are
>> confusing and should be changed. But for now, the upshot is that you
>> can hit Continue and let the exception remain uncaught and logged to
>> the console, or you can examine the exception object directly using
>> gdb (`po $rsi` on 64-bit Intel).
>> 
>> --Kyle Sluder
>> 
>> ___
>> 
>> Cocoa-dev mailing list (cocoa-...@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/cocoa-dev-garchive-...
>> 
>> This email sent to cocoa-dev-garchive-98...@googlegroups.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/ken%40codeweavers.com
> 
> This email sent to k...@codeweavers.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: Crash when scroll down UITableView

[Eric Dolecki]

We need to see code for your data provider and your cell ode for the table. 

Sent by Eric's faithful iPad. 

On Feb 19, 2012, at 10:50 AM, Vavelin Kevin  wrote:

> Hi all,
> 
> I'm Vavelin Kevin and i'm student at Supinfo International University. I try 
> to develop an application for my uni and i have something wrong on my app. 
> When i scroll down my tableView, it doesn't bounce, my app just crash with 
> "Thread 1: Program received signal: "EXC_BAD_ACCESS" ".
> I don't understand why i have this crash that make me totally crazy.
> 
> Do you have any idea ?
> 
> Thanks a lot for help. 
> 
> -- 
> Vavelin Kevin
> 
> ___
> 
> 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/edolecki%40gmail.com
> 
> This email sent to edole...@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: feature request: implement a true checkbox in iOS

[Mike Abdullah]

This really isn't the place for feature requests. File a radar instead.

On 24 Feb 2012, at 02:44, William Squires wrote:

> Ever since the first release of iOS (then called iPhone OS), the UISwitch has 
> really bothered me:
> 
> 1) It takes up too much valuable screen real-estate compared with a checkbox
> 2) The "On/Off" text can't even be customized - the checkbox NSButton in Mac 
> OS X at least allows you to change its caption.
> 
> Could the geniuses at Apple please do a better job - surely a custom view 
> should be easy enough for them to incorporate in iOS 6... :) Sure, I could 
> make a custom view, but then I'd have to import it into every iOS project - 
> yuck. Plus, what if they already have something like this planned? Their look 
> & feel wouldn't match mine, then mine would just look geeky... Plus, it's 
> probably get rejected from the app store. :(
> 
> 
> 
> 
> ___
> 
> 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/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.net


___

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: feature request: implement a true checkbox in iOS

[Joshua Tidsbury]

On 2012-02-23, at 9:44 PM, William Squires wrote:

> Ever since the first release of iOS (then called iPhone OS), the UISwitch has 
> really bothered me:
> 
> 1) It takes up too much valuable screen real-estate compared with a checkbox
> 2) The "On/Off" text can't even be customized - the checkbox NSButton in Mac 
> OS X at least allows you to change its caption.
> 
> Could the geniuses at Apple please do a better job - surely a custom view 
> should be easy enough for them to incorporate in iOS 6... :) Sure, I could 
> make a custom view, but then I'd have to import it into every iOS project - 
> yuck. Plus, what if they already have something like this planned? Their look 
> & feel wouldn't match mine, then mine would just look geeky... Plus, it's 
> probably get rejected from the app store. :(


http://bugreport.apple.com/


Joshua Tidsbury | CTV Television
t 416.384.7253 | m 416.433.3968 | joshua.tidsb...@bellmedia.ca
___

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

[Jeremy Matthews]

Awesome, I'll check it out!

Thanks
Jeremy

Sent from my iPhone

On Feb 24, 2012, at 4:42 AM, John Maisey  wrote:

> 
> I also don't think this is in the API. 
> 
> The relevant information is stored in the Info.plist file for each calendar. 
> The keys are 'EventContainer' and 'TaskContainer', both boolean.
> 
> Best wishes
> 
> John Maisey
> 
> www.nhoj.co.uk
> www.twitter.com/johnmaisey
> www.facebook.com/nhojcouk
> 
> 
> 
> 
> 
> On 23 Feb 2012, at 23:04, cocoa-dev-requ...@lists.apple.com wrote:
> 
>> Message: 10
>> Date: Fri, 24 Feb 2012 08:49:33 +1000
>> From: Gideon King 
>> To: Jeremy Matthews 
>> Cc: list-cocoa-dev Development 
>> Subject: Re: iCal Integration
>> Message-ID: <4ad9e40b-977e-4901-a1cb-a068efd8f...@novamind.com>
>> Content-Type: text/plain; charset=windows-1252
>> 
>> I don't see anything in the API to detect it - I have encountered calendars 
>> that don't support tasks, and if I try to save a task to them, I get an 
>> error with code 1025 (CalCalendarNotEditableError), and deal with that in my 
>> code. 
>> 
>> isEditable returns YES for a calendar which only supports events, so you 
>> still have to try to save a task to it before you know it won't store tasks.
>> 
>> I haven't come across one that can't save events yet. Do you know what error 
>> code you get back when you try to save an event to a calendar which doesn't 
>> support events? I'm assuming it's the same code?
>> 
>> I haven't looked at the "type" property to see if the values there bear any 
>> relationship to what can be saved to it, but that seems like the only other 
>> property that could potentially be relevant…
>> 
>> 
>> HTH
>> 
>> Gideon
>> 
>> 
>> On 23/02/2012, at 1:19 PM, Jeremy Matthews wrote:
>> 
>>> I have a simple app which, as a byproduct, creates tasks and events in 
>>> iCal. Prior to 10.7, the user would choose from a popup list populated by 
>>> all calendars within the [CalCalendarStore defaultstore], which worked 
>>> great and created both events and tasks perfectly fine.
>>> 
>>> Now, in 10.7, it seems as if a CalDAV (alal iCloud) or Exchange calendar is 
>>> separated into two separate objects - one for events and one for tasks, and 
>>> the result is the user is shown a list of calendars...and in many cases 
>>> users appear to see duplicates, when in reality there are those two 
>>> separate "calendars".
>>> 
>>> So now, when a user selects the calendar, they might get an event created, 
>>> but not tasks, and vice-versa. 
>>> 
>>> Is there any known way of dealing with this, or any way to easily find out 
>>> which "calendar" supports events vs tasks, instead of firing off a "test" 
>>> tasks and finding out the hard way? Or perhaps, a better solution 
>>> altogether?
>>> 
>>> Thanks,
>>> jeremy
>> 
> 

___

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: Semi-Transient NSPopover disappearing when it shouldn't (10.7.3)

[Antonio Nunes]

On 23 Feb 2012, at 21:52, Seth Willits wrote:

>> I have a few popovers that, as far as I'm aware of, were working fine up to 
>> 10.7.2. Now, in 10.7.3, when the popover appears, if a user clicks on it, it 
>> often disappears, whether the click is on the background or on a UI item.
> 
> Can you replicate this in a test project?

I couldn't replicate it in Apple's sample "Popover" project, but since it had a 
somewhat different implementation than what I had devised, I changed my 
strategy to one more similar with that of the sample, and, for now, it looks 
like it fixed the issue.

I had my popovers in separate nibs, which each had a popover and the file's 
owner was the popover view controller (not the one the IB automatically creates 
when you drag in a popover, since I needed the file's owner to be the popover 
controller, so I had deleted the one IB creates).

Now I changed strategy to have one popover in the view controller that controls 
and displays the popovers, and the nibs have only the popover view controller 
and the the view. Now the popover is created on the fly in the parent view 
controller, instead of residing in the nib. This appears to work better in 
10.7.3.

-António


There is nothing as strong as real gentleness, and
there is nothing as gentle as real strength.






___

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: Crash when scroll down UITableView

[Mike Abdullah]

What's the backtrace? http://whathaveyoutried.com/ ? Instruments?

On 19 Feb 2012, at 15:50, Vavelin Kevin wrote:

> Hi all,
> 
> I'm Vavelin Kevin and i'm student at Supinfo International University. I try 
> to develop an application for my uni and i have something wrong on my app. 
> When i scroll down my tableView, it doesn't bounce, my app just crash with 
> "Thread 1: Program received signal: "EXC_BAD_ACCESS" ".
> I don't understand why i have this crash that make me totally crazy.
> 
> Do you have any idea ?
> 
> Thanks a lot for help. 
> 
> -- 
> Vavelin Kevin
> 
> ___
> 
> 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/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.net


___

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: ImageCapture + ImageKit problem...

[Eric Matecki]

Hi Fritz,

On 23/02/12 21:26, Fritz Anderson wrote:

On 23 Feb 2012, at 2:12 AM, Eric Matecki wrote:


Oh, something that may be part of the problem (or of the solution...):

I don't call run on my app for multiplatform portability reasons.
Instead I call this in a customized event loop:


Alas, you are writing an application for Mac OS X. Cocoa's event loop handler 
is probably more than two lines long, and ImageCapture/ImageKit may depend on 
things your event loop does not do.

Narrow your problem down by seeing whether your app works when run as an 
application.

— F


I really can't call run...
Our app runs on macosx, win, linux, android, and even on macrosystem's 
casablanca (if you ever heard about it).
They all have different philosophies about event handling, and we have to find 
some common groud.

In NSApplication's doc, it is said :
Subclassing Notes
...
Methods to Override
...
Override run if you want the application to manage the main event loop differently than it does by default. (This a critical and 
complex task, however, that you should only attempt with good reason.)

...

I think my reason is a good one, or at least a valid one, I can't just rewrite 
everything, that wouldn't make any economic sense.

So where can I find pointers as to how to override the run methods (google 
wasn't my friend this time...) ?
After all, it is explicitly allowed by Apple.

Thanks.

--
Eric M.
http://www.tvpaint.fr
___

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

What to use instead of operatingSystemVersionString

[Gerriet M. Denkmann]

The documentation says of NSProcessInfo operatingSystemVersionString:
"This string is not appropriate for parsing". But if fails to mention what to 
use instead.

So what should I use? Gestalt? Or is there some more convenient Cocoa 
alternative?

(I need this info for a bug workaround which occurs only in 10.6.)


Kind regards,

Gerriet.


___

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: I added an exception breakpoint to my app...

[R]

Note that the exception was "resolved"... nothing to continue or log
as far as I can tell


On Feb 22, 11:17 pm, Kyle Sluder  wrote:
> On Wed, Feb 22, 2012 at 7:53 AM, R  wrote:
> > and now see:
>
> > Catchpoint 2 (throw)Pending breakpoint 1 - "objc_exception_throw"
> > resolved
>
> > No further details.  The app appears to be fine with no errors or
> > warnings.  Is this a problem?
>
> > (SnowLeopard Xcode 4)
>
> This the result of some non-obvious changes made between Xcode 3 and Xcode 4.
>
> 1. "Break on Objective-C exceptions" is on by default, which will
> cause the debugger to break on objc_exception_throw.
> 2. "Show Disassembly When Debugging" is off by default, meaning that
> when you break in the debugger Xcode will select the first frame on
> the stack that contains _your_ code; often times this is the call to
> NSApplicationMain().
>
> The frequency of this question leads me to believe the defaults are
> confusing and should be changed. But for now, the upshot is that you
> can hit Continue and let the exception remain uncaught and logged to
> the console, or you can examine the exception object directly using
> gdb (`po $rsi` on 64-bit Intel).
>
> --Kyle Sluder
>
> ___
>
> Cocoa-dev mailing list (cocoa-...@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/cocoa-dev-garchive-...
>
> This email sent to cocoa-dev-garchive-98...@googlegroups.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: I added an exception breakpoint to my app...

[R]

I created a single view application in Xcode 4, no additions, just the
boilerplate template.  The same exception was noted.  Maybe an Xcode
bug?

thanks --R


On Feb 22, 11:17 pm, Kyle Sluder  wrote:
> On Wed, Feb 22, 2012 at 7:53 AM, R  wrote:
> > and now see:
>
> > Catchpoint 2 (throw)Pending breakpoint 1 - "objc_exception_throw"
> > resolved
>
> > No further details.  The app appears to be fine with no errors or
> > warnings.  Is this a problem?
>
> > (SnowLeopard Xcode 4)
>
> This the result of some non-obvious changes made between Xcode 3 and Xcode 4.
>
> 1. "Break on Objective-C exceptions" is on by default, which will
> cause the debugger to break on objc_exception_throw.
> 2. "Show Disassembly When Debugging" is off by default, meaning that
> when you break in the debugger Xcode will select the first frame on
> the stack that contains _your_ code; often times this is the call to
> NSApplicationMain().
>
> The frequency of this question leads me to believe the defaults are
> confusing and should be changed. But for now, the upshot is that you
> can hit Continue and let the exception remain uncaught and logged to
> the console, or you can examine the exception object directly using
> gdb (`po $rsi` on 64-bit Intel).
>
> --Kyle Sluder
>
> ___
>
> Cocoa-dev mailing list (cocoa-...@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/cocoa-dev-garchive-...
>
> This email sent to cocoa-dev-garchive-98...@googlegroups.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

[Moderator] Obvious, but lists are back up

[Scott Anguish]

This may be obvious since you’re reading this, but the lists are back up after 
a brief technical issue.

Thanks for your patience and a big thanks to those who fixed the issue.



--
Moderator *Scott=[Moderator alloc];
___

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: NSView mouseDown truncated coordinates

[Greg Parker]

On Feb 23, 2012, at 12:09 PM, Markus Spoettl  wrote:
> 1) On -mouseMoved: locate object under the cursor and highlight it so the 
> user knows which one of them will be operated on when the mouse goes down.
> 
> 2) On -mouseDown: locate object under the cursor and prepare it for dragging 
> (by remembering it).
> 
> 3) On -mouseDragged: drag the object selected in (2)
> 
> Pretty standard stuff. Of course this relies on steps (1) and (2) locating 
> the same object.
> 
> Apparently one can't assume (1) and (2) produce the same coordinates, 
> although I think that's a bug or at least it's unclear what the relationship 
> of coordinates between mouseMoved: and mouseDown: is.

One alternative:

1. On -mouseMoved: locate and highlight and remember the object under the cursor
2. On -mouseDown: do nothing
3. On -mouseDragged: drag the most recent object remembered by #1.

This works if the difference between the last -mouseMoved: and -mouseDown: is 
not too large. Try both and see which gives the better user experience.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: App Crashing in ARC !!

[KappA]

Based on this line:

 -[NSPanel release]: message sent to deallocated instance 0x111c74a60*

And this from the stack trace:

*#2  0x7fff8ff49ca0 in CFRelease ()*

Looks like you're over releasing. Perhaps ensure that the object is
declared as "strong" so that you keep a reference of it around?

This is just my guess based on the above. You should enable NSZombie and
malloc stack and see if you get any more info. If not, at least you have an
idea that it's the NSPanel, and you can take a closer look at that in your
code.

I happened to see this on the documentation for NSAlert which looks
interesting...

**
LinkSpecial
Considerations

This is a compatibility method. It is designed for easy adoption by
applications migrating from the corresponding function-based API. This
method uses earlier return
values—NSAlertDefaultReturn
,NSAlertAlternateReturn,
and 
NSAlertOtherReturn—compatible
with the earlier API, rather than the return values defined by the
NSAlert class,
described in “Button Return
Values.”

Unless you must maintain compatibility with existing alert-processing code
that uses the function-based API, you should allocate (alloc) and
initialize (init) the object, and then set its attributes using the
appropriate methods of the NSAlert class.
**

Anyways, good luck and maybe someone else might chime in with a more
conclusive answer.

Thanks,
Kappa


On Thu, Feb 23, 2012 at 3:01 PM, Fritz Anderson wrote:

> On 22 Feb 2012, at 9:31 PM, Naresh Kongara wrote:
>
> > I'm creating the alert with class method in NSAlert and running it with
> runModal.
> >
> > NSAlert *alert =[NSAlert
> alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:];
> > if ([alert runModal] == NSAlertDefaultReturn) {
> > //Code
> > }
> > This crash is happening only after we migrated to ARC. I tried with
> analyzer and Zombies, but no success in finding the cause for the crash.
>
> You've provided a skeleton of how you intend to do something, but nothing
> that shows what you are actually doing. You've provided nothing more than
> "make an alert and run it." If there is a bug in this section of your code,
> it's probably in the construction of the parameters to alertWith…, or in
> "Code."
>
> If your actual code is terribly complex, or proprietary, reduce it to a
> minimal case that reproduces it, and post it. Creating a minimal case will
> often show you your problem with no need to consult anyone else.
>
> Also: By any chance, are you running this alert on any thread other than
> the main one? You can't do that. You'll crash.
>
>— F
>
>
> ___
>
> 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/rejekted%40gmail.com
>
> This email sent to rejek...@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

feature request: implement a true checkbox in iOS

[William Squires]

Ever since the first release of iOS (then called iPhone OS), the UISwitch has 
really bothered me:

1) It takes up too much valuable screen real-estate compared with a checkbox
2) The "On/Off" text can't even be customized - the checkbox NSButton in Mac OS 
X at least allows you to change its caption.

Could the geniuses at Apple please do a better job - surely a custom view 
should be easy enough for them to incorporate in iOS 6... :) Sure, I could make 
a custom view, but then I'd have to import it into every iOS project - yuck. 
Plus, what if they already have something like this planned? Their look & feel 
wouldn't match mine, then mine would just look geeky... Plus, it's probably get 
rejected from the app store. :(




___

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: Dumb question about radio buttons

[William Squires]

That's what I was looking for - now, back to my project... tomorrow! :)

On Feb 23, 2012, at 2:04 PM, Seth Willits wrote:

> On Feb 23, 2012, at 5:58 AM, William Squires wrote:
> 
>> I have a custom view with an NSBox containing an NSMatrix of button cells 
>> (radio buttons) When I created the NSMatrix, I told it I wanted 3 of them, 
>> but in the view hierarchy, I can see the NSMatrix under the NSBox, but it 
>> has 4 button cells under it, not the three I asked for.
> 
> The top one is the prototype cell for the matrix. It's duplicated when new 
> cells are added.
> 
> 
> 
>> Also, even though I set the tag for each button cell  …. 
> 
> The sender is the matrix, not the individual cell.
> 
> 
>> Am I supposed to connect the NSMatrix to the action, and not the individual 
>> cells? If so, how do I ask for the cell's tag value?
> 
> 
> You have selectedCell to determine which radio cell is selected, and can get 
> its tag from that.
> 
> 
> --
> Seth Willits
> 
> 


___

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: text field question

[Rick C.]

Thanks Jan.  What method do you call to make it accept the text?  That's maybe 
what I'm looking for...



On Feb 23, 2012, at 11:32 PM, Jan E. Schotsman wrote:

> 
> On Feb 23, 2012, at 7:56 AM, Rick C. wrote:
>> 
>> I have a panel with a number of text fields where a user should enter 
>> numeric values.  These text fields are setup with Sent on End Editing so 
>> that if the user presses enter or tabs or changes text fields the value will 
>> be entered.  The problem is sometimes a user just types in a value and 
>> that's it...no enter, no tab, no changing text fields and the value is never 
>> received.  How does everyone else handle this and what can you recommend?
> 
> 
> I have Carbon app that starts a timer whenever typing occurs. After two 
> seconds it accepts the text.
> Not everybody likes it and I suppose you kindof may assume that most users 
> know text entries must be confirmed by pressing enter or return or changing 
> focus.
> 
> Jan E.
> ___
> 
> 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/rickcorteza%40gmail.com
> 
> This email sent to rickcort...@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: text field question

[Rick C.]

Thanks to all for the replies.  In my case there is a certain process that 
takes place (initiated by the user) that will read these values.  Currently if 
the user enters a value but does not click enter or tab, etc. when the process 
starts and I read the text field string it is empty.  In my case I would only 
need to read these values once before the process starts so I wouldn't have to 
worry about the key focus issues...



On Feb 24, 2012, at 6:17 AM, Keary Suska wrote:

> On Feb 22, 2012, at 5:59 PM, Rick C. wrote:
> 
>> I have a panel with a number of text fields where a user should enter 
>> numeric values.  These text fields are setup with Sent on End Editing so 
>> that if the user presses enter or tabs or changes text fields the value will 
>> be entered.  The problem is sometimes a user just types in a value and 
>> that's it...no enter, no tab, no changing text fields and the value is never 
>> received.  How does everyone else handle this and what can you recommend?  
>> Thanks,
> 
> 
> The Interface Builder inspector used to have this issue and it could be 
> really annoying. I would commit any values being entered when the panel loses 
> key focus, via the delegate method -windowDidResignKey: or listening for 
> NSWindowDidResignKeyNotification.
> 
> 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

Re: Loading existing NIB file from Cocoa?

[Howard Moon]

On Feb 23, 2012, at 2:17 PM, Fritz Anderson wrote:

> ... You know best, but do you really have to support Carbon any more?
> 
>   — F

Yes, as long as a significant portion of our customer base uses audio hosts 
that are carbon-based.

Heck, we still supported PowerPC until last year... and we got grief for 
stopping that! :-)

-Howard

P.S., Fritz, sorry for the double send, and to your personal email at that!  I 
think I need another coffee! :-)




___

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: NSView mouseDown truncated coordinates

[Quincey Morris]

On Feb 23, 2012, at 14:15 , Markus Spoettl wrote:

> Mouse movement highlighting must happen when the mouse moves. At that time, 
> only the mouse move coordinates are known. They correspond with what happens 
> on the screen, so highlighting works as expected.
> 
> Now a mouse-down comes along with different coordinates. That change in 
> coordinates is not reflected visually on screen (no cursor movement, no 
> highlight changes). It leads to other objects than the one highlighted one 
> being manipulated. Really confusing to the end user.

What I'm saying is, have mouseDown invoke cursorUpdate with the mouseDown 
event, so that if the position is different from the last real 
cursorUpdate/mouseMoved, the highlighted item will change to the item that's 
being dragged.

That may sound wrong, but it's the same behavior as if the mouse was really 
moving when you pressed the button.

Would I be correct in saying that the behavior you're asking for is as follows?

The mouse location reported in any event following mouseMoved or mouseDragged 
(except another mouseMoved or mouseDragged, of course) must be the same as the 
mouse location reported by the preceding mouseMoved or mouseDragged event.

Although the above might have been mostly true in the past, I doubt it was ever 
guaranteed in any way. However, even if it were true (or for that matter, even 
if your mouseDown called cursorUpdate/mouseMoved), it wouldn't truly solve your 
problem. It would mean that the dragged item is highlighted, not that the item 
the user attempted to click on (and was highlighted at the start of the 
attempt, perhaps) is dragged. See what I mean?

> PS: None of your or my replies seem to make it through to the list although 
> both you an I cc the list. Not sure why that is.

I think the list is just still slow. Or again. Other things are coming through.


___

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: Dumb question about radio buttons

[Gideon King]

Not sure about your number of items in your matrix, but you are wanting [sender 
selectedTag] to get the user's choice.

Regards

Gideon 

On 23/02/2012, at 11:58 PM, William Squires wrote:

> 
> -(IBAction)baseChanged:(id)sender
> {
> int choice = [sender tag];
> }
> 
> I always get, "user chose hexadecimal"! :( (all the buttons generate an 
> action, so it's not 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: iCal Integration

[Gideon King]

I don't see anything in the API to detect it - I have encountered calendars 
that don't support tasks, and if I try to save a task to them, I get an error 
with code 1025 (CalCalendarNotEditableError), and deal with that in my code. 

isEditable returns YES for a calendar which only supports events, so you still 
have to try to save a task to it before you know it won't store tasks.

I haven't come across one that can't save events yet. Do you know what error 
code you get back when you try to save an event to a calendar which doesn't 
support events? I'm assuming it's the same code?

I haven't looked at the "type" property to see if the values there bear any 
relationship to what can be saved to it, but that seems like the only other 
property that could potentially be relevant…


HTH

Gideon


On 23/02/2012, at 1:19 PM, Jeremy Matthews wrote:

> I have a simple app which, as a byproduct, creates tasks and events in iCal. 
> Prior to 10.7, the user would choose from a popup list populated by all 
> calendars within the [CalCalendarStore defaultstore], which worked great and 
> created both events and tasks perfectly fine.
> 
> Now, in 10.7, it seems as if a CalDAV (alal iCloud) or Exchange calendar is 
> separated into two separate objects - one for events and one for tasks, and 
> the result is the user is shown a list of calendars...and in many cases users 
> appear to see duplicates, when in reality there are those two separate 
> "calendars".
> 
> So now, when a user selects the calendar, they might get an event created, 
> but not tasks, and vice-versa. 
> 
> Is there any known way of dealing with this, or any way to easily find out 
> which "calendar" supports events vs tasks, instead of firing off a "test" 
> tasks and finding out the hard way? Or perhaps, a better solution altogether?
> 
> Thanks,
> jeremy


___

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

Crash when scroll down UITableView

[Vavelin Kevin]

Hi all,

I'm Vavelin Kevin and i'm student at Supinfo International University. I try to 
develop an application for my uni and i have something wrong on my app. When i 
scroll down my tableView, it doesn't bounce, my app just crash with "Thread 1: 
Program received signal: "EXC_BAD_ACCESS" ".
I don't understand why i have this crash that make me totally crazy.

Do you have any idea ?

Thanks a lot for help. 

-- 
Vavelin Kevin

___

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: Was: Re: NSStepper - useless?

[Gregory Weston]

William Squires wrote:

> Why didn't they just make the NSStepper a custom view that draws two arrows, 
> and has two sent actions that you can connect? Or even a variation of 
> NSMatrix with two button cells that look like arrows. That would avoid the 
> problem entirely, and be more intuitive to use.

Um. Because that's not what the control *is*. An NSStepper is a numeric input, 
for which the interface happens to be a pair of arrows. It's not just a pair of 
arrows that do whatever you want in response to pressing on each of them. Think 
of "stepper" in the context of "motor." If it was just two arrows with 
connectable actions it would be less intuitive and more difficult to use for 
what it was designed to do. If you want to augment the intended behavior, KVO 
is probably the way to go. If you want to do something completely different, 
your should have your own control and it shouldn't look especially like a 
stepper.
___

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: text field question

[Keary Suska]

On Feb 22, 2012, at 5:59 PM, Rick C. wrote:

> I have a panel with a number of text fields where a user should enter numeric 
> values.  These text fields are setup with Sent on End Editing so that if the 
> user presses enter or tabs or changes text fields the value will be entered.  
> The problem is sometimes a user just types in a value and that's it...no 
> enter, no tab, no changing text fields and the value is never received.  How 
> does everyone else handle this and what can you recommend?  Thanks,


The Interface Builder inspector used to have this issue and it could be really 
annoying. I would commit any values being entered when the panel loses key 
focus, via the delegate method -windowDidResignKey: or listening for 
NSWindowDidResignKeyNotification.

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