Re: Nil and nil Macro Conflict

[Andreas Grosam]

On May 2, 2012, at 7:46 AM, Don Quixote de la Mancha wrote:

> Are not both Objective-C and C++, as well as Objective-C++
> case-sensitive?  If so, Nil and nil should be different symbols.  

They are case-sensitive. Both, "nil" and "Nil" are different macros defined for 
different purposes in Objective-C:

"nil" is the NULL-pointer for an Object,
"Nil" is the NULL-pointer for a Class (object).

Both effectively map to __DARWIN_NULL  on Mac OS X.


> If they should be, and really are different symbols, but still conflict
> somehow, then you've actually got a different problem than you think
> you do.

To clarify, I don't have a conflict with "Nil" against "nil"  - but a conflict 
with a C++ class name 
nm::nil with nil, and a class name nm::Nil and Nil.

where "nm" stands for an arbitrary qualifier list (namespaces).


> 
> Do Not Let The Sun Go Down Until You've Read John Lakos' excellent
> book "Large Scale C++ Software Design", published by Addison-Wesley.
> Much of what he proposes will contribute to the solution of your
> conflicting symbol problem.

I can believe this is an excellent read and it would certainly add values to my 
knowledge. Though my current problem shouldn't be such an issue and it feels 
it's digressing.  It's just that an Objective-C++ module includes a C++ header 
with symbols "Nil" and "nil" - and there is no other non-Objective-C module at 
all where I could move it to.


> …

Your recommendations and suggestions in the above make certainly sense, and  I 
- as far as I can ensure you - try to follow these proposed guidelines, 
probably even drifting to the other extreme which results in more independent 
files than absolutely necessary. Though, in my current project, all code is 
templates and "header only" - encapsulation of "private symbols" is 
accomplished through namespaces.  (You may even take a look at the sources - 
they are open source ;)  )




Regards
Andreas


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Instruments, how to fix leak in C Lib

[Alexander Reichstadt]

Hi,

through Instruments I found a memory leak outside my code in a pqlib, the 
postgres client library. 

This is what Leaks prints out:

Bytes Used  # Leaks Symbol Name
  84.81 KB 100.0%   48  PQgetResult
  84.81 KB 100.0%   48   pqParseInput3
  80.00 KB  94.3%   40pqResultAlloc
  80.00 KB  94.3%   40 malloc
   4.00 KB   4.7%   4 pqAddTuple
   4.00 KB   4.7%   4  malloc
832 Bytes0.9%   4 PQmakeEmptyPGresult
832 Bytes0.9%   4  malloc


I thought that inside PQgetResult there ought to be a call to pqParseInput3, 
inside of which I would then e.g. find a call to pqResultAlloc. But this is not 
the case. So I thought maybe the compiled version of the C-library I am using 
here does not match the sourcecode I obtained. I recompiled the library from 
source, built the Objective-C framework and rebuilt my app and did a new trace, 
but the leaks' trees were identical also now that I excluded the source for 
error of there being a difference in version.

Please can someone help how to read this?

Cheers
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Instruments, how to fix leak in C Lib

[Jean-Daniel Dupas]

Le 2 mai 2012 à 09:59, Alexander Reichstadt a écrit :

> Hi,
> 
> through Instruments I found a memory leak outside my code in a pqlib, the 
> postgres client library. 
> 
> This is what Leaks prints out:
> 
> Bytes Used# Leaks Symbol Name
>  84.81 KB 100.0%  48  PQgetResult
>  84.81 KB 100.0%  48   pqParseInput3
>  80.00 KB  94.3%  40pqResultAlloc
>  80.00 KB  94.3%  40 malloc
>   4.00 KB   4.7%  4 pqAddTuple
>   4.00 KB   4.7%  4  malloc
>832 Bytes0.9%  4 PQmakeEmptyPGresult
>832 Bytes0.9%  4  malloc
> 
> 
> I thought that inside PQgetResult there ought to be a call to pqParseInput3, 
> inside of which I would then e.g. find a call to pqResultAlloc. But this is 
> not the case. So I thought maybe the compiled version of the C-library I am 
> using here does not match the sourcecode I obtained. I recompiled the library 
> from source, built the Objective-C framework and rebuilt my app and did a new 
> trace, but the leaks' trees were identical also now that I excluded the 
> source for error of there being a difference in version.
> 
> Please can someone help how to read this?
> 

