Re: [iPhone] (newbie) navigation controller is null, combining navigation controller and tab bar controller

[Greg Titus]

Hi Beth,

Something that you might try, just to simplify the number of IB  
hookups and cut down on the possibility of errors there, is to change  
this line:


[delegate.topicsTableNavController pushViewController:questionDetail  
animated:YES];


To just:

[self.navigationController pushViewController:questionDetail  
animated:YES];


The UIViewController class has a method (-navigationController) to  
access the navigation controller that it is currently inside of. Using  
it will keep you from having to look up you app delegate, since it  
looks like the problem that you are having is that your app delegate's  
"topicsTableNavController" outlet is not getting set.


Hope this helps,
- Greg

On Jun 15, 2009, at 8:26 AM, Beth Freeman wrote:

Hello,This is a follow up question to my previous question about  
combining a

navigation controller with a tab bar controller.

I have successfully combined the two in building the interface with
Interface Builder: My top level controller is a tab bar controller.   
This

references a navigation controller, which references a table view
controller.  Selecting a row from the table view is then supposed to  
display
a UI view (ie, not another table view).  When I run the program, I  
see the
tab bar, the navigation bar and the table with my data just fine.  
However,

when I select a row from the table, I never see the UI view.

In my accessoryButtonTappedForRowWithIndexPath method (see below) in  
my
table view controller, my navigation controller appears to be null.   
When I
put a breakpoint at the line when I push the view controller on the  
stack,

the address of the navigation controller is 0x0.

I have studied TheElements example from Apple extensively and  
believe I am

doing everything correctly in IB.  Since TheElements example is built
programmatically, it's a little difficult for me to know if I've done
everything I need to do to hook things up correctly, but I believe I  
have.
My understanding is that when I drag a controller from the library  
into my
MainWindow.xib window, I'm "instantiating" that as an object.  I  
have an

object in my MainWindow.xib window whose class is set to
TopicsTableNavController (the navigation controller for the first  
tab),
however, as described above, this appears to not be instantiated at  
the

breakpoint.

In TheElements example, the navigation controllers are created and  
added to
the tab bar view controllers programmatically.  My assumption was  
that when
you assign the view controllers for the tab bar controller through  
IB, and
set the class of each of the view controllers through IB, I'm  
instantiating

the objects at that time.

Am I missing something?  Is there something I need to do  
programmatically to
set up the navigation controller that I don't know about?  Am I  
wrong about

how IB works?

In the code below, I set up the view controller for the view that  
should be
pushed onto the stack (questionDetail) and, I assume, displayed.  I  
do see
the log message just before the push, and have verified that my view  
is
being set up correctly.  However, the view is never displayed, I'm  
guessing

because the navigation controller is 0x0 and is thus nil.

Thanks so much in advance for any help.

Elisabeth



- (void)tableView:(UITableView *)tableView
accessoryButtonTappedForRowWithIndexPath:(NSIndexPath *)indexPath {

NSUInteger row = [indexPath row];

if (self.questionDetail == nil) {

QuestionDetail *aQuestionDetail = [[QuestionDetail alloc]  
initWithNibName:

@"QuestionDetail" bundle:nil];

self.questionDetail = aQuestionDetail;

[aQuestionDetail release];

}

questionDetail.title = [NSString stringWithFormat:@"Question from %@",
[topicsArray objectAtIndex:row]];

if (QADetail != nil) {

[questionDetail.question setText:[QADetail objectForKey:@"question"]];

[questionDetail.answer setText:[QADetail objectForKey:@"answer"]];

}

NDQAppDelegate *delegate = [[UIApplication sharedApplication]  
delegate];


NSLog(@"Pushing Question Detail View Controller");

[delegate.topicsTableNavController pushViewController:questionDetail
animated:YES];

}
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to g...@omnigroup.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: GC pros and cons

[Greg Titus]

On Jun 24, 2009, at 10:38 PM, Marcel Weiher wrote:


On Jun 24, 2009, at 11:00 , Bill Bumgarner wrote:


On Jun 24, 2009, at 12:51 PM, Quincey Morris wrote:
In a nutshell, for folks like me who regularly use CFCreate …  
CFRelease in loops, what are the benefits of GC?


If CFCreate/CFRelease is precisely what you want to do, there are  
no benefits from GC, because the garbage collector isn't involved.  
Similarly, if you regularly use alloc/init ... release in loops,  
there are no benefits from using autorelease instead of release  
(in a non-GC app, I mean).


However, if the lifetime of the object you CFCreate is not  
strictly internal to the loop, then using (in a GC app)  
CFMakeCollectable once instead of futzing with CFRelease in  
multiple paths of execution might simplify your code greatly.


There are actually some performance downsides to using CFRetain/ 
CFRelease in Leopard that grow to a greater significance in Snow  
Leopard.  In Snow Leopard, this includes short lived objects like  
the temporaries that may be CFCreate'd/CFRelease'd in a tight loop  
(obviously, I can't disclose what those changes are -- if you are  
curious, post a question to devforums.apple.com).


Hmm...this part of the answer indicates a generic downside...

Specifically, you are effectively disabling the Collector's ability  
to do collection work, including object reclamation and  
finalization, concurrently with the execution of code that actually  
does work.


...whereas this part talks specifically about the collector.  Is  
there a downside in SnowLeopard to CFRetain/CFRelease when not using  
the collector?




There's no _new_ downside to CFRetain/CFRelease. It's just the  
existing downside (collected process or not) that CFRetain/CFRelease  
are function calls that need to be made and code that needs to be  
executed, and, what's more, retain/release needs to be thread-safe,  
which adds a bit more to the expense.


The important word in what Bill was saying is "concurrently". The  
garbage collector can work concurrently in another thread, so your  
tight loops in your compute thread(s) do less work (no CFRetain/ 
CFRelease), and you get a performance advantage because your code is  
able to take more advantage of multiple cores, since memory is  
reclaimed in a separate thread, rather than that work being  
interleaved in your code in the compute thread(s).


- Greg___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Undo without Redo

[Greg Titus]

On Jul 12, 2009, at 7:10 AM, John Nairn wrote:

I added an option to cancel some action in the middle of the action.  
The most convenient coding was to implement the cancel by calling  
undo in the NSUndoManager, but this adds a "Redo" action to redo the  
partial or incomplete changes (and leaves the data in a poor state).


I can either re-code the change process or for an alternative, is  
there a way to perform to top level undo without having it moved to  
the redo stack? Or, similarly, is there a way to perform an undo and  
then remove the top most item in the redo stack?


First, I'd agree with I.S. that this sounds a little bit unclean, and  
that if there is a way to rearchitect this, I would.


But to answer your question, the "redo" action consists of all those  
things that get registered for undo _during_ the time when it is  
undoing (which is why it is the opposite set of changes from the  
undone changes). So it ought to work to disable registration during  
that time. I.e.:


[undoManager disableUndoRegistration];
[undoManager undo];
[undoManager enableUndoRegistration];

Ought to undo the last top level undo group, but without registering  
anything on the redo stack.


Hope this helps,
Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: dragging to move objects around?

[Greg Titus]

Hi Darren,

