That is what I thought but just wanted too verify … thanks.
-koko
On Nov 26, 2011, at 12:28 PM, Dave Fernandes wrote:
> You can just subclass NSWindowController and make that subclass the File's
> Owner.
>
> Sent from my iPhone
>
> On 2011-11-26, at 2:14 PM, koko wrote:
>
>> I want to displ
thank you very much for your answers.
2011/3/23 Graham Cox
>
> On 23/03/2011, at 11:58 AM, Quincey Morris wrote:
>
> > 1b. The property is a to-many relationship.
> >
> > If #1a, then the return value should be unchangeable, in the sense that
> it should never change after being returned (regard
On 23/03/2011, at 11:58 AM, Quincey Morris wrote:
> 1b. The property is a to-many relationship.
>
> If #1a, then the return value should be unchangeable, in the sense that it
> should never change after being returned (regardless of whether the returned
> object is of a mutable class or not).
On Mar 22, 2011, at 16:53, Graham Cox wrote:
> That's because a) NSMutableArray IS a NSArray, and b) your method has told
> its clients it is returning an NSArray, so the client has no right to go any
> further than the methods of NSArray with that object, that is, it cannot make
> use of knowl
On 23/03/2011, at 6:29 AM, Ariel Feinerman wrote:
> Hi,
>
> can someone look at and say is a returning of immutable objects necessary or
> no?
>
> @interface XMLElement : NSObject {
>
>
> NSString *_name;
>
> NSMutableString *_text;
>
> NSMutableDictionary *_attributes;
>
> NSMutableArray
Fair enough. I guess what I'm wondering then is how do I handle the
following case. I have several loosely coupled properties which can
read somewhat like this.
(ProjectInstall *)projectInstall {
return [ProjectInstallController projectInstallWithProjectId:projectId];
}
And in some cases it
On Aug 6, 2009, at 12:29 PM, Quincey Morris wrote:
Finally, the question of whether 'projectInstall' sometimes returns
nil is irrelevant. That has nothing to do with the compliance of the
Project object.
Except, check out "Bug Fix in KVO's Dependency Mechanism" in the
Leopard Foundation R
On Aug 6, 2009, at 07:46, Kaelten wrote:
I guess what I'm wondering then is how do I handle the
following case. I have several loosely coupled properties which can
read somewhat like this.
(ProjectInstall *)projectInstall {
return [ProjectInstallController
projectInstallWithProjectId:proj
On Aug 4, 2009, at 11:35, Kaelten wrote:
I have an application I'm working on where I'm using mainly Bindings
for communicating with the UI, but I find myself in situations where
I'm not getting all the data updates to the UI.
These lack of updates seem to stem either from dependent keys, loose
On Mar 10, 2009, at 1:39 AM, rajesh wrote:
I need to display huge number of "elements" in NSView (1000-2000).
These elements are generally made of high resolution image files
with some fancy drawing around them. These elements may vary from
size 300 X 270 to 4280 X 3500.
First I made use
On 10/03/2009, at 7:39 PM, rajesh wrote:
Is there any other way of approach, or should I be making use of one
of the ways I mentioned ?
Of course - just define a custom object that contains or manages each
piece of content and draw them in one view. This is the "classic"
approach and is
So besides hiding a layer I should also removeAnimationForKey:
Thanks!
On Feb 12, 2009, at 11:16 AM, David Duncan wrote:
On Feb 12, 2009, at 9:50 AM, David Blanton wrote:
Do I understand correctly that if a layer with explicit animations
is hidden the animation is still running?
Yes, ani
On Feb 12, 2009, at 9:50 AM, David Blanton wrote:
Do I understand correctly that if a layer with explicit animations
is hidden the animation is still running?
Yes, animations always run, regardless of the hidden state of a layer
(hidden is just another render attribute).
--
David Duncan
A
Do I understand correctly that if a layer with explicit animations is
hidden the animation is still running?
On Feb 12, 2009, at 10:45 AM, David Duncan wrote:
On Feb 12, 2009, at 9:37 AM, David Blanton wrote:
Side question ... in doing so will the animations begin when the
hidden property
On Feb 12, 2009, at 9:37 AM, David Blanton wrote:
Side question ... in doing so will the animations begin when the
hidden property is set NO.
Animations run independently of each other, so hiding a layer does not
pause animations at all.
--
David Duncan
Apple DTS Animation and Printing
_
Sorry. When I posted about "the problem Oleg Krupnov describes", I
wasn't caught up on my reading of the list. The VC MYShapeDraw
application I describe is a drawing application and not related to
image thumbnail caching. Of course, the pattern is general and
applicable to image thumbnai
"Cocoa Design Patterns" Chapter 29, "Controllers," contains an MVC
solution to exactly the problem Oleg Krupnov describes. The chapter
presents a relatively simple MVC MYShapeDraw application. The chapter
leads the reader through the step by step process of re-inventing
NSArrayControlle
Thanks, that mostly answers my question, finally. And the short answer
is "No" :). There is no standard Cocoa way of doing this and it's up
to me how to implement it. I just wanted to make sure I was not
reinventing the wheel.
You are correct in suspecting me in a kind of MVC purism (typical for
a
Grahaam Cox wrote on 2008-08-28 13:11:47:
>
> Regarding the above though, if this is similar to your situation -
> what's really wrong with model objects caching a thumbnail? Being a
> slave to MVC is going to lead to suboptimal solutions just as ignoring
> MVC altogether is going to be. The c
On Aug 28, 2008, at 12:26 PM, Oleg Krupnov wrote:
I think there are times when it's appropriate to have wrapper
objects - that
are view related - for your model objects. In an image browser,
it's likely
that there is a "thumbnail" object that draws "image" objects.
Yeah, maybe "view-rela
On 28 Aug 2008, at 8:26 pm, Oleg Krupnov wrote:
In your image browser example, this problem sounds as follows: where
to store the cached thumbnail images, to avoid re-creating them anew
in each drawRect call? Also, if a thumbnail is in process of dragging
inside the custom view, where to save t
On 28 Aug 2008, at 6:15 pm, Oleg Krupnov wrote:
I have only one problem with this approach: As I mentioned before, I
need to add custom-view specific instance variables (states) to the
model object's category. The Objective-C categories do not allow
adding instance variables, only methods
I am
> I think there are times when it's appropriate to have wrapper objects - that
> are view related - for your model objects. In an image browser, it's likely
> that there is a "thumbnail" object that draws "image" objects.
Yeah, maybe "view-related wrapper objects for model objects" is the right t
On Aug 28, 2008, at 11:06 AM, Oleg Krupnov wrote:
In other words, I need a way to associate additional
custom-view-specific properties with model object, without adding them
as transitive properties to the model. What is the best way to do
this? Or maybe your point is that this is a bad idea at
Okay, I – hopefully – understand you now:
You have a view with some (model) objects displayed.
There is another view (potentially or really?) that can display these
objects, too
The additional attributes are specific for each displayed object and
each view?
Correct? (There is a german phrase
Yes, you are correct. I am looking not to break MVC and also get the
correct implementation of binding in a custom view
> Just an example: I had a graphic application that drawed some inserted
> shapes. The shape itself is a part of the model, the color of the shape,
> too. But when the user selec
Am Do,28.08.2008 um 10:15 schrieb Oleg Krupnov:
Parts of your first question remind me of a situation that I had.
Erik Buck gave me some great advice and part of it was the following:
If you are worried about adding drawing code to a "Model" object,
add the drawing code in a category of *
> Parts of your first question remind me of a situation that I had. Erik Buck
> gave me some great advice and part of it was the following:
> If you are worried about adding drawing code to a "Model" object, add the
> drawing code in a category of * and maintain the category
> implementation in
On Aug 27, 2008, at 8:10 AM, Oleg Krupnov wrote:
I am building a custom view that can display and edit some polymorphic
objects. Furthermore, the objects can be composite, i.e. contain child
objects hierarchically.
Now I want to bind this custom view to the model through a controller
(NSTreeCon
On 22 Aug 2008, at 2:22 pm, Phil wrote:
Why use NSNotifications when there's already
perfectly good notification mechanism?
Indeed, but notifications have been around a lot longer than KVO, so
there are still plenty of places in Cocoa that notifications are used
for legacy reasons.
Als
On Fri, Aug 22, 2008 at 3:59 PM, Kyle Sluder
<[EMAIL PROTECTED]> wrote:
> @implementation ToolBar
> {
>-(id) init
>{
>[[[NSNotificationCenter] defaultCenter] addObserver:self
> selector:@selector(splitViewResized:) object:mySplitView];
>}
-(void)dealloc
{
[[NSNotificationCe
On Thu, Aug 21, 2008 at 10:27 PM, Graham Cox <[EMAIL PROTECTED]> wrote:
> But one thing that has been overlooked - common or garden notifications. If
> all you want is to pick up a change in an object a notification is a simple
> way to do it without writing your own messaging system. It's less pow
So, does everybody really always use KVC/KVO for implementing MVC, in
all projects? Is this the recommended best practice?
From code written after 10.2, yeah, pretty much. Coupled with the
tools support in Interface Builder and the AppKit support with Cocoa
Bindings, it's really not worth t
On 22 Aug 2008, at 1:03 am, Oleg Krupnov wrote:
4) Anything else I may have overlooked?
I've read through this thread and it's very interesting.
But one thing that has been overlooked - common or garden
notifications. If all you want is to pick up a change in an object a
notification is
On Aug 21, 2008, at 7:09 PM, Erik Buck wrote:
On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote:
On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:
KVC also provides support (hooks) for change management so that
any change to a property can have application defined side effects
like registering
On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote:
I have some quibbles...
On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:
So, in summary, the whole point of KVC is to standardize the way an
object’s properties are accessed regardless of how they are stored.
Well, the real point, to my mind,
Remember that NeXT and Apple didn't just invent KVC, KVO, and Bindings
out of thin air for no better reason than they were enamored of the
idea.
There was a substantial history of NeXTStep/OpenStep/Cocoa programs
written. The developers at NeXT and then Apple recognized that there
was a
I have some quibbles...
On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:
So, in summary, the whole point of KVC is to standardize the way an
object’s properties are accessed regardless of how they are stored.
Well, the real point, to my mind, is to increase the dynamism of
property access.
I love answering questions that require an essay. So here is my essay.
I think my forthcoming Cocoa Design Patterns book does a good job of
explaining the patterns used to implement Cocoa and reused to implement Cocoa
applications. In particular, the book explains how techniques like Key
Am Do,21.08.2008 um 17:03 schrieb Oleg Krupnov:
Amin,
It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.
In particular, would you e
Oleg,
by all means, go ahead with what you started and spend more time
learning about KVC/KVO.
Yes, this is used in many many projects and I personally would really
miss it if it wouldn’t be there. Actually, as you described yourself,
if it wouldn’t be there, you’d had to brew something s
Amin,
It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.
In particular, would you explain me, in just two words, what are the
relations
Am Do,21.08.2008 um 16:41 schrieb Oleg Krupnov:
Thanks Amin for responding.
You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.
So, does everybody really always use KVC/KVO fo
Thanks Amin for responding.
You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.
So, does everybody really always use KVC/KVO for implementing MVC, in
all projects? Is this the rec
Am Do,21.08.2008 um 15:22 schrieb Oleg Krupnov:
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:cha
>> I suspect that it could be way easier, when a property's value
>> changes, to just explicitly send a concise and clearly named message
>> to the subscribed objects,
>
> This is, what is done. The name of the message is
> -observeValueForKeyPath:ofObject:change:context:
Then how is it better tha
Am Do,21.08.2008 um 08:58 schrieb Oleg Krupnov:
I need to make the design decision regarding how the model and the
views will be kept in sync with each other. Namely:
- I can use key-value coding and observing (KVC and KVO)
- I can use bindings (not sure if it's really different from the KVC/
On Jul 20, 2008, at 10:24 PM, Jens Alfke wrote:
On 20 Jul '08, at 8:05 PM, James W. Walker wrote:
Since there is a window (which has a title that depends on the
data) I thought I should use a subclass of NSWindowController. On
the other hand, there is an array being displayed in a table, a
On Mon, Jul 21, 2008 at 4:05 AM, James W. Walker <[EMAIL PROTECTED]> wrote:
> I have these windows, each of which has a table displaying data from an
> array of dictionaries. The data is never stored on disk, so I don't think
> of these windows as "documents".
In addition to what Jens said: If t
On 20 Jul '08, at 8:05 PM, James W. Walker wrote:
Since there is a window (which has a title that depends on the data)
I thought I should use a subclass of NSWindowController. On the
other hand, there is an array being displayed in a table, and I
gather that's easier to set up using bindi
I'd agree with what I.S. said, make sure you read up on and run
through some tutorials for coding a table and its data source by
hand. Aaron Hillegass does a great job of this in Cocoa Programming
for Mac OS X. As a Cocoa newbie this is a great book to hit the
ground running. It assumes
Does anyone have any comments on my design so far?
Overcomplicated. :-) If I were writing a quick utility to do as
you're looking to do, I'd probably implement it all in a single
application controller. There's no real design advantage in something
with so few requirements and simple is
On Jul 11, 2008, at 2:45 AM, Patrick Mau wrote:
Do you think that observing lots of objects with lots
of keypaths is a good idea anyway?
Honestly, I've forgotten the original design issues you're considering.
If you need to observe lots of objects and key paths to achieve your
purposes, the
Ken Thomases wrote:
> How about a dictionary whose keys are NSValues representing the
> objects? For each object, the value from the dictionary would be an
> NSMutableArray whose elements are the key paths being observed on that
> object.
>
> // ...
> NSValue* objectKey = [NSValue valueW
On Jul 10, 2008, at 4:55 PM, Patrick Mau wrote:
I'd like to show you one ugly detail. I put all observed objects,
including their keyPath in a local NSDictionary, because I have to
remove the observers on deletion of a table row. The 'observeObject'
looks like that:
- (void)observeObject:(id)o
I. Savant wrote:
>> Check out this page:
>>
>> http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
>>
>
> I should also mention that you should approach these examples like this:
>
> 1 - Read the Cocoa Bindings documentation (including all the Key Value
> Coding / Key Value Observing r
> Check out this page:
>
> http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
>
I should also mention that you should approach these examples like this:
1 - Read the Cocoa Bindings documentation (including all the Key Value
Coding / Key Value Observing related documentation).
2 - Exam
> Where would you observe changes to data?
I think you should worry about one thing at a time (ie, leave the
animation part for another day and concentrate on your bindings
machinery first). Check out this page:
http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
Great examples of B
58 matches
Mail list logo