Are you properly using this library ?
If you alloc some PQ structure and does not free them, the leaks will appears 
in the libpq, but your code will be the culprit. 
Make sure you properly call PQclear on all result you got from a libpq call, 
and PQfinish on all connections objects.

-- Jean-Daniel





___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Minimal document-based app

[jonat...@mugginsoft.com]

On 1 May 2012, at 20:46, Wade Tregaskis wrote:
> 
> Actually, there are a lot of commercial developers who hard-code their entire 
> UIs.  I'm at something of a loss to see why myself, but they do it, and they 
> swear it's the best way.  Ironically, one of the reasons often given is 
> "easier internationalisation" vs xibs.


I use xibs of course but I quite often apply my bindings in code for more 
complex views.
I find it much easier to track down bindings' issues in code than through the 
Xcode GUI. 

I think that knowing how to do things in code such as establish a window, 
configure a view hierarchy and establish target/action relationships are 
primary knowledge even if they are not a primary means of implementation.

Jonathan Mitchell

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Concealing an app from DTrace

[Eric Gorr]

Thanks Don. This is what I was looking for in response to my inquiry.

Sent from my iPad

On May 2, 2012, at 1:04 AM, Don Quixote de la Mancha  
wrote:

> On Tue, May 1, 2012 at 6:28 PM, Kyle Sluder  wrote:
> 
>>> I was just wondering if this is still true or true in general...that it is 
>>> not possible to conceal an application from DTrace.
> 
>> On May 1, 2012, at 6:04 PM, Eric Gorr  wrote:
>> It is true and will be true as long as your are able to compile your own 
>> kernel. Think about it.
> 
> Even if you couldn't compiler your own kernel there are all kinds of
> ways to defeat this:
> 
> - Hot-Patch the running kernel by editing its memory space with a
> kernel debugger or even just a hex editor.
> 
> - Load a device driver (Kernel Extension in the case of iOS and OS X)
> that does the hot-patching.
> 
> - Patch the executable binary of the program that you want to crack,
> by writing some No-Op instructions over the code that sets that flag.
> 
> - Build from source any of the libraries that are in the call chain
> from the attempt to set the flag to the context switch into the
> kernel.
> 
> - Replace any of those libraries at runtime, when they dynamic
> libraries are linked, in just the same way as Guard Malloc replaces
> the regular memory allocation library.
> 
> - Rather than replace a library, insert a "shim", that is, what
> appears to the app to be a library, but is just a thin veneer that
> calls through to the regular library, but in certain routines it
> either alerts the input parameters, the output results, or it just
> returns immediately when called rather than calling down to lower
> levels.
> 
> When I was at Working Software in the early nineties, most of our
> products were what the company founder describes as "Virus-Like
> Hacks", with the difference that our products' users wanted them on
> theirs Macs, paid good money for them, and they were packaged in
> full-color boxes with attractive, well-written manuals.
> 
> -- 
> Don Quixote de la Mancha
> Dulcinea Technologies Corporation
> Software of Elegance and Beauty
> http://www.dulcineatech.com
> quix...@dulcineatech.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mailist%40ericgorr.net
> 
> This email sent to mail...@ericgorr.net

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Concealing an app from DTrace

[Ken Thomases]

On May 2, 2012, at 12:04 AM, Don Quixote de la Mancha wrote:

> On Tue, May 1, 2012 at 6:28 PM, Kyle Sluder  wrote:
> 
>>> I was just wondering if this is still true or true in general...that it is 
>>> not possible to conceal an application from DTrace.
> 
>> On May 1, 2012, at 6:04 PM, Eric Gorr  wrote:
>> It is true and will be true as long as your are able to compile your own 
>> kernel. Think about it.
> 
> Even if you couldn't compiler your own kernel there are all kinds of
> ways to defeat this:
> [... snip ...]

My recollection is that it was even easier to defeat.  You just start the 
target program with the debugger, as opposed to attaching to it already 
running, break on ptrace() where it attempts to deny attaching, and simply 
short-circuit the call.

Regards,
Ken


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Minimal document-based app

[ecir hana]

Thank you all for the replies!