The point passed into -draggedImage:endedAt:operation: is in screen  
coordinates, which is different from the window base coordinates that - 
convertPointFromBase: expects. You want to convert from screen to  
base, and then from base to your superview's coordinate system  
(because the frame rect that you are setting is in terms of your  
superview's coordinates):


aPoint = [[self window] convertScreenToBase:aPoint];
aPoint = [[self superview] convertPointFromBase:aPoint];
[self setFrameOrigin:aPoint];

I'll also mention that what you are doing here is not what is  
generally intended by the dragged image protocol. It is usually used  
for things like dragging icons or URLs to different apps/windows. If  
you want to move something around within a single view you'd generally  
detect what you clicked on in -mouseDown: and track the mouse in - 
mouseDragged:. You can reset your view's frame on every mouseDragged:  
call, so that the user will see the original view being moved around  
on your view instead of an image "lifted" up from your window and  
dragged anywhere on screen and then dropped.


Hope this helps,
- Greg

On Jul 22, 2009, at 4:27 AM, Darren Minifie wrote:


Hi

I am trying to implement the ability to move subviews around a view by
dragging them.  The simple code I have thus far:

- (void)draggedImage:(NSImage *)anImage endedAt:(NSPoint)aPoint
operation:(NSDragOperation)operation{
   [self setFrameOrigin:[self convertPointFromBase:aPoint]];
}

Here the image that is moving about is an exact copy of the original
subview.  When the endedAt method executes, I would like the  
subview's frame
to be changed to where the last position of the dragged image was.   
The code
I have thus far is producing some undpredictable results.  for  
example, i'll
drag the subview straight down ( no change in x) but the subview  
will be

moved somehwere far to the left or right.

--
Darren Minifie
Computer Science Masters Candidate
University of Victoria, BC. Canada
My Rants: www.noisyair.com
My Band: www.ohsnapmusic.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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to g...@omnigroup.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception-like behavior in save panel used for file choose

[Greg Titus]

On Jul 31, 2009, at 9:23 AM, Kyle Sluder wrote:

On Jul 31, 2009, at 8:38 AM, Steve Christensen   
wrote:
If you set a breakpoint on -[NSException raise], you can break when  
the exception actually happens.


On Leopard you want to break on obj_exceptionThrow instead.


Typo there... it's objc_exception_throw().


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa et al as HCI usability problem

[Greg Titus]

Peter Duniho wrote:

In C#:

   void setColor(NSColor color)
   {
   undoManager.prepareWithInvocationTarget(this).setColor(mColor);
   mColor = color;
   }


Your point being?  If you think your example is useful in presenting  
your claim, you'll need to be a lot more specific.


[...]
Well, I'm still waiting for someone to show me how that flexibility  
is used.  You are certainly doing a great job of stating the same  
party line I've heard countless times already.  But you're also  
failing to provide a compelling example of how this flexibility  
comes into play in the real world.  Again, this is not only typical,  
it's characteristic of _every_ single time I've heard the party line  
stated.


You've translated the Objective-C syntax into C# syntax, but the point  
of the question is to think about what prepareWithInvocationTarget()  
does. How would you write that method in C#?


In Objective-C, after you call -prepareWithInvocationTarget: on an  
NSUndoManager, it then accepts _any_ message call of any kind. It is  
completely and totally dynamic. It accepts messages from your  
application which weren't defined and didn't exist when the  
NSUndoManager class was compiled. The undo manager accepts the  
message, saves the target and method invocation with an arbitrary  
number of arguments and is able to re-invoke it later on the original  
target when the user asks you to Undo.


This is an example of what a dynamic message dispatch mechanism can do  
for you. How would you implement that in a direct invocation or v- 
table environment? Of course Undo is still doable in Java or C#: these  
are all turing equivalent languages, but how much code would it take  
and how complicated would it be for the programmer using the undo  
management library to define this-is-something-to-undo?


Hope this helps,
- Greg


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Greg Titus]

On May 19, 2008, at 10:52 AM, David Wilson wrote:
On Mon, May 19, 2008 at 1:33 PM, Peter Duniho <[EMAIL PROTECTED]>  
wrote:
Maybe I'm misinformed about how message-dispatching in Objective-C  
works.
But AFAIK, it's nothing like the direct invocation and v-table  
mechanisms

that exist in C# and Java.  It's the exact opposite of "similar".


You're misinformed about how message-dispatching in Objective-C works.
It's very analogous to a v-table in c++ and related languages; I
believe there's just a touch more run-time information stored in the
table.


Well, "similar" and "analogous" and "touch more information" are all  
kind of vague words, and we can disagree on wether they are analogous  
or similar or not. I don't think the mechanisms are very similar at  
all. To nail things down:


A v-table implementation means that the class of an object contains an  
array of function pointers. A call to a method compiles down to "call  
function #3". This means that both the caller and the callee both need  
to know the mapping that virtual method foo() is the third item in the  
v-table. Which means that the caller needs to be able to see all the  
class information for the receiver and all superclasses of the  
receiver to perform that mapping. Changing the order or number of  
virtual methods in any superclass results in all code that calls  
methods on that class needing to be recompiled because the v-table  
indices change. The benefit is that at runtime this simple index  
lookup then call is very fast.


Objective-C uses a method dispatch hash table. A method name is  
converted to something called a selector at compile time, and that  
selector is a unique one-to-one mapping to the method name. (So there  
is a "foo" selector with some unique value and at runtime you can  
convert the selector to the method name and vice versa.) The class of  
an object contains a hash table that allows you to look up a function  
pointer based on a selector. A call to a method compiles down to "look  
up selector X in this object's hash table and call it". The linker  
performs the uniquing of method names to selectors, so when compiling  
the caller doesn't need to know anything at all about the class of the  
receiver. The penalty to all this flexibility is that at runtime the  
hash table lookup isn't quite as fast as the v-table simple index.


Hope this helps,
- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Greg Titus]

On May 19, 2008, at 11:00 AM, Peter Duniho wrote:

On May 19, 2008, at 10:48 AM, Greg Titus wrote:

You've translated the Objective-C syntax into C# syntax, but the  
point of the question is to think about what  
prepareWithInvocationTarget() does. How would you write that method  
in C#?


Well, it was a poorly stated question then.  His primary  
presentation asked how I'd write the code he posted, not the  
supporting implementation details.


I agree. It could have been stated a lot better.

In Objective-C, after you call -prepareWithInvocationTarget: on an  
NSUndoManager, it then accepts _any_ message call of any kind. It  
is completely and totally dynamic. It accepts messages from your  
application which weren't defined and didn't exist when the  
NSUndoManager class was compiled. The undo manager accepts the  
message, saves the target and method invocation with an arbitrary  
number of arguments and is able to re-invoke it later on the  
original target when the user asks you to Undo.


Thanks.  That certainly makes the example more clear, and make more  
sense.


That said, because of the existence of reflection in C# and Java,  
similar functionality isn't really that difficult in those  
languages.  It's trivial to take any arbitrary class or instance of  
a class and invoke any arbitrary named method with an arbitrary  
number of arguments, immediately or later as necessary.


I would agree that in the light you've offered, the NSUndoManager  
offers a somewhat more compelling use case than previous examples.   
But it's not true that the C# or Java version would be significantly  
different.  They would be only slightly more verbose (though yes, I  
admit...they would be more verbose, albeit slightly).


I've worked in Java quite a bit in the past, and I disagree, but more  
to the point: I've never done significant work in C# before, so if  
that's an environment you are familiar with and you are willing, I'd  
very much like to see what prepareWithInvocationTarget: would look  
like in that language.


NSUndoManager's Objective-C implementation looks something like this:

// all we need to do here is save a pointer to the target object in  
our instance variables temporarily

- (void)prepareWithInvocationTarget:(id)target
{
_target = target;
}

// this method is a part of the introspection done by the Obj-C  
runtime on looking up info on what method to call, if we have a  
target, act as if we are that target as far as the runtime is concerned

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
{
if (_target)
return [_target methodSignatureForSelector:aSelector];
else
[super methodSignatureForSelector:aSelector];

}

// the Obj-C runtime calls this method when it doesn't find a pre- 
existing defined method for a selector called upon you. The normal  
behavior is to throw an exception. Here we'll just re-direct the  
target of the message invocation back to our target, and save the  
invocation in a list. Then nil out our temporary target variable.

- (void)forwardInvocation:(NSInvocation *)anInvocation
{
[anInvocation setTarget:_target];
[_undoStack addObject:anInvocation];
_target = nil;
}

// Call invoke on all the NSInvocation objects that we've saved.  
They'll perform message calls on all their original targets.

- (void)undo
{
[_undoStack makeObjectsPerformSelector:@selector(invoke)];
}

Now in the real NSUndoManager there is a little more complication  
because there are multiple steps of undo supported and so on, but this  
is really all the code that you need to support a really powerful and  
general concept.


Hope this helps,
- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Greg Titus]

On May 19, 2008, at 12:08 PM, Peter Duniho wrote:
[...]
However, _with_ reflection we can do much of the same kinds of  
things that Obj-C does, without knowing in advance the classes that  
might use the NSUndoManager class.


One advantage I see in Cocoa is that, because classes may respond to  
selectors that they didn't even declare, NSUndoManager can simply  
set a temporary variable, and then catch a selector to be saved away  
for later invocation.  This makes the reflection aspect  
("introspection" in Objective-C) more transparent.


Right. I'm glad you see that. Another place to look for the same type  
of thing is Distributed Objects in Obj-C. It's another piece of the  
frameworks that use the ability to catch invocations "in flight". In  
that case, in order to serialize the method and arguments, send the  
data across the network or between threads, unserialize on the other  
side, and invoke in that other machine/process/thread.


