Hi all,
I'm trying to use two nib files in my program. In my main controller class,
I load the second nib with:
[NSBundle loadNibNamed:"second" owner:self];
But then, not only does the second controller in the second nib file recevie
the awakeFromNib message, but also does the main controller
c
Hi,
you load the second nib from the main controller i guess. Thereby you
set the instance of your main ontroller as owner, thus it gets the
awakeFromNib call. Set your second controller as owner or nil (if you
have an instance of your second class in your NIB as file owner (!)).
Cheers,
Drumroll please...
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSNibAwaking_Protocol/Reference/Reference.html
http://markmail.org/message/kmmikobih6a44rh4
http://www.cocoabuilder.com/archive/message/cocoa/2004/2/18/97396
http://forums.macnn.com/79/
I've uploaded a simple test case here:
http://dl.getdropbox.com/u/550950/gc-crash.zip
On Sat, Oct 24, 2009 at 11:18 PM, Ken Ferry wrote:
> If you have extracted this to a test project, does that mean you now
> have a reproducing case whose source you can share? If so, why don't
> you put it up s
On 24 Oct 2009, at 16:36, TFS - Tobias Jordan wrote:
Thanks again Thomas and Jonathan. What you've written, Thomas, is
indeed working as it should however I can't use it for my project
since I am creating special folder structures when copying the
files, e.g. Adobe Photoshop Files -> 2008-
That's because it's a private method. Have a look at the WebKit source
– WebUIDelegatePrivate.h
It's been there since WebKit 3.0 so will probably be around for a
while to come. And at worst, WebKit will just stop calling your method
and you'll have to find something else (or include a custom
I have, or rather had, a problem. I've solved it but I'm still not
sure why the problem is there in the first place.
I have a bunch of controller classes which have a common base class,
and this in turn subclasses NSObject. Recently I factored out some
code into an even more primitive base
Surprisingly, I could find no reference to this issue.
In the archives, there seems to be, lately, the consensus ( I hope)
that direct ivar access is preferred in 2 methods ie init and dealloc.
This would seem to imply that initWithCoder/encodeWithCoder should
also use direct ivar access,
Well the documentation for 10.6 does say that awakeFromNib is called
only if the receiver responds to it, I don't have the leopard docs on
my machine at the moment so I don't know what that says.
Are these new objects really new classes which weren't in the NIBs
before or are classes which
On 25/10/2009, at 11:24 PM, Roland King wrote:
Are these new objects really new classes which weren't in the NIBs
before or are classes which were always in the NIB, but where you've
now changed the implementation of the class to use the new
refactored code? My thought was that the NIBs th
On Oct 25, 2009, at 7:53 AM, Graham Cox wrote:
Then, running on 10.5.(8) I stared to get an error that the object
did not respond to -
awakeFromNib. I'd not previously seen this error until I refactored
my code. Sure enough my new base class and its new fork don't
implement awakeFromNib b
Where's that documented??? I looked for that when I saw the original
question. For iPhone it's documented under NSObject UIKit Additions
Reference, for 10.6 it's under NSNibAwakingProtocol which doesn't show
up anywhere as an implemented protocol of NSObject.
I'm sure you're right but I've
On Oct 25, 2009, at 12:22 PM, Roland King wrote:
Where's that documented??? I looked for that when I saw the original
question. For iPhone it's documented under NSObject UIKit Additions
Reference, for 10.6 it's under NSNibAwakingProtocol which doesn't
show up anywhere as an implemented prot
Pleases do not encourage use or attempted use of private functions and
methods.
This is bad practice. Encouraging others to do so is irresponsible and
unethical.
If you worked for me, you would stand a very large chance to lose your
job.
It is also not permitted to discuss private API o
On Oct 23, 2009, at 5:46 PM, Grant Erickson wrote:
On 10/23/09 4:38 PM, Kyle Sluder wrote:
On Fri, Oct 23, 2009 at 4:31 PM, Grant Erickson
wrote:
Unlike the Network table, in my case there is no mandate that an
item (i.e.
row) always be selected. However, if there are no rows selected,
wh
OK that's great Mike, thanks a lot for your help.
As you say that's probably not something they will need to change over
time so long as WebView remains in its current form.
Anyway, hopefully you've given me my 'get out of jail card'.
Cheers
-- Luke
On 2009-10-25, at 3:30 AM, Mike Abdullah
On 10/25/09 10:26 AM, Keary Suska wrote:
> On Oct 23, 2009, at 5:46 PM, Grant Erickson wrote:
>> On 10/23/09 4:38 PM, Kyle Sluder wrote:
>>> On Fri, Oct 23, 2009 at 4:31 PM, Grant Erickson
>>> wrote:
Unlike the Network table, in my case there is no mandate that an
item (i.e.
row) al
My code draws lines some thousand times with different angles. I'd
like to have the lines to look similar to 3D objects. So currently I
draw each line segment three times:
1. one time with a thick line in black
2. the second time with a slightly thinner line in the current color
3. and a thir
On Oct 25, 2009, at 2:42 PM, Matthias Arndt wrote:
My code draws lines some thousand times with different angles. I'd
like to have the lines to look similar to 3D objects. So currently I
draw each line segment three times:
1. one time with a thick line in black
2. the second time with a sli
Hm, nothing obviously wrong.
Could you please file a bug at bugreporter.apple.com and send me the number?
Thanks.
-Ken
Cocoa Frameworks
On Sun, Oct 25, 2009 at 2:34 AM, slasktrattena...@gmail.com <
slasktrattena...@gmail.com> wrote:
> I've uploaded a simple test case here:
>
> http://dl.getdro
Hi,
I'm having a problem getting a unit test to run. It's quite a simple
one, based on a sample project that I developed and that does actually
work. It's loosely based on the Apple Temperature Converter project.
I have a Converter class that has a float property called
originalTemperatur
On Oct 25, 2009, at 2:08 PM, Ian Piper wrote:
It also has a method called convertCToF that ... returns the
converted temperature, also as a float.
NSNumber *newTemperatureInF = [testConverter convertCToF]; // This
is where I get the error "Incompatible types in initialization"
An NSNumb
On 25 Oct 2009, at 20:13, Dave DeLong wrote:
On Oct 25, 2009, at 2:08 PM, Ian Piper wrote:
It also has a method called convertCToF that ... returns the
converted temperature, also as a float.
NSNumber *newTemperatureInF = [testConverter convertCToF]; // This
is where I get the error "Inc
On Oct 25, 2009, at 1:08 PM, Ian Piper wrote:
> testConverter = Converter.new;
Dot syntax is for accessing state (properties) of objects, not for invoking
behavior.
This should be either
testConverter = [Converter new];
or
testConverter = [[Converter alloc] init];
to indicate that i
Done. Bug ID# 7334881.
On Sun, Oct 25, 2009 at 8:41 PM, Ken Ferry wrote:
> Hm, nothing obviously wrong.
> Could you please file a bug at bugreporter.apple.com and send me the number?
> Thanks.
> -Ken
> Cocoa Frameworks
> On Sun, Oct 25, 2009 at 2:34 AM, slasktrattena...@gmail.com
> wrote:
>>
>>
Am 25.10.2009 um 19:50 schrieb I. Savant:
How about creating 1 NSGradient instance for each color you want,
then creating one bezier path for each line. The path would describe
the outer edges of the pipe, then you'd *fill* it with the gradient
at the desired angle, rather than stroking.
On Oct 25, 2009, at 5:44 PM, Matthias Arndt wrote:
Thanks for your response. I'm nearly convinced to look into the
gradients tomorrow, although I'm afraid it won't result in a better
performance: Empty the path, calculate the angle, create the rect
(with rounded edges), apply the gradient
On Oct 25, 2009, at 14:44, Matthias Arndt wrote:
I'm nearly convinced to look into the gradients tomorrow, although
I'm afraid it won't result in a better performance: Empty the path,
calculate the angle, create the rect (with rounded edges), apply the
gradient and fill the path ... vs. thr
Hi,
Coming from .NET, I was wondering if there is anything like a TreeView
control in Cocoa?
Thanx.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators
On Oct 25, 2009, at 6:49 PM, Gevik wrote:
Coming from .NET, I was wondering if there is anything like a
TreeView control in Cocoa?
NSOutlineView?
--
I.S.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin request
Gah! That was it - seems I actually added a [super awakeFromNib] at
some point to one of my classes during the refactoring for reasons
that escape me now. Removing it fixes the issue.
Thanks for the help guys (off-list too).
--Graham
On 26/10/2009, at 2:53 AM, Jim Correia wrote:
On Oct 2
On 26/10/2009, at 10:44 AM, Matthias Arndt wrote:
Am 25.10.2009 um 19:50 schrieb I. Savant:
How about creating 1 NSGradient instance for each color you want,
then creating one bezier path for each line. The path would describe
the outer edges of the pipe, then you'd *fill* it with the gradie
On 26/10/2009, at 10:07 AM, Paul M wrote:
screensavers should be low impact - personally, if a screensaver
uses more that about 10-15% cpu, I'll ditch it imediately
Really? It's not as if your computer has anything better to do.
The OP included a link to his project - it's not a screensave
I need to programatically resize the view of an NSCollectionViewItem
as soon as it is created. So far I tried this (subclassing
NSCollectionView and overriding newItemForRepresentedObject)
@implementation IGCollectionView
- (NSCollectionViewItem *)newItemForRepresentedObject:(id)object {
On Oct 25, 2009, at 7:22 PM, Graham Cox wrote:
screensavers should be low impact - personally, if a screensaver
uses more that about 10-15% cpu, I'll ditch it imediately
Really? It's not as if your computer has anything better to do.
Again: battery. Many of us are laptop users.
The OP
On Oct 25, 2009, at 4:22 PM, Graham Cox wrote:
Really? It's not as if your computer has anything better to do.
Uhoh, we're entering philosophical debate territory.
First, it often takes a while to check out and compile a fresh copy of
our source tree. During this time my system is unusable
On Oct 25, 2009, at 7:48 PM, I. Savant wrote:
Quincey's suggestion to cache is right on the money: draw it with
bezier paths once, then only display the finished product as PDF
data. You could even separate it out into different 'overlays' for
each 'thread file'. That minimizes any redraw
On 26/10/2009, at 10:42 AM, PCWiz wrote:
I need to
Why? What's the real story?
It's likely that whatever view you return will be resized to suit the
space available in the collection view, so whatever you do to its
frame prior to that is going to be ignored.
--Graham
On 26/10/2009, at 10:48 AM, I. Savant wrote:
Quincey's suggestion to cache is right on the money: draw it with
bezier paths once, then only display the finished product as PDF
data. You could even separate it out into different 'overlays' for
each 'thread file'. That minimizes any redrawin
On Oct 25, 2009, at 8:00 PM, Graham Cox wrote:
But caching to a bitmap of some kind is a much bigger win, provided
you do it at the scale you need to draw it at (and recache if that
scale changes). Using CGLayer can generate really big speedups, so
that's worth looking into, but even the v
On Oct 25, 2009, at 17:00, Graham Cox wrote:
I've found that caching to a PDF doesn't gain much performance wise
- a little, but not that significant. Since a PDF essentially
records whatever paths you create and rasterizes them, that's no
surprise
Could well be, though it depends on whet
On 26/10/2009, at 11:21 AM, Quincey Morris wrote:
On Oct 25, 2009, at 17:00, Graham Cox wrote:
I've found that caching to a PDF doesn't gain much performance wise
- a little, but not that significant. Since a PDF essentially
records whatever paths you create and rasterizes them, that's no
The reason is that for some of the collection view items, the normal
size is not enough to fully display some of the content inside the view.
On 2009-10-25, at 5:54 PM, Graham Cox wrote:
On 26/10/2009, at 10:42 AM, PCWiz wrote:
I need to
Why? What's the real story?
It's likely that what
I have a peculiar situation involving matching an application with its
documents; I have read the Apple stuff on Uniform Type Identifiers and
I suspect they can solve my problem, but I am slow at seeing how:
This issue comes up during development, in which case it is a bother,
but it does n
On Sun, Oct 25, 2009 at 6:57 PM, Jay Reynolds Freeman
wrote:
> I have an app, "MyApp", which has a user preferences file, properly located
> in the user's Library/Preferences directory, and properly named
> "com.Jay_Reynolds_Freeman.MyApp.plist". All is well and good with the
> preferences mechan
Jay Reynolds Freeman wrote:
The binary-file documents are clickable -- you are supposed to be
able to launch the app by mousing on one. But if the wrong version
of the app gets launched by mistake, it fails. I would like to make
that not happen, mostly so that I can make sure I haven't some
Thanks for the answer. Do you know why the file's owner gets awakFromNib
call as well? Is it creating a new file's owner object?
I tried to NSLog(@"%@", self); in maincontroller's awakefromnib, but the
second call to that raised an exception.
In the code I was trying to pass the second controlle
On Sun, Oct 25, 2009 at 7:30 PM, DairyKnight wrote:
> Thanks for the answer. Do you know why the file's owner gets awakFromNib
> call as well? Is it creating a new file's owner object?
No, the file's owner is never created by virtue of loading a nib. It
is always an object that already exists.
> Do you know why the file's owner gets awakFromNib
> call as well? Is it creating a new file's owner object?
That's the entire purpose of having an object in the nib ;-)
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
_
Hi.
I just joined the mailing list and tried to post this last week, but
never saw it show up. I'm trying again.
I'm getting the message below printed to the console from my
application and hope someone knows what might be going on.
When this happens I have a view with an NSProgressIndicator whic
The issue isn't that it crashes, the issue is that I cannot test that
any given version of "MyApp" does the right thing with the right
version of the binary file, unless I can get the finder to match up
the file that I mouse on with the right version of the app.
I in fact do have a mechanis
>> Do you know why the file's owner gets awakFromNib
>> call as well? Is it creating a new file's owner object?
>
> That's the entire purpose of having an object in the nib ;-)
Sleep-deprived nonsense; try to forget that I ever said it.
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killer
On Oct 25, 2009, at 10:30 PM, DairyKnight wrote:
Thanks for the answer. Do you know why the file's owner gets
awakFromNib
call as well? Is it creating a new file's owner object?
Remember the purpose of a nib is to instantiate objects, set their
properties, and set connections between them.
On Sun, Oct 25, 2009 at 8:21 PM, Jon Nall wrote:
> Hi.
> I just joined the mailing list and tried to post this last week, but
> never saw it show up. I'm trying again.
It did in fact make it through; a good way to check is to look at
Cocoabuilder (http://www.cocoabuilder.com) and the Apple mailin
hello every one
i need to get current system event,waiting until the function get some
event,then remove it from the queue
what should i do?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments
> -Original Message-
> From: cocoa-dev-bounces+dbridges=codecomplete@lists.apple.com
> [mailto:cocoa-dev-bounces+dbridges=codecomplete@lists.apple.com] On
> Behalf Of Squ Aire
> Sent: Friday, October 23, 2009 7:03 AM
> To: bryanhe...@mac.com
> Cc: cocoa-dev@lists.apple.com
> Subject
56 matches
Mail list logo