As I said above, I don't want the question to be whether I should better
use NIBs, or whether Cocoa is more suitable than assembler. I somewhat know
already what the role of NIB is, that it can save time and so on. What I
would like to know is what to do if I was not using NIBs, i.e. if I wanted
to build as much as possible by hand.

To put it in other words, imagine I wanted to go to some city and was
asking about the best spots for hitchhiking. I know it's faster to get
there by a car and that I can use a train. And please, let's not argue
whether I should be hitchhiking in the first place.

Now, I have some code to share!

Please, I think I managed to write an app which seems to be working but I
would like to check whether I missed something. Here what I did:

- I have to use a bundle. That is, a folder with the following structure:
Contents
Contents/Info.plist
Contents/MasOS/

- Info.plist has to have:
CFBundleExecutable for 
CFBundleName for the name of top-most folder (i.e. the bundle filename)
CFBundleDocumentTypes - which I don't yet understand and will get do it
bellow

- then, the other interesting thing I found out is that I don't need to
write AppDelegate (!). So, my main.m looks like:
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSApplication * application = [NSApplication sharedApplication];

[application run];

- then, and this is the interesting bit, newDocument: gets automatically
routed to my NSDocumentClass from Info.plist and there I create the window,
the model, etc.:
- (id)init
{
   self = [super init];
   if (self) {
   NSRect contentSize = NSMakeRect(0.0f, 0.0f, 480.0f, 320.0f);
   window = [[NSWindow alloc] initWithContentRect:contentSize
styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered defer:YES];
   <...>
   [window makeKeyAndOrderFront:self];
   }
   return self;
}

And when I hit apple-n, the new window pops-up! I also have to implement
dataOfType: and readFromData: - that comes next.

But I have lots of questions:

- I saw that Xcode named the Info.plist differently (it prepends my project
name to it) - is it ok just to call it Info.plist? Is there any convention?

- this CFBundleDocumentTypes - what if I wanted to have only one kind of
documents? Does it have to be an array as well? What is the absolute
minimum every CFBundleDocumentTypes must contain?

- is it really the case that I don't need the AppDelegate? It currently
makes sense to me but maybe I'm missing something?

- I don't want to put the window in init, where else should I put it? Does
NSDocument have an equivalent of applicationDidFinishLaunching, i.e. when
the document is created is there any callback fired?

- new windows are positioned over the previous ones - I know this is
because of that NSMakeRect() - the application created using Xcode (with
NIBs) put every new window slightly to the right, slightly below the
previous window - what is responsible for it? The NIB?

Lots of questions, I know. Thank you in advance for any help with answering
these!
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Minimal document-based app

[Richard Somers]

On May 2, 2012, at 7:19 AM, ecir hana wrote:

> - I saw that Xcode named the Info.plist differently (it prepends my project
> name to it) - is it ok just to call it Info.plist? Is there any convention?

https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigFiles.html


> - this CFBundleDocumentTypes - what if I wanted to have only one kind of
> documents? Does it have to be an array as well? What is the absolute
> minimum every CFBundleDocumentTypes must contain?

https://developer.apple.com/library/mac/#documentation/CoreFOundation/Reference/CFBundleRef/Reference/reference.html


> - is it really the case that I don't need the AppDelegate? It currently
> makes sense to me but maybe I'm missing something?

http://cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html


> - I don't want to put the window in init, where else should I put it? Does
> NSDocument have an equivalent of applicationDidFinishLaunching, i.e. when
> the document is created is there any callback fired?

https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/nsdocument_Class/Reference/Reference.html


> - new windows are positioned over the previous ones - I know this is
> because of that NSMakeRect() - the application created using Xcode (with
> NIBs) put every new window slightly to the right, slightly below the
> previous window - what is responsible for it? The NIB?

It is called window cascading.

https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/nswindowcontroller_Class/Reference/Reference.html


You should also read this.

http://cocoawithlove.com/2008/03/cocoa-application-startup.html

--Richard


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTableview tooltip bug?

[Corbin Dunn]

hi don,
I recommend using the builtin tooltip support in NSTableView. There is a 
delegate method to provide the tool tip. Next, you are seeing 
expansionToolTips. Look at NSCell.h for custom drawing API for them. Or, turn 
them off for your table with API on NSTableView.