An approach in C# that is still reasonably close to the Obj-C  
version would be to instead pass a method name and an array of  
arguments (so, the syntax isn't identical, but comparable):


   undoManager.prepareWithInvocationTarget(this, "setColor",  
object[] { mColor });


Then the method would look something like this (warning: email code,  
uncompiled, untested):


   void prepareWithInvocationTarget(object target, string name,  
object[] args)

   {
   Type[] argTypes = new Type[args.Length];
   MethodInfo targetMethod;

   for (int iarg = 0; iarg < args.Length; iarg++)
   {
   argTypes[iarg] = args[iarg].GetType();
   }

   targetMethod = target.GetType().GetMethod(name, argTypes);

   // save targetMethod and args in an appropriate data  
structure for

   // later retrieval and invocation
   // ...code omitted for brevity
   }


Thanks very much for the example. The same sort of facility (getting  
method from name) is available in Objective-C, of course, and Andreas  
Mayer replied on the list an interesting example of how he uses that  
in AppleScript handling. What C# seems to be missing is the reverse  
facility (going from a compiled method call back out to name +  
arguments), which my sample NSUndoManager code demonstrated.


Interestingly, given your earlier remarks about the desirability of  
compile time checking, in Objective-C [[undoManager  
prepareWithInvocationTarget:self] setColor:mColor] is type checked.  
The compiler knows about the -setColor: method declaration it has seen  
and can check that mColor is an appropriate type. (Because Obj-C still  
lets you call any method on any object the result of bad typing here  
will be a warning rather than an error, but Obj-C programmers  
generally learn to pay attention to and fix all warnings.) Whereas I  
suspect that when you are using the reflection facilities in C# in the  
way you are above, that there is no type checking being performed. Is  
that correct?


That is one of the advantages of having the dynamism built into the  
language runtime rather than a reflection API built on top. Another  
advantage is that code can be written that doesn't need to know  
whether reflection is being used or not. In the Distributed Objects  
case, for instance, it is very common to pass around proxies as  
arguments to code that doesn't have any idea that the methods it is  
calling on those argument objects actually get forwarded somewhere  
else entirely.


In reality, I would (and have) more likely implement an undo manager  
that uses anonymous methods.  Then all you're saving to your undo  
state is a delegate that does what you want (assumes the "property"  
semantic I posted):


   undoManager.AddUndo(delegate { color = mColor; });

This is more idiomatic in C# and wouldn't need all that messy  
reflection stuff.  Executing the undo is a simple matter of invoking  
the delegate that was passed, a simple one-line operation that reads  
like a method call (note that the use of the name "delegate" is very  
different in C# than in Cocoa...C# "delegate" is more like a  
function pointer than an actual object to which some selector has  
been delegated).


Like I said earlier, I don't know C#, but this doesn't appear to me  
what the code would actually look like.  The trouble is that the whole  
point is we want to be able to undo a previous -setColor: call. If  
mColor is a reference to the "this" object's current color, then at  
the time that the undo happens, the value of the reference "mColor"  
will be the _new_ color, not the old color that we want to restore. So  
that line of code will just set it to itself. What is needed is to  
store the mColor value as it is at the time the anonymous delegate is  
created, not at the time the delegate is executed. Is it possible for  
an anonymous method to have its own instance variables (in this case,  
to store the old color)? From looking at the docs it doesn't appear  
to. Nor does it seem possible to

Re: Trying to understand -- please help...

[Greg Titus]

On May 21, 2008, at 12:37 PM, Johnny Lundy wrote:


This is just one example of that "little tidbit" that is always left  
out of these references by Apple. It seems to be the <.O. for some  
reason. The "tidbit" isn't some extraneous bell or whistle; it's  
always something fundamental.


They can't take 2 lines instead of 1 to document the behavior of a  
class method?


A lot of people have already mentioned that the memory management  
semantics for these methods are the same everywhere and are described  
in the conceptual documentation. I'd like to answer the obvious follow  
up question: even if it is described in the concept docs, how would it  
hurt to repeat it in the NSArray class method references? It is just  
one more line...


The reason is that the location of the information says something very  
important about its specificity or generality.


Let me use the class hierarchy as a comparison point: An NSView has  
bounds and a frame and subviews. Those things are described in the  
NSView documentation. An NSScrollView also has bounds and a frame and  
subviews, but those aren't described in the NSScrollView  
documentation. Why? Because if you just looked at the NSScrollView  
docs and saw them there you could be left with the mistaken impression  
that bounds/frame/subviews are specific to scroll views. If those  
things were there it might make it easier to learn how to set the  
frame rectangle of a scroll view when you specifically needed to use a  
scroll view, but you would miss the very important lesson that _all_  
views work this way. It would, in fact, take a long time and a lot of  
use of various types of views to realize that - hey - these all work  
the same way in important respects. Worse, until you did finally  
figure that out, you'd be trying to use different views in different  
ad hoc ways instead of realizing that they all shared common  
functionality and ways of interacting with each other.


Re-describing all the superclass functionality in the subclass might  
seem like it puts all the information in one place if you are using  
the subclass, but it loses all sense of the overall design. Of what  
parts are specific to the class you are looking at and what parts are  
more general. And that sense of the overall design is a vastly more  
important thing to learn than the specific use of any one class.


This might seem obvious in the case of views because it is a type of  
abstraction that is very common in lots of languages. Now let's return  
to the memory management semantics: exactly like a subclass and  
superclass relationship, we don't want to re-describe the memory  
management semantics in each class reference because then you'd never  
learn that there are overarching rules to the design, which is a much  
more important thing to learn than what specifically happens with any  
one particular method. I think people new to Cocoa get into trouble  
with this specific topic because in most C-like languages, the most  
complicated thing about any API is the memory management semantics.  
Different libraries do very different things. Pass in your own  
buffers, have to free returned buffers, have to use some library- 
specific free()-like return-the-memory APIs, et cetera. The memory  
management style tends to be quite inconsistent and needs to be  
documented everywhere because different API calls can have different  
requirements. That this is _not_ the case in Cocoa is extremely  
important.


Hope this helps,
- Greg


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: How hard is it to learn Cocoa - Survey ?

[Greg Titus]

I think it'll be very hard to compare learning times then to learning  
times now because the frameworks involved are quite a bit different. I  
started working on Cocoa stuff for Omni near the end of 1993. A lot of  
the concepts behind the AppKit class hierarchy have changed  
surprisingly little since then, and we even had binding equivalents as  
part of DBKit (an ancient database layer that was rewritten into EOF  
and then into WebObjects Obj-C and then into Java...). But there was  
no Foundation framework back then, no retain/release, standard  
Objective-C style was even quite a bit different (set methods normally  
returning self instead of nil, et cetera).


With that caveat: I'm pretty sure I was usefully productive in Cocoa  
after two weeks or so. Note that this was a full-time job, so I had  
both time to come up to speed, no distractions, and was working  
directly with people who were already experts. That is a very  
different learning environment from a spare time, on-your-own method  
of learning.


-- Greg

On May 25, 2008, at 1:18 PM, Erik Buck wrote:

I have been working with Cocoa and its predecessors for so long that  
I can't remember how long it took me to learn to use the  
frameworks.  One of my first non-trivial NeXTstep applications was a  
Tetris game.  It was about 1989 or early 1990 when a friend was  
admiring my NeXT cube.  She asked if there was a Tetris game, and  
when I said there wasn't, she said, well what kind of computer  
doesn't have Tetris?  It must be useless.


I spent two days with little sleep - maybe 40 hours straight- and  
coded up a Tetris game.  Of course, it was 2 bit gray scale, but it  
had synthesized "stringed instrument" background music, and you  
could supply your own images to be used as backgrounds.  In fact,  
every user could have different background images.  My friend said  
she wasn't impressed, but she spent about two hundred hours playing  
the game that summer.  She asked me to enhance the game so that the  
music tempo increased with the game level and sliding or rotating  
blocks had their own sound effects that were mixed with the  
background music.  Stacking up blocks transposed the music to  
different keys.  At first she played the game to get the highest  
score in our social circle.  Later she played the game to see what  
kind of cool "music" she could produce.  NeXT's DSP was was very  
cool, and the examples I used to get started later became MusicKit  
(I think).  I never was able to digitally record her music in real  
time  though...


So, anyway, I implemented lots of student projects with Objective-C  
and the NeXT.  I wrote a recursive descent parser for my compilers  
class.  There was a separate class for each scan-able token.  A  
class method +newWithPartialString:(const char*) nextPosition:(int  
*)nextIndexPtr  returned an instance of whatever token subclass  
could make the longest match.  Then each token know about the  
previous and next tokens and contained the applicable grammar rules  
to identify syntax errors along the lines of "I am not allowed to  
follow my predecessor so there is a syntax error at my position..."   
My professor thought it was really nifty.  Everybody else in the  
class used Pascal or Ada to implement their parsers as direct copies  
of the textbook examples.


By the time graduated in December 1991, I was thoroughly familiar  
and comfortable with most NeXT APIs including the Unix layer and  
Display Postscript.  I would say I went from newbie to advanced in  
about two years or maybe a little less while working and attending  
school full time.  I used Interface Builder and File's Owner and  
First Responder and targets and actions  and delegates.   Since then  
I have been along for the ride with the separation of FoundationKit,  
DBKit, EOF, 3DKit, NeXTtime, MusicKit, Renderman, the transition to  
Openstep, the years in the wilderness with Apple... Of course, there  
is a lot more to learn now, or is there really?




So this is a survey:
For those who consider themselves intermediate to advanced Cocoa  
programmers, how long was the journey from newbie to competent and  
from competent to advanced ?  What percentage of your time did you  
dedicate over how many months ?


Maybe we can establish a standard distribution of learning time  
required.  Just having a basis to set expectations might help future  
newbies.








___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list

Re: Detecting a resize window event?

[Greg Titus]

Assuming you are asking because you need to do drawing differently  
based on whether resizing is taking place, see here:


http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaPerformance/Articles/CocoaLiveResize.html

You'll want to override the -viewWillStartLiveResize and - 
viewDidEndLiveResize methods.


Hope this helps,
- Greg

On May 25, 2008, at 4:00 PM, Graham Reitz wrote:


How do you detect a resize event?

I can see that lockFocus and drawRect are getting called.

Is there a method to help determine if the user is resizing the  
window?


thanks,
graham
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Detecting a resize window event?

[Greg Titus]

In your NSView:

- (void)viewDidMoveToWindow
{
	[[NSNotificationCenter defaultCenter] addObserver:self  
selector:@selector(windowResized:) name:NSWindowDidResizeNotification  
object:[self window]];

}

- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
[super dealloc];
}

- (void)windowResized:(NSNotification *)notification;
{
NSSize size = [[self window] frame].size;

	NSLog(@"window width = %f, window height = %f", size.width,  
size.height);

}

Hope this helps!
- Greg

On May 25, 2008, at 5:49 PM, Graham Reitz wrote:
I don't think I am presenting my question well enough.  Let me try  
again.


I have a custom NSView object with a NSOpenGLContext in it.  When  
the window is resized how do you capture the window height and width  
(not the derived NSView object's height/width, it doesn't change) so  
I can adjust the view port appropriately.


Assume that I need a custom NSView.  It seems this behavior comes  
for free when inheriting from NSOpenGLView.


Posters often suggest that I go to the online apple docs and figure  
it out.  I am looking online after I make all these posts.  The  
majority of the time I get a response sooner than I figure it out.
I am on the steep slope of the learning curve and will be off in  
short order.


Thanks again for all the help.

-graham


On May 25, 2008, at 6:14 PM, Scott Andrew wrote:


For a window:

If you are registered as the delegate you can handle the  
windowWillResize:toSize: call to get called just before the  
reisize. Or, If you want the message after the resize, you can  
handle the windowDidResize: call.


For a view:

You can register to receive the NSViewFrameDidChangeNotification  
notification. This is called after the frame of the view has been  
changed. I don't know of a message to track it real time.


Scott

On May 25, 2008, at 4:00 PM, Graham Reitz wrote:


How do you detect a resize event?

I can see that lockFocus and drawRect are getting called.

Is there a method to help determine if the user is resizing the  
window?


thanks,
graham
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/scottandrew%40adelphia.net

This email sent to [EMAIL PROTECTED]




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Good mouse tracking design for dynamic view?

[Greg Titus]

On Jun 26, 2008, at 11:56 AM, Douglas Davidson wrote:



On Jun 26, 2008, at 11:20 AM, Nathan Vander Wilt wrote:

So it seems I need to do more bookwork myself, but I'm wondering  
which direction others would recommend:
a) Set up a single tracking area for the whole view, and perform  
all my own hit testing every time the mouse moves.
b) Keep the per-item tracking areas, but perform my own testing in  
the edge cases when active (mouse has entered but not exited)  
tracking areas are getting reset.


Even though it seems like I'd be reimplementing something Cocoa  
already offers, I'm leaning towards option A: I'm not sure if I'll  
be able to foresee all the edge cases, and I'd be reinventing half  
the hit testing code there anyway.
Does it sound reasonable from a maintenance and performance  
perspective to handle the mouse on my own inside my view? It seems  
like the tracking Cocoa provides is designed for more static  
content, or am I just missing the intended "Option C" recipe for my  
scenario?


If your hit testing is not too time-consuming, it is quite possible  
to do it on every mouse move.  Individual tracking areas are  
convenient if you don't have your own hit-testing mechanism set up,  
but if you are able to do it efficiently yourself, you certainly may  
do so.


What we tend to do when we do hit-testing via mouse move is to also  
calculate and cache the rect within which the current state is valid.  
So then at the very top of your hit testing you can do a quick test:  
is the mouse still within the same area it was before? If so, don't  
need to do anything and return quickly. This can make hit testing a  
lot more efficient if you have complicated content.


- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Delete action from variety of key presses

[Greg Titus]

Hi Nathan,

By overriding -keyDown: and not calling [super keyDown:keyEvent], you  
have stopped your view from actually processing the keys any further.  
That's why you aren't getting to either of the delete methods.


Hope this helps,
- Greg

On Jul 7, 2008, at 4:59 PM, Nathan Vander Wilt wrote:

The Cocoa Text Bindings system already translates keys and key  
combinations into invocations of NSResponder methods. 


So, what you need to do is determine which methods those keys are  
already mapping to, override those methods in the appropriate place  
in your responder chain (e.g. on your custom view or application  
delegate), and have them all invoke some common method to do what  
you want.


Thanks, I forgot to mention that I tried overriding some of those  
action methods. However, I couldn't get them to fire.


If I implement:

- (BOOL)acceptsFirstResponder {
return YES;
}

- (void)keyDown:(NSEvent*)keyEvent {
(void)keyEvent;
printf("key event received\n");
}

- (void)deleteBackward:(id)sender {
(void)sender;
printf("delete backward received\n");
}

- (void)deleteForward:(id)sender {
(void)sender;
printf("delete forward received\n");
}


...and then press delete or forward-delete, I only ever get "key  
event received". According to the chart at http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/chapter_2_section_3.html#/ 
/apple_ref/doc/uid/1060i-CH3-SW10, it looks like the event  
should flow all the way down to the "Key Action?" conditional, and  
since it's a bound key binding I thought I should get the "Yes: Send  
action message to first responder" path.


However, on further investigation, I see that this is just a  
"potential" path diagram, and seems to be an example for if the  
first responder view is a text one, which mine will rarely be. Under  
what circumstances will the Cocoa Text Bindings system convert  
keypresses to the "text" actions, so that a non-NSResponder (ie, a  
window/app delegate) can perform the action?


thanks,
-natevw
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Remove overlap on NSBezierPath

[Greg Titus]

On Jul 14, 2008, at 4:24 AM, Graham Cox wrote:
Right now I use GPC and (optional) curve fitting. It keeps the  
curves in terms of their appearance but can greatly alter the number  
and location of the control points. I don't like it much either -  
one reason I'd love there to be a great solution built-in.  
Unfortunately I'm no mathematician and so I haven't been able to  
come up with a great way to do it from first principles, nor found  
any suitable code out there until...


I just had a short look at the Omni-OAExtensions. There are some  
functions to find intersections of paths, so I have to build my own  
merging routine out of it, right?



...this. I hadn't seen those before either. It looks as if they've  
given away the hardest part, finding the intersections and crossing  
directions of each intersection. On top of that you can build the  
set operations. I plan to have a very good look at doing this for DK  
as soon as I can - if it can be made to work it will be a much  
better solution than curve fitting. Props to the Omni guys for being  
prepared to give away this code like this :)


You're welcome!

The set operations are still quite a bit of work even given all that  
as a substrate. Beware of the complications of shared line/curve  
segments between the two paths (places where they overlap for more  
than just a single point at a time). That makes things quite a bit  
more difficult.


- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Remove overlap on NSBezierPath

[Greg Titus]

Thanks!

- Greg

On Jul 14, 2008, at 4:24 AM, Graham Cox wrote:


On 14 Jul 2008, at 7:48 pm, Georg Seifert wrote:


Hello,

Thanks for you replies.

To clarify: I need it in a small drawing app, where you can draw  
shapes and then you should be able to combine them. There is no  
outline but the winding is quite important (there may be  
overlapping, clipping and self intersecting parts).


If you don't need to draw the stroke, things maybe much easier (you  
could keep a list of contributing paths as part of some object of  
your own device for example).


I did found DrawKit but as I need to keep the curves, this doesn’t  
seem to be an option.



Right now I use GPC and (optional) curve fitting. It keeps the  
curves in terms of their appearance but can greatly alter the number  
and location of the control points. I don't like it much either -  
one reason I'd love there to be a great solution built-in.  
Unfortunately I'm no mathematician and so I haven't been able to  
come up with a great way to do it from first principles, nor found  
any suitable code out there until...


I just had a short look at the Omni-OAExtensions. There are some  
functions to find intersections of paths, so I have to build my own  
merging routine out of it, right?



...this. I hadn't seen those before either. It looks as if they've  
given away the hardest part, finding the intersections and crossing  
directions of each intersection. On top of that you can build the  
set operations. I plan to have a very good look at doing this for DK  
as soon as I can - if it can be made to work it will be a much  
better solution than curve fitting. Props to the Omni guys for being  
prepared to give away this code like this :)




cheers, Graham___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Blue lines

[Greg Titus]

Interface Builder actually makes a couple of windows to do that. One  
wide window for the horizontal part of the line, and another tall and  
thin window for the vertical part. The positions of the windows change  
as your mouse moves, and they have simple views inside that draw  
basically just blue over their entire contents.


Hope this helps,
- Greg

On Jul 15, 2008, at 5:31 PM, Andrew Thompson wrote:

How do Interface Builder and Quartz Composer draw the blue line  
connections

from object to object?
I have been looking through the APIs, but I can't find anything that  
looks

right.

I thought of just drawing my own line on a custom view (shouldn't be  
that
hard), but interface builder manages to do it between objects that  
aren't

connected by ANY view, and I am not sure how to do that.

I am trying to build an HTML GUI editor.

Thanks in advance!

~Andrew
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Tabbed preference panels

[Greg Titus]

You may also want to take a look at OmniAppKit's OAPreferences  
implementation: .


Hope this helps,
- Greg

On Aug 22, 2008, at 9:29 AM, Sumner Trammell wrote:


Hi, I'm working on a preferences panel. I want to build a compound
panel like the kind seen in most mainstream apps today: a toolbar on
top with "tabbed" view switching. The panel changes its appearance
depending on which 32x32 toolbar icon you have selected.

I'm not sure where to start. Looking for examples, I've looked in
Safari's app bundle resources dir, and I see that Safari uses separate
nibs per preferences tab.  When I open one of these nibs, I see a
window object, and that window object has the preference tab's layout.
Pretty straightforward. Of course, Safari is not open source, so I
can't go any further and see how this design works.

Looking at the source for Transmission, I see they've taken a
different approach, which is to have one PrefsWindow.xib, and in that
xib, a number of View objects, one for each tab. Open the view object
representing a particular preference tab, and you see its layout. I
have not studied the Transmission source yet to see how they make it
all work.

So we have at least 2 accepted ways of doing the tabbed preference
panel thing. But I'd like a better understanding of the hows and why's
overall. Can anyone point me to some Cocoa programming guide docs, or
programming topics docs, on tabbed preference panels? (Are they even
called "tabbed preference panels?")


Thanks,
-s
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: array segment

[Greg Titus]

Hi James,

It sounds like you want -subarrayWithRange:

Hope this helps,
- Greg

On Sep 1, 2008, at 8:37 AM, James Maxwell wrote:


Hello All,

Is there an obj-C equivalent to Java's System.arraycopy() which will  
allow me to easily copy a segment of an NSArray into a new array?


If so, a one-liner example would be very much appreciated.

I looked at -getObjects:range:, but I'm not sure if this is the  
right thing since it returns void... Do I provide an array to use as  
"aBuffer"?


J.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: How to track Slider's value while dragging the mouse?

[Greg Titus]

Hi Oleg,

The property you want is setContinuous:YES, or check the "Continuous"  
checkbox in Interface Builder. (The method is defined on NSSilder's  
superclass, NSControl.)


Hope this helps,
- Greg

On Sep 24, 2008, at 7:08 AM, Oleg Krupnov wrote:


NSSlider only changes its value (and fires its target/action and the
binding) when the user releases the mouse button.

Whereas I need to track the current value of the slider while the
mouse is being dragged, with the button held down -- like thumbnail
size in iPhoto.

I can't believe I have to implement my own slider to get this
behavior. Neither I can find the property of NSSlider that would make
it behave like this. Am I missing something?
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: cocoa http client library

[Greg Titus]

Hi Sandeep,

Look some more. :-)

NSMutableURLRequest, which is the request you pass to the  
NSURLConnection should allow you to set whatever custom headers you  
need.


- Greg

On Mar 28, 2008, at 11:27 AM, C Sandeep wrote:

Hi Jens,

Thanks. I looked at NSURLConnection docs. It doesn't allow me to set
certain custom headers, while connecting to the http server. Are there
any other libraries that you recommend ? Thanks.

- Sandeep

On Fri, Mar 28, 2008 at 2:09 PM, Jens Alfke <[EMAIL PROTECTED]>  
wrote:


On 28 Mar '08, at 10:59 AM, C Sandeep wrote:


Im trying to access a custom http server via my cocoa app. I have
looked at various libraries, mainly CFNetwork, available from apple,
however Im not sure which one of them to use(Im comfortable using
Objective-C over C) .


Then why not use NSURLConnection, which is in the Foundation
framework? That's the standard way to implement HTTP client
functionality in Cocoa apps.

—Jens

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa-dev Digest, Vol 5, Issue 600

[Greg Titus]

On Apr 13, 2008, at 12:40 PM, Alex Curylo wrote:
No, I can personally assure you that exact practice has led me to  
finding many dozens -- quite possibly several hundreds by now  
actually -- of 'calling methods of a deleted object' type bugs in C+ 
+ code, particularly game code I port from Windows, which somehow  
always seems to have been written by semi-literate chimpanzees on  
crack. And perhaps I am unfair to the chimpanzees here.


As a former game porter, let me offer my condolences here. I know  
exactly what you mean.


It does seem that class of problem is much less likely to arise with  
Objective-C object references (I'm still fairly new to this Cocoa  
thing) but as long as I still work with any C++ objects or raw  
pointers, I'm going to consider that "set things up so anything  
accessing this object's memory after I'm done with it promptly  
causes an access violation" is a valuable habit -- nay, essential  
practice -- in properly defensive programming. Autoptrs and the like  
help, but they're not foolproof. Stands to reason that the retain/ 
[auto]release paradigm isn't completely foolproof either, although  
it does seem pretty resistant to commonly accepted levels of foolery  
so far.


The big difference is that in Objective-C, trying to send a message to  
nil results in a no-op instead of an access violation, so your  
defensive C++ practice is actually going to tend to mask those same  
errors in Objective-C and make them harder to track down.


Hope this helps,
- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Stale Objective-C object pointer detection

[Greg Titus]

You want to just leave the pointer alone and turn on NSZombiesEnabled  
when you run your app. Then instead of the object on the other end of  
the pointer being freed, it'll point to a special zombie class which  
will helpfully raise you an exception when you try to send it a  
message. This has the added advantage of being able to more easily see  
what the pointer _used_ to point to, because the zombie has  
information about the original class name.


- Greg

On Apr 13, 2008, at 1:35 PM, Alex Curylo wrote:


On 13-Apr-08, at 1:06 PM, Greg Titus wrote:
The big difference is that in Objective-C, trying to send a message  
to nil results in a no-op instead of an access violation, so your  
defensive C++ practice is actually going to tend to mask those same  
errors in Objective-C and make them harder to track down.


*smacks forehead*

Yeah, now that I actually think about it, that would be the effect,  
wouldn't it. Just hadn't made the connection up 'til now, somehow.  
Thank you.


OK, then, what would an equivalently useful value to set a released  
Objective-C object pointer/ivar to in order to cause any subsequent  
access of it to stop the program immediately? 0xDEADBEEF perhaps?