corbin

On May 1, 2012, at 5:10 PM, Donald Hall  wrote:

> I have an NSTableview column where each cell contains a file name. I use 
> tooltips (addToolTipRect and NSToolTipOwner protocol)  to show the complete 
> path to the file when the user hovers the mouse over the cell. This works 
> fine unless the name of the file exceeds the column width - 3 pixels. i.e. if 
> the width of the text for the cell is greater than (column width - 3) I get a 
> strange behaviour: the correct tooltip flashes briefly in the usual place 
> relative to the cell, then the cell itself becomes highlighted with a bright 
> yellow background. If the text width is greater than the cell width the the 
> highlighted rectangle extends over the column boundary, so I guess it is the 
> enclosing rectangle of the cell's text that is highlighted.
> 
> I created a category on NSString to define a truncated string method where I 
> remove characters from the middle of the string to fit it into a specified 
> width. My workaround to this problem was to specify the column width - 3 as 
> the width I wanted for the truncated string.
> 
> Has anyone else seen this? Is it a known bug?
> 
> Thanks, Don
> 
> 
> Don Hall
> Apps & More Software Design, Inc. 
> d...@appsandmore.com
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com
> 
> This email sent to corb...@apple.com


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

[MEET] Toronto Cocoaheads / tacow - May 8

[Karl Moskowski]

tacow's next meeting is scheduled for 6:30 PM on Tuesday, May 8, 2012 in room 
304 of Metro Hall.

@AshFurrow, lead iOS developer at 500px, will give a presentation on advanced 
scroll-view techniques. 

Details, directions, etc. at .

All are welcome, and we look forward to seeing you there.


Karl Moskowski 
Voodoo Ergonomics Inc. 



smime.p7s
Description: S/MIME cryptographic signature
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Instruments, how to fix leak in C Lib

[Wade Tregaskis]

> Bytes Used# LeaksSymbol Name
>  84.81 KB 100.0%48PQgetResult
>  84.81 KB 100.0%48 pqParseInput3
>  80.00 KB  94.3%40  pqResultAlloc
>  80.00 KB  94.3%40   malloc
>   4.00 KB   4.7%4  pqAddTuple
>   4.00 KB   4.7%4   malloc
>832 Bytes0.9%4  PQmakeEmptyPGresult
>832 Bytes0.9%4   malloc
> 
> I thought that inside PQgetResult there ought to be a call to pqParseInput3, 
> inside of which I would then e.g. find a call to pqResultAlloc. But this is 
> not the case. So I thought maybe the compiled version of the C-library I am 
> using here does not match the sourcecode I obtained. I recompiled the library 
> from source, built the Objective-C framework and rebuilt my app and did a new 
> trace, but the leaks' trees were identical also now that I excluded the 
> source for error of there being a difference in version.

Symbolication picks the first known symbol before the address in question.  
It's the consequence of a tragic design flaw in debug info formats to date.

It's more obvious when this goes wrong in Crash Reporter or Shark where you can 
see the offsets (e.g. "CGContextLock + 38623824").

It happens as a result of stripping of debug info from the built library.  This 
is normal practice for release distributions.  That you see it when you build 
from source yourself implies that you either didn't actually get your new 
version of the library loaded as expected, you didn't build it with full debug 
info to begin with, or that at some point some of the info was stripped again.
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Instruments, how to fix leak in C Lib

[David Hoerl]

Look at Valgrind - it works on the Mac now. What you do is have a demo 
app or even a GUI that launches, runs, then quits. You enter your app 
and args as arguments to valgrind when you run it.


Valgrind monitors every malloc, and when the app/program quits tells you 
not only what leaks you have, but the stack trace that got you to the 
allocation. Absolutely amazing. I've used it with several open source 
libraries I support.


David

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Instruments, how to fix leak in C Lib

[Wim Lewis]

On 2 May 2012, at 10:55 AM, Wade Tregaskis wrote:
> Symbolication picks the first known symbol before the address in question.  
> It's the consequence of a tragic design flaw in debug info formats to date.
> 
> It's more obvious when this goes wrong in Crash Reporter or Shark where you 
> can see the offsets (e.g. "CGContextLock + 38623824").
> 
> It happens as a result of stripping of debug info from the built library.  
> This is normal practice for release distributions.  That you see it when you 
> build from source yourself implies that you either didn't actually get your 
> new version of the library loaded as expected, you didn't build it with full 
> debug info to begin with, or that at some point some of the info was stripped 
> again.