--
Alex Curylo -- [EMAIL PROTECTED] -- http://www.alexcurylo.com/

Programming is like sex...
One mistake and you support it the rest of your life.






___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: -charactersIgnoringModifiers and the shift key

[Greg Titus]

I think you'd ask the NSEvent for its -keyCode, then pass that key  
code to UCKeyTranslate() with all the modifier key state (including  
shift) turned off in order to get a unicode string for what that key  
would mean if the user hadn't been pressing any modifiers.


Hope that helps,
- Greg

On Apr 17, 2008, at 9:02 AM, John Stiles wrote:
I have an NSEvent and I need to know what key the user has pressed,  
minus any of the modifiers. NSEvent -charactersIgnoringModifiers  
seems like a good place to start, but it has one serious flaw—it  
does not ignore the Shift key. So, for instance, it won't change ~  
to `, ! to 1 or { to [.


I need this for my app, because I am trying to implement  
functionality where the user can add custom hotkeys to buttons or  
menu items—this is a requirement of the design, it works well  
conceptually, and it works well on the Windows side. On the Mac  
side, however, there are lots of problems where AppKit will get  
confused when two items have similar hotkeys (such as rdar://5848023  
[NSResponder] Problem with button hotkeys and shift modifier, which  
I posted about here before) and the end result is that it, with some  
key combinations, AppKit sends the action message to the wrong menu  
item or button.


To work around these issues, when the user presses a hotkey, I am  
looking at [NSApp currentEvent] to see what key is actually pressed,  
and given that info I can easily figure out what button or menu item  
needs to be invoked on my own. To do this, I use [event  
charactersIgnoringModifiers] and [event modifierFlags] and then  
checking a dictionary of all the hotkeys. For most things, this  
works well. Where it falls down is shifted punctuation, because my  
dictionary has the hotkey listed as "cmd+shift+[", but the event is  
telling me that the user pressed "cmd+shift+{". Of course, "cmd+shift 
+{" isn't in my table at all, so it doesn't work.


I could bite the bullet and hard-code the unshifted versions of all  
the keys on the US keyboard, and that would make Americans happy,  
but I expect we will eventually need to "do the right thing" so I  
need to actually get the unshifted character out of this NSEvent. So  
how can this be done? Any pointers would be helpful.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Hyperlinks

[Greg Titus]

Hi Matt,

You need to use an NSTextView here rather than an NSTextField. The  
behavior you are seeing is because an NSTextField is not 'active'  
until clicked upon, and then it gets the window's field editor (which  
is a shared NSTextView used by all fields on the window), and places  
that view on top of the text field and uses it to edit the text. It is  
NSTextView that handles the link hand cursor, and et cetera.


Hope this helps,
- Greg

On Jan 8, 2009, at 4:02 AM, Matthew Morton wrote:


Hi all,

I have a NSTextField in Interface Builder that is quite large and  
includes a number of lines, one of which I want to be a hyperlink.   
I have bound the value of the NSTextField to an NSAttributedString  
in a custom class and set attributes for NSLinkAtributeName,  
NSForegroundColorAtributeName, and NSUnderlineStyleAttributeName.   
Back in Interface Builder I have set the NSTextField to be  
selectable, allow rich text, and the control state enabled.  When I  
build and run my app the text appears as expected but there is no  
'finger-style' cursor when I hover over the hyperlink, just the  
'text-edit' style one until I click on the textfield.  At this point  
the text changes size and the hyperlink becomes clickable.


Anybody have any ideas on what I am doing wrong and any pointers to  
help me resolve this issue.


Thanks,

Matt.
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to g...@omnigroup.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: What's the most cocoa-ey pattern for this?

[Greg Titus]

Hey Wave,

Is the Sequence delegate interested in all Element/Markers moved into  
and out of? Or only some small subset?


If the former, you really just want something like:

NSNotificationCenter* ctr = [NSNotificationCenter defaultCenter];
SEL s = @selector(enteredElement:);
[ctr addObserver:delegate selector:s name:XXTimeMovedForward  
object:sequence];


and then make the Sequence include the element/marker info as part of  
the notification user info:


NSDictionary *info = [NSDictionary  
dictionaryWithObjectsAndKeys:markerArray, @"XXMarkers", element,  
@"XXElement", nil];
[[NSNotificationCenter defaultCenter]  
postNotificationName:XXTimeMovedForward object:self userInfo:info];


The delegate then examines the user info of the notification it  
receives to get the list of Markers that got entered and the Element  
entered (if any).


If your delegates don't want to see all those notifications and are  
only interested in a small subset of the Elements/Markers, then you'll  
probably want to have your Sequence have its own notification center,  
and have delegates sign up with that center to get notified of  
Elements/Markers. Multiple Sequences then have different centers,  
which would support having the same marker or element in more than one  
sequence (you didn't mention if this was a requirement or not, but it  
wouldn't be a problem)...


Delegate then looks like:

NSNotificationCenter* ctr = [sequence notificationCenter];
SEL s = @selector(enteredElement:);
[ctr addObserver:delegate selector:s name:XXTimeMovedForward  
object:elementInterestedIn];


and the notifications can just be sent from the Sequence via:

[[self notificationCenter] postNotificationName:XXTimeMovedForward  
object:elementMovedInto];


Hope this helps!

- Greg


You'll probably want to have your Sequence have its own


On Jan 8, 2009, at 2:59 PM, Michael B Johnson wrote:

So I have a "Sequence" of "Elements", ordered by "Time".  Elements  
cannot overlap each other, they can only be strung in a temporal  
line, with no gaps (i.e. the end of one element abuts another,  
unless its at the front or end).


In addition to these Elements, we can drop "Markers" on this  
sequence, where the Markers can be attached to a single point in  
Time, or some contiguous range of Time.  Multiple Markers could be  
on the same point in Time, or overlap each other in Time.


Let's say Time can move forward, move backwards, or instantaneously  
jump to a point in Time.


This Sequence has a delegate, that would like to express interest in  
the following:


(1) when the "current time" moves forward into the beginning of an  
Element or Marker.
(2) when the "current time" moves backward into the end of an  
Element or Marker.
(3) when the "current time" is the same as a Marker attached to a  
single point in time.


With that information, we would know what Element is "active", and  
what Markers might be "active".


So what info do we need?   Assuming a Sequence has some delegate,  
that delegate could register the Sequence to be told when any of  
those three events happens.


Let's say we use as our unique identifier the following info in a  
dictionary:


- sequence
- time value
- time direction (forward, backwards, impulse (i.e. neither, it just  
appeared there))

- object (i.e. Element or Marker that this Time value concerns

so the delegate registers to get notifications from the sequence by  
(and this is where the pattern is weird):


NSNotificationCenter* ctr = [NSNotificationCenter defaultCenter];
SEL s = @selector(enteredElement:);
NSDictionary* dict = [NSDictionary  
dictionaryWithObjectsAndKeys:sequence, @"XXSequence", time,  
@"XXTimeValue", direction, @"XXTimeDirection", element,  
@"XXElement", nil];
[ctr addObserver:delegate selector:s name:XXTimeMovedForward  
object:dict];


what's weird about this is that we're handing in a *dictionary* that  
contains the object that will send out this notification, not the  
object itself.


That's weird, right?  But you see what I'm trying to do?  Is there  
some other pattern here I'm missing?


Thanks in advance for any help.


--> Michael B. Johnson, PhD
--> http://homepage.mac.com/drwave (personal)
--> http://xenia.media.mit.edu/~wave (alum)
--> MPG Lead
--> Pixar Animation Studios

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to g...@omnigroup.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:
http://lists.apple.com/mailman/optio

Re: What's the most cocoa-ey pattern for this?

[Greg Titus]

On Jan 8, 2009, at 3:28 PM, j o a r wrote:



On Jan 8, 2009, at 2:59 PM, Michael B Johnson wrote:

This Sequence has a delegate, that would like to express interest  
in the following:


(1) when the "current time" moves forward into the beginning of an  
Element or Marker.
(2) when the "current time" moves backward into the end of an  
Element or Marker.
(3) when the "current time" is the same as a Marker attached to a  
single point in time.


With that information, we would know what Element is "active", and  
what Markers might be "active".



So this is the goal: To be able to track the active element and  
marker, to be notified when elements and markers are activated? It  
seems to me that you're not really talking about delegation, but  
rather observation (?), so how about using KVO (pseudocode &  
incomplete):


@interface Sequence
@property (readonly) Element *activeElement;
@property (readonly) Element *activeMarker;
@property (readonly) Direction currentDirection;
@end

Your observers would add themselves as observers for the properties  
that they are interested in, and then get notified as they changes.  
I think that these three properties would be all that you need to  
satisfy your #1 - #3 above.


Except that there can be multiple active markers (they can overlap).  
But you could change that to:


@property (readonly) NSMutableSet *activeMarkers;

And then continue to use KVO as joar is proposing...

- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to add a -(unsigned long long)unsignedLongLongValue method to NSString

[Greg Titus]

On Jan 11, 2009, at 10:48 AM, Kyle Sluder wrote:

On Sun, Jan 11, 2009 at 2:50 AM, Ken Thomases   
wrote:
Sure it would.  Both unichar (as typedef'd) and char are integer  
types in C.
'7' is another way of writing a number, although not the number 7.   
Which
number depends on the encoding of your source file, but in most  
modern
systems it would be ASCII or UTF-8.  (I don't know if, for example,  
EBCDIC
is still used on any modern systems.)  In either of those, '7' is  
the same

as 0x37 or 55.


Except I recall that Cocoa often uses UTF-116 or UCS2 internally...


Cocoa does use UTF-16 as the encoding for its unichar type in  
NSStrings, but the low 7-bits of UTF-16 (characters 0-127) are  
identical to the ASCII encodings, so you can cast (char)'7' or  
(unichar)'7' and get 0x37 either way and it'll be interpreted as the  
'7' character in a string as you would expect.


Hope this helps,
- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ObjC in time-critical parts of the code

[Greg Titus]

Jens,

The point of what people are trying to tell you is that the result you  
are getting (3ms per empty Objective-C call) is approximately 500,000  
times longer than the time you ought to be getting (5-6ns). If an  
Objective-C message send took 3 milliseconds (333 method calls per  
second!), no useful software could ever have been written in the  
language.


From your guess at the end of your post, ("message dispatcher  
servicing") it is pretty clear that you don't really know what is  
going on. Blaming the language environment for performance behavior  
that is vastly different than any of the rest of us have ever seen is  
not likely to be useful to you at all. There is something else  
happening with your application.


We're just trying to save you the effort of rewriting and then  
discovering that nothing about the timing problem has changed, because  
you have misidentified the problem.


Good luck,
 Greg

On Jan 15, 2009, at 11:20 PM, Jens Bauer wrote:


Hi Chris,

The rendering is not choppy in every frame.
I'm already using Shark often (now it's a bit easier just jusing  
Activity Monitor, because it's always running anyway).
I know the Microseconds() call by heart, and there's nothing wrong  
with it; it does work very well, and does not use much CPU-time.
I doubt that the performance tools are microsecond accurate; in my  
case, it's important to go down to the millisecond level, since I'm  
about to go 60 FPS, and would like my entire operation to stay at  
least below 5ms (actually it uses 0.4 ms).



Love,
Jens

On Jan 16, 2009, at 01:32, Chris Hanson wrote:

Rather than cobble together your own measurement infrastructure  
using old Carbon calls and NSLog, I recommend in the strongest  
possible terms that you measure your application's performance  
using purpose-built profiling and analysis tools like Shark and  
Instruments.


Performance measurement may seem simple at first glance but it can  
be very subtly hard to get right. That's why tools for it are  
supplied with Xcode, and why they need explicit support from the  
operating system.


-- Chris

On Jan 15, 2009, at 2:16 PM, Jens Bauer   
wrote:



Hi all,

I just want to let you know that I discovered I did a terrible  
mistake today.
In other words: you don't have to learn from your own mistakes, if  
you can learn from mine. =)


I investigated this, because my rendering was choppy.

The code...

- (void)renderObject
{
}

- (void)renderAll
{
 UnsignedWideus;
 doubletime;

 Microseconds(&us);
 time = ((double) us.hi) * 65536.0 * 65536.0 + ((double) us.lo);
 [self renderObject];

 Microseconds(&us);
 time = ((double) us.hi) * 65536.0 * 65536.0 + ((double) us.lo) -  
time;


 NSLog(@"time:%.3fms", time * 0.001);
}

..often used around 3ms for the empty method "-renderObject".
It gave me the terrible result of up to 21ms spent in the empty  
method!



-So I'd like to let you know that it's sometimes good to think "do  
I really need this method?"
I will be rewriting around 8 of my large files for doing some  
rendering, so they will be using C-routines instead of ObjC  
methods, since I'm using them in a real-time environment.


My guess is that the message dispatcher probably needs to do  
something else than servicing *my* application, so I believe it's  
the nature of the environment, not a bug.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to g...@omnigroup.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSMutableArray comparator; sorting on insert

[Greg Titus]

On Jan 16, 2009, at 8:27 AM, David Harper wrote:


Hello,

I have written a comparator that returns an NSComparisonResult based  
on the comparison of two objects as required for


[(NSMutableArray *)someArray  
sortUsingSelector:@selector(theSelector:)]


Now, I want this array to remain sorted after each insert.  For now  
I am inserting, then sorting, but this is not ideal.  Is there a way  
to perform an insert using the same selector to find the correct  
index before inserting?


Bill Bumgarner asked good questions about whether you really need this  
or not, but if you do need it, another thing that you could do would  
be to go look at OmniFoundation , which  
includes a category on NSMutableArray for keeping arrays sorted:


// Maintaining sorted arrays
- (void)insertObject:(id)anObject inArraySortedUsingSelector: 
(SEL)selector;
- (void)insertObject:(id)anObject inArraySortedUsingFunction: 
(NSComparisonResult (*)(id, id, void *))compare context:(void *)context;
- (void)removeObjectIdenticalTo:(id)anObject  
fromArraySortedUsingSelector:(SEL)selector;
- (void)removeObjectIdenticalTo:(id)anObject  
fromArraySortedUsingFunction:(NSComparisonResult (*)(id, id, void  
*))compare context:(void *)context;


(These methods all use binary searches across the array contents.)

Hope this helps,
	Greg 
___


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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ObjC in time-critical parts of the code

[Greg Titus]

On Jan 18, 2009, at 5:13 PM, Justin Carlson wrote:



Jean-Daniel Dupas wrote:
>
> Each time you use KVC/KVO.

Hi Jean-Daniel,

Sorry if I misreading this, your response was short - it could mean  
a few things. I am inclined to think you were responding to my  
question "how often do your subclasses rewrite getters/setters?".



Justin,

Jean-Daniel was referring to the way that Apple has implemented  
automatic KVO compatibility. The first time that someone tries to  
observe an object of class X with accessor -foo, and -setFoo:, the  
framework makes a dynamic subclass of your class X called something  
like X_KVO, and reimplements -setFoo: to be something like:


- (void)setFoo:(id)aFoo
{
[self willChangeValueForKey:@"foo"];
[super setFoo:aFoo];
[self didChangeValueForKey:@"foo"];
}

It then replaces the original X class with the X_KVO class (using a  
mechanism like -poseAs:) so that all existing X's are now X_KVO's.  
This automatic and dynamic subclassability of getters/setters makes  
KVO a lot easier to use, because a lot of it happens for you without  
any effort on the programmer's part. And, of course, this wouldn't be  
possible had the setter been defined non-virtually in a language like C 
++. So here's an example of the dynamism being useful for even the  
smallest and simplest of methods (that would normally be inlined in a C 
++ framework design).


Hope this helps,
- Greg

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Still can't get NSFormatter working....

[Greg Titus]

How about take a step back. Is 'nameField' hooked up in IB correctly  
so that the formatter is actually being set on a real field? You might  
try logging both 'nameField' and '[nameField formatter]' right after  
your code to assign it.


Hope this helps,
Greg

On Feb 17, 2009, at 7:57 AM, Todd Freese wrote:

Still can't this NSFormatter to work. It does not seem to be getting  
called from my NSTextField.


Here is the formatter:

@implementation FileNameFormatter

- (NSString *)stringForObjectValue:(id)anObject
{
if ([anObject isKindOfClass:[NSString class]]) {
NSString *sourceString = [NSString stringWithString:anObject];
return sourceString;
} else {
return nil; 
}   
}

- (BOOL)getObjectValue:(id *)obj forString:(NSString *)aString  
errorDescription:(NSString **)error

{
if (aString != NULL) {
*obj = [NSString stringWithString:aString];
return YES;
} else {
return NO;
}
}

- (NSAttributedString *)attributedStringForObjectValue:(id)anObject  
withDefaultAttributes:(NSDictionary *)attributes

{
return nil;
}

- (BOOL)isPartialStringValid:(NSString **)partialStringPtr
   proposedSelectedRange:(NSRangePointer)proposedSelRangePtr
  originalString:(NSString *)origString
   originalSelectedRange:(NSRange)origSelRange
errorDescription:(NSString **)error
{
NSLog(@"formatter called");
return NO;
}

@end

And here is how I assign it to the NSTextField:

FileNameFormatter *fileNameFormatter = [[[FileNameFormatter alloc]  
init] autorelease];

[nameField setFormatter:fileNameFormatter];

Any ideas?

Todd Freese




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to g...@omnigroup.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Greg Titus]

Brian,

The way to handle this is to _not_ respond to memory warnings in  
subclasses (at least not for the purposes of view outlet handling -  
there may be other non-view memory you want to free up in response to  
a memory warning). Instead, implement -setView: in your  
UIViewController subclass, and release outlets when the argument is  
nil. For example:


- (void)setView:(UIView *)aView;
{
if (!aView) {
self.anOutlet = nil;
self.anotherOutlet = nil;
self.thirdOutlet = nil;
}
[super setView:aView];
}

This will correctly clean up all of your outlets whenever the  
UIViewController unloads its view, and not otherwise.


Hope this helps,
- Greg

On Nov 18, 2008, at 10:01 AM, Brian Stern wrote:


OK Erik, I'll bite.  What you describe above is correct as far as it  
goes.  However, when you say all the memory management is handled in  
one place, of course it's two.  The object has to be released.  The  
normal place to release objects is in their owner's dealloc method,  
and this also applies to outlets.


However, UIViewController has the ability to unload its view outlet  
in response to a memory warning.  Any subclass should also release  
its outlets in response to the memory warning, if the base class  
releases its view, but not otherwise.  So now there are three places  
to manage the memory of these outlets. The problem is that the base  
class doesn't always release its view in response to a memory  
warning and as far as I can tell the subclass has no clean way of  
telling if the view will be released or has been released.  That's  
the problem.


--
Brian Stern
[EMAIL PROTECTED]



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to [EMAIL PROTECTED]


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Greg Titus]

On Nov 19, 2008, at 7:00 AM, Brian Stern wrote:


This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is in  
many respects academically unsatisfying.
(b) For non-top-level-object, specify an assign attribute for the  
property -- and risk dangling pointers.


The override of setView is very similar to the viewDidUnload  
callback that I proposed as a solution for this.  It has its own  
further issues.  UIViewController calls [setView:nil] from its  
dealloc method so the subclass has to be prepared for this.  What  
I've done is to add all the public retain properties for all the  
outlets.  Additionally I've added a


-(void)releaseOutlets

method that uses the properties and sets them all to nil.  I call  
this method from my subclass's dealloc method and setView:  
override.  That way I only have one place to write the code that  
releases all the outlets.



Brian,

What is your reason for having a separate -releaseOutlets method to do  
this?


The sample that I gave (calling self.anOutlet = nil; when the argument  
to -setView: is nil) will do whatever releasing is required (if the  
anOutlet property is "retain") or simple zeroing the pointer (if the  
anOutlet property is "assign"). The fact that UIViewController calls - 
setView:nil from its -dealloc is just additional convenience. All of  
your outlets get cleaned up at the same time as the UIViewController  
cleans up the main view. There is no need to write any outlet related  
code in your -dealloc at all, since it is all handled via the  
superclass and the -setView: override.


In short, the way I think of it, -setView: _IS_ the one centralized  
place that deals with all view-related pointers, including all  
outlets. And UIViewController calls -setView: at all the necessary  
times (setup, memory warning, dealloc), so you don't have to do  
anything else.


Hope this helps,
- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSIndexSet

[Greg Titus]

On Nov 21, 2008, at 7:44 AM, David Blanton wrote:


How would one construct an NSIndexSet containing the indices 2,4,5 ?

I did:

NSRange two = NSMakeRange(2, 1);
NSRange four = NSMakeRange(4, 1);
NSRange five = NSMakeRange(5, 1);
NSRange u1 = NSUnionRange(two,four);
NSRange u2 = NSUnionRange(u1,five);
id indices = [NSIndexSet indexSetWithIndexesInRange:u2];
But, of course, NSUnionRange adds 3 so indices becomes 2,3,4,5.

Or, should one even use NSIndexSet?


The easiest way is to make a mutable index set:

NSMutableIndexSet *indices = [NSMutableIndexSet indexSet];
[indices addIndex:2];
[indices addIndex:4];
[indices addIndex:5];

Hope this helps,
- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: CGPoint and CGRect

[Greg Titus]

On Nov 21, 2008, at 3:19 PM, DKJ wrote:

I want to determine whether a line between two CGPoints in a view  
intersects with a given CGRect. There's nothing in the CGGeometry  
reference that does this specifically, and I don't yet see how to  
use the functions that are there to figure this out.


Before I dust off my Euclid (a rare first edition), has anyone got a  
quick solution? It seems the sort of thing that would be handy in  
many situations.


dkj


BOOL lineIntersectsRect(CGPoint a, CGPoint b, CGRect rect)
{
float lineSlope = (b.y - a.y) / (b.x - a.x);
float yIntercept = a.y - lineSlope * a.x;
float leftY = lineSlope * NSMinX(rect) + yIntercept;
float rightY = lineSlope * NSMaxX(rect) + yIntercept;

if (leftY >= NSMinY(rect) && leftY <= NSMaxY(rect))
return YES;
if (rightY >= NSMinY(rect) && rightY <= NSMaxY(rect))
return YES;
return NO;
}

Here's something I just wrote in email (so may be totally wrong), but  
basically you determine the slope and y-intercept of the line formed  
by the two points, then see where that line's Y-position would be on  
each of the left and right sides of the rectangle. If the Y-position  
hits the left or right edges of the rect, then the line intersects the  
rect.


Note that this is line intersection, not line _segment_ intersection.  
If the line doesn't extend beyond the two points given, you'll need a  
couple extra checks in this code.


Hope this helps,
- Greg
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSLog with %f and comparisons using ==

[Greg Titus]

If what you really want is to see whether the result is the same as %f  
previously printed, then you could always make your array of constants  
an array of constant _strings_ and then compare the strings. Not  
terribly efficient, maybe, but straightforward.


- Greg

On Apr 11, 2009, at 10:26 AM, James Maxwell wrote:

oooh, damn... I was afraid someone was going to say that. I just  
hoped there might be some way to force a float to conform to what  
NSLog %f prints... That seems like it might be a useful function -  
something like pround(aFloat), for "print-round", to force any float  
number to round as the printf %f would round it. Anyway, that's  
obviously not available.


Is there any C function that can compare within a given margin of  
error? (I seem to remember seeing something like that, as some  
point...??)
If not, no big deal - I'll just calculate the comparison within a  
margin of error by hand.


thanks,

J.


On 11-Apr-09, at 10:15 AM, Michael Ash wrote:


On Sat, Apr 11, 2009 at 12:46 PM, James Maxwell
 wrote:

I've got a strange problem.
I have a list of float constants that I need to compare to the  
result of a

new calculation.

I derived the constants by performing the calculation, and  
printing using
NSLog with %f, then just writing down the results in my array of  
constants.
So, the result of the calculation used to derive the float  
constants was run

through NSLog, using the %f token.

Now, when I run the calculation "live" and try to compare to my  
stored
constants, I'm not getting matches. I'm assuming this is because  
the result
of the calculation *isn't* actually what I stored in my constants,  
since the
constants were rounded during the NSLog. So, how do I make sure my  
"live"
calculation returns a value that will be rounded in the same way  
as an

NSLog(@"%f", aFloat)?

That's a confusing question, I know... I hope it makes sense to  
somebody.


Read "What Every Computer Scientist Should Know About Floating-Point
Arithmetic":

http://docs.sun.com/source/806-3568/ncg_goldberg.html

But basically, never depend on floating point calculations to be
exact. As a consequence, never compare floats or doubles for  
equality.

Instead, compute a delta from the desired value, and see if the delta
is within an acceptable range.

Mike
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com

This email sent to jbmaxw...@rubato-music.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:
http://lists.apple.com/mailman/options/cocoa-dev/greg%40omnigroup.com

This email sent to g...@omnigroup.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com