DWARF debug info, which is the standard on OSX now, is rich enough to solve 
this problem. Unfortunately Apple's "external dsyms" convention means that the 
debug info of open-source libraries usually gets lost before installation, and 
Apple doesn't include it in system frameworks either.

(Tail-call elimination is another reason that call stacks might not precisely 
match the structure of the source code, but from a glance at the libpq sources 
I think it's more likely that the lack of accurate debug info is the reason.)

Anyway, Jean-Daniel is probably right in suggesting that the bug isn't in libpq 
but in its caller--- odds are that some code is calling PQgetResult, and then 
failing to fulfill its obligation to release the resources returned to it.



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Instruments, how to fix leak in C Lib

[Jens Alfke]

On May 2, 2012, at 11:38 AM, David Hoerl wrote:

> Valgrind monitors every malloc, and when the app/program quits tells you not 
> only what leaks you have, but the stack trace that got you to the allocation. 
> Absolutely amazing. I've used it with several open source libraries I support.

Valgrind is cool, but the ‘leaks’ tool that’s always shipped with OS X can do 
what you describe above. You just have to set the environment variable 
MallocStackLogging when running your app/tool so ‘leaks’ can grab the 
backtraces:

env MallocStackLogging=1 ./MyTool &
leaks MyTool

One could argue that Instruments makes the ‘leaks’ tool obsolete, but I find 
it’s so quick and easy to use that I still turn to it. Especially since you can 
use it on an already-running app (although you lose the backtraces if the app 
wasn’t launched specially as above.)

Valgrind can do a lot more, including detecting illegal memory accesses — if 
you read or write even one byte past the end of a malloc block, it’ll tell you, 
and show you the stack trace and the position/size of the block. This has been 
really helpful in debugging some low-level bit-twiddly code I’m currently 
working on!

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

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

Re: Minimal document-based app

[Chris Hanson]

On May 2, 2012, at 6:19 AM, ecir hana  wrote:

> As I said above, I don't want the question to be whether I should better
> use NIBs, or whether Cocoa is more suitable than assembler. I somewhat know
> already what the role of NIB is, that it can save time and so on. What I
> would like to know is what to do if I was not using NIBs, i.e. if I wanted
> to build as much as possible by hand.

Nonetheless, you should not do “as much as possible by hand” if what you’re 
looking for is a deeper understanding of the frameworks. The Cocoa frameworks 
are designed to be used with nibs.

One of the core principals in Cocoa development is “don’t fight the framework.” 
Trying to develop a Cocoa application without using Interface Builder is 
fighting the framework.

Learn how things work with Interface Builder first, then do things manually in 
the few cases where you have to. You’ll get up the learning curve a lot faster 
and you’ll be a lot more productive at the same time.

  -- Chris


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Minimal document-based app

[Chris Hanson]

On May 2, 2012, at 6:19 AM, ecir hana  wrote:

> - I saw that Xcode named the Info.plist differently (it prepends my project
> name to it) - is it ok just to call it Info.plist? Is there any convention?

Xcode is actually prepending the target name, not the project name: A project 
can have multiple targets, creating a new project really creates a new empty 
project and then adds a target of the desired type with the same name.

Using a «TargetName»-Info.plist as the name also helps to emphasize that it’s a 
source file, not something copied wholesale into the output. For example, build 
settings using ${SETTING_NAME} syntax in «TargetName»-Info.plist are expanded, 
for example

CFBundleIdentifier
com.example.${PRODUCT_NAME:rfc1034identifier}

is used (assuming you specified a bundle identifier prefix of com.example) 
instead of hard-coding the app name into the bundle identifier.

> - I don't want to put the window in init, where else should I put it? Does
> NSDocument have an equivalent of applicationDidFinishLaunching, i.e. when
> the document is created is there any callback fired?

This is a case where I think trying to do everything “by hand” may be inducing 
some confusion and is definitely causing you to do more work than you probably 
need to.

The method -[NSDocumentController newDocument:] is what creates and presents a 
new untitled document; its documentation indicates what it sends to do so, and 
the documentation for those methods do the same in turn. In the end 
-[NSDocument makeWindowControllers] and -[NSDocument showWindows] are used to 
present the document’s human interface.

As you check out the documentation, you’ll see that by default, -[NSDocument 
makeWindowControllers] expects -[NSDocument windowNibName] to return the name 
of a nib file to use for the document’s human interface. In a lot of cases 
you’ll want a separate NSWindowController subclass, but even in those cases 
you’ll want it to use a nib (by initializing it with -[NSWindowController 
initWithWindowNibName:]) rather than a programmatically-wired-up window.

In essence, don’t make more work for yourself than you need to. What Interface 
Builder does for you is basically this:

  Class1 *object1 = [[Class1 alloc] init];
  Class2 *object2 = [[Class2 alloc] init];
  Class3 *object3 = [[Class3 alloc] init];
  
  owner.outlet1 = object1;
  owner.outlet2 = object2;
  owner.outlet3 = object3;
  
  object1.property1 = owner;
  object1.property2 = object2;
  
  object2.property1 = object1;
  object2.property2 = object3;
  
  object2.target = owner;
  object2.action = @selector(anAction:);
  
  object3.target = firstResponder;
  object3.action = @selector(anotherAction:);
  
  [owner awakeFromNib];
  [object1 awakeFromNib];
  [object2 awakeFromNib];
  [object3 awakeFromNib];

and so on. (Interface Builder actually uses archiving so it’ll use 
-initWithCoder: not -init, but the gist is clear.)

It really won’t teach you much about Cocoa to write dozens of lines of code 
like this by hand — plus you’ll wind up having to do a lot of extra work to get 
everything to look like it does when you drag it (pre-configured) out of the 
library in Interface Builder.

This is why people in the Cocoa community have the reaction we do when 
developers new to Cocoa ask how to put together interfaces without using 
Interface Builder, and why “don’t tell me not to, just tell me how” doesn’t 
generally get a good reception.

  -- Chris


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Converting CGPathAddArcToPoint (or NSBezierPath equivalent) to a fixed number of CGPathAddCurveToPoint calls

[Wim Lewis]

On 30 Apr 2012, at 3:26 PM, Gideon King wrote:
> Hi, I am using the CAShapeLayer's ability to animate a path, but the start 
> and end path need to have the same number of segments. 
> 
> I have been using CGPathAddArcToPoint to add the curves to my path. That 
> translates to CGPathAddCurveToPoint calls behind the scenes, but sometimes it 
> adds one curve and sometimes two, which means that the curve can't be 
> animated. 
> 
> I therefore need to be able to approximate the arc with the same number of 
> CGPathAddCurveToPoint calls each time (presumably 2 or 3).
> 
> Has anyone done this already either with CGPaths or NSBezierPaths? Any 
> pointers would be most welcome.


The usual way of converting circular arcs into cubic Beziers uses one curve for 
no more than 90 degrees of arc. Presumably calling CGPathAddArcToPoint() for 
less than 90 degrees will always add exactly one path segment (though this is 
an implementation detail of course). So you could try dividing up your arcs 
into a fixed number of sub-arcs so that the sub-arcs are always less than 90 
degrees.



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Are there any way to update NSPanel content during dragging the panel ?

[Yoshiaki Katayanagi]

 My custom NSView in a NSPanel shows some information depends on panel's 
position to the main window. I want  to update it during dragging the panel. I 
try [self setNeedsDisplay:YES] in mouseDragged: delegate, drawRect: called many 
times during dragging, but it will not appear on screen until mouse stop.
 I test it on Mac OS X 10.7 and want to support 10.6.

Yoshiaki Katayanagi
http://www.jizoh.jp/english.html
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTableView doesn't show data until I click on a header

[Koen van der Drift]

Got it, it all works (I think :).

The only thing that made me scratch my head was how to empty the whole
array.  Right now I am using this, but any suggestions or improvements
are welcome:

NSRange range = NSMakeRange(0, [self countOfMyObjects]);
NSIndexSet *indexes = [NSIndexSet indexSetWithIndexesInRange: range];

[self removeMyObjectsAtIndexes: indexes];


- (void) removeMyObjectsAtIndexes: (NSIndexSet *)indexes
{
[self.myArray removeObjectsAtIndexes: indexes];
}



Thanks,

- Koen.




On Mon, Apr 30, 2012 at 12:40 PM, Quincey Morris
 wrote:
> On Apr 30, 2012, at 09:27 , Koen van der Drift wrote:
>
> I am using an NSMutableArray to store the myObjects, the table
> displays several properties of each object in seperate columns.  So
> the order in which the objects are stored in the array is not
> critical, they will be ordered once displayed in the table and the
> user can select which column to use for ordering. Therefore I don't
> think I need to use the 'indexed mutable accessors', but the 'mutable
> unordered accessors' as discussed in the same link from mmalc.   Am I
> correct here?
>
>
> No, you have to use the indexed accessors, because the NSArrayController
> that mediates between your data model and your UI (NSTableView) expects the
> property to be indexed -- i.e. to behave like an array -- even though the
> contents get re-sorted before display.
>
> [Confusingly, this is only true when you're using an array controller in
> "Class" (normal) mode. When you're using an array controller in "Entity"
> (Core Data) mode, it expects the property to be unordered, since that how
> Core Data to-many properties are modeled. Of course, in this case, you're
> not implementing the accessors yourself.]

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTableview tooltip bug?

[Donald Hall]

Thanks! Got it running in a few minutes. For others, I used the 
NSTableViewDelegate methods

tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:

and

tableView:shouldShowCellExpansionForTableColumn:row:

to prevent the cell expansion.

Don Hall
Apps & More Software Design, Inc.   
d...@appsandmore.com


On 2012-05-02, at 11:54 AM, cocoa-dev-requ...@lists.apple.com wrote:

> From: Corbin Dunn 
> To: Donald Hall 
> Cc: cocoa-dev@lists.apple.com
> Subject: Re: NSTableview tooltip bug?
> Message-ID: <0a0b2cde-d218-4d90-8021-c73872afd...@apple.com>
> Content-Type: text/plain; charset=us-ascii
> 
> hi don,
> I recommend using the builtin tooltip support in NSTableView. There is a 
> delegate method to provide the tool tip. Next, you are seeing 
> expansionToolTips. Look at NSCell.h for custom drawing API for them. Or, turn 
> them off for your table with API on NSTableView.
> 
> corbin
> 
> On May 1, 2012, at 5:10 PM, Donald Hall  wrote:
> 
>> I have an NSTableview column where each cell contains a file name. I use 
>> tooltips (addToolTipRect and NSToolTipOwner protocol)  to show the complete 
>> path to the file when the user hovers the mouse over the cell. This works 
>> fine unless the name of the file exceeds the column width - 3 pixels. i.e. 
>> if the width of the text for the cell is greater than (column width - 3) I 
>> get a strange behaviour: the correct tooltip flashes briefly in the usual 
>> place relative to the cell, then the cell itself becomes highlighted with a 
>> bright yellow background. If the text width is greater than the cell width 
>> the the highlighted rectangle extends over the column boundary, so I guess 
>> it is the enclosing rectangle of the cell's text that is highlighted.
>> 
>> I created a category on NSString to define a truncated string method where I 
>> remove characters from the middle of the string to fit it into a specified 
>> width. My workaround to this problem was to specify the column width - 3 as 
>> the width I wanted for the truncated string.
>> 
>> Has anyone else seen this? Is it a known bug?
>> 
>> Thanks, Don
>> 
>> 
>> Don Hall
>> Apps & More Software Design, Inc.
>> d...@appsandmore.com
>> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Are there any way to update NSPanel content during dragging the panel ?

[Jens Alfke]

On May 2, 2012, at 5:59 PM, Yoshiaki Katayanagi wrote:

> My custom NSView in a NSPanel shows some information depends on panel's 
> position to the main window. I want  to update it during dragging the panel. 
> I try [self setNeedsDisplay:YES] in mouseDragged: delegate

-mouseDragged: is called after the mouse button is pressed *within your view* 
and the cursor moves. It has nothing to do with the window being dragged, since 
after all that’s a mouse-down in the title bar, not your view.

In general views don’t care about and don’t get notified about window movement. 
You can listen to the NSWindowDidMoveNotification posted by the window, if you 
want to know about it.

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

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