Re: Right place to unobserve notifications in a document
Am Mo,18.08.2008 um 20:14 schrieb Andy Lee: Since the observed object (maybe notification center) will still hold a reference to the observing object, there is a problem. The *observer* will not be freed, if the observed is still living. Obviously you have a problem using GC, for example if you have an observing window and an observed model instance. The model probably lives longer than the window. (Think of info windows …) This seems to be the reason for the weak reference using GC. I've been reading this thread and I don't understand it in the case of GC. Why don't you still have to remove the observer from the notification center when you are not longer using it. Even if it is held as a weak reference, it will still remain registered for receiving notifications, so what when the observer is eventually collected, won't the notification center continue sending messages to the observer as long as it remains registered to receive them?, Please clarify. Joan Lluch ___ 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: Right place to unobserve notifications in a document
Joan Lluch El 20/08/2008, a las 16:05, Negm-Awad Amin escribió: Am Mi,20.08.2008 um 15:37 schrieb Joan Lluch (casa): I've been reading this thread and I don't understand it in the case of GC. Why don't you still have to remove the observer from the notification center when you are not longer using it. Even if it is held as a weak reference, it will still remain registered for receiving notifications, so what when the observer is eventually collected, won't the notification center continue sending messages to the observer as long as it remains registered to receive them?, Please clarify. First I want to say, that I'm happy to have a thread on this list, which is not related to a concrete problem, but discusses a design. I like that. :-) Second: As you read, *I* would prefer to unregister the observer explicitly. You can do this in -finalize, but I do not have to repeat the design problems with finalization. *I* wanted a delegate method or a defined method to be overwritten in a subclass (I mentioned -close) to do it explicitly, *before* destroying the object. You ask the wrong person … Third, to your question: Weak references in GC – they have nothing to do with retainless weak references using RC – are nullified automatically. If you use GC the weak collection should be modified appropiate by the collector itself. So this might be no problem. (I didn't test it, because it is not my idea.) I understand what is your preferred approach, which it is also what I would do. I can add to it that I even thought that you *have to* *always* unregister the observers when you have done with them. This is obviously true in RC environment, but this is apparently not true in the case of GC. This is the part I don't get. I would appreciate if someone would clarify it for me. Joan Lluch ___ 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]
Where's the best place for addObserver and removeObserver
I am coding a single window, multiview, app, and as what I think is a recommended design pattern I only load the views controllers (and therefore their views) from their nibs as they are required, and then I retain them in the main window controller so they do not have to be loaded again each time the user switches from one view to another that has been previously shown. As part of my application, I also need the views to react to changes on several conditions of the whole application, an thus for each view I set up observers to the relevant keyPaths of the application delegate by using: [[NSApp delegate] addObserver:self forKeyPath:@myKey options:NSKeyValueObservingOptionNew context:nil] ; in the view controller awakeFromNib method and [[NSApp delegate] removeObserver:self forKeyPath:@myKey] ; in the view controller dealloc method So far so good. However, the way I am doing it makes me wonder where the best place should be for adding and removing the observers. What I am currently doing is adding the observers in the awakeFromNib methods of each viewController, and removing them in the dealloc method of the same controller. I think that adding the observers in awakeFromNib methods is fine, but the fact that I retain the view controllers implies that such controllers are still observing the application delegate even if they are not currently showing. Is this a good coding/design pattern?. Furthermore, if I eventually switch to Garbage Collection in the future, those observers will not ever be removed. Or worse, in case I decided not to keep a reference in my window controller, and the GC eventually claims an unused view controller, then what will happen to the observers. Would someone bring a light to this.? Basically what i am asking is, where is the recommended place to add and to remove observers set up in views (or view controllers)? Thanks for any comment. Joan Lluch ___ 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: Where's the best place for addObserver and removeObserver
El 17/07/2008, a las 18:13, Jonathan Dann escribió: Hi Joan, As Keary says, removing in -dealloc is probably not the best thing to do as there are a few cases that this can bite you, like if your window controller retains the view controllers, and -dealloc is called on the window controller, which would proceed to release its collection of view controllers. In this case you get console logs a- plenty informing you that the window controller is being deallocated while observers are still registered with it. Well, it does not happen in my case because the observed property is in the Application delegate, but you are right that I would get into this if I was observing something in the window controller What I do is get all the view controllers to conform to a formal protocol called DetailViewController. The protocol has two methods that the conforming parties must implement, - becomeDetailViewController: and -resignDetailViewController: (the names are a result of my master/detail view setup in my app). In these methods the receiver can setup and tear-down both bindings and observations. Thanks, I understand this approach and it is much safer than mine. Furthermore, I can easily find the right place in my window controller to send these messages because I already have implemented insertion and removal of my view controllers to/from the responder chain so they can pick up menu actions So when I swap a view in or out I have a single - swapDetailViewWithView: method in my windowController that wraps the call to the window's content view -replaceSubview:withView (I think that's the name) with calls to the current and potential detail view controllers -resign... and -become..., respectively. Exactly! Thanks again Joan Lluch___ 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: Is there any way to show disclosure button always closed in NSOutlineView
El 14/07/2008, a las 7:49, Aman Alam escribió: I am working on a project that needs the disclosure button of NSOutlineView always closed whether its row are expanded or not. Does anyone know that how to do that? Does not that violate the Apple Human Interface Guidelines?. I mean, what condition do you want to show. Joan Lluch___ 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: NSTableView prematurely posts selection changed notification
El 10/07/2008, a las 5:21, Graham Cox escribió: When my app starts up, it opens a floating window containing a table view. As the table is brought to life from the Nib, it posts a selection changed notification to its delegate. At that time it hasn't had its data initialised from the data model so the selected row is 0. This causes an undesirable change to the data model. Yes, this is an annoying behaviour. I ran some time ago with the same issue and I ended giving up, because after all it was not such a big issue in my app. To my knowledge, which is not much compared to some other members of this forum, this is not an easy task nor a bug, because it already does what it is supposed to to as far as KVO notifications is concerned. What triggers the change here is the selection state of the TableView, not the model, so the model gets updated as a consequence. The only way I think of to overcome this problem is to load the TableView without the selection binding, set manually the selected row, and then establish the binding with the model. Another possible approach is to cache the selected row (according to the model) just before the nib loads, and then manually re-set it after the nib has loaded, regardless of what its current value is now. However in this case you might have to turn temporarily off the undo manager to avoid registering for that 'phantom' change. I didn't try any of the above though. I will be interested in your developments with regard to this subject, though. Joan Lluch___ 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: Why can't I name a property `tag'?
Joan Lluch El 10/07/2008, a las 18:29, Graham Cox escribió: Well, that's the weird thing. I wasn't getting that warning. I was including both headers, my own usage explicitly using #import, and all of Cocoa implictly using the precompiled headers. I wonder if that's how the compiler fails to notice the ambiguity - because of one being in a precompiled header? I don't know enough about how that works to be sure. Does this warning have to be explicitly turned on, or is it on by default? What's the flag? G. It's default. And you should get it after a clean all and then build. If not this is a bug. Since warnings does not show again once a file has been successfully compiled you might have missed that one in the first place, or have added the second (offending) method after the headers were precompiled, so a warning never showed. Just my guess. Joan Lluch ___ 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]
NSOutlineView hiding a column while editing a row in another column
I have a NSOutlineView which I want to make several columns hidden in response to a user action. I have set up the outlineColumn to resize with table and the rest have fixed size, so that when one or more columns are hidden, the outlineColumn widens accordingly. In normal conditions everything goes as expected. However, if the user is editing a row of the outlineColumn and then decides to hide a different column, the focus ring of the resized outlineColumn is not changed and the result is a mess of several columns in that row. I just need a way to tell the outlineView that update the size of the cell being edited (and its focus ring), or simply a way to programatically commit and accept the user changes on the cell. I can not use commitEditing because the outlineView is not bound to any controller, and I use the data source methods instead. Any help will be appreciated Joan Lluch ___ 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: Debugging strategy - exceptions
El 09/07/2008, a las 12:13, Ruotger Skupin escribió: So an exception got thrown for a pretty obvious reason, but where? Could be anywhere, even in WebKit (which we use). Is there any chance to get near the culprit without a stack trace (which I don't have)? This question is more suitable for the Xcode-user list, but anyway, you should get a proper stack trace by breaking at objc_exception_throw. Did you try it? Joan Lluch___ 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: garbage collection and NSConnection
El 07/07/2008, a las 0:18, Hamish Allan escribió: On 7/4/08, Chris Hanson [EMAIL PROTECTED] wrote: Under non-GC, an object's memory may not be reclaimed until the current autorelease pool is drained. However, under GC, an object's memory can be reclaimed as soon as the collector can tell there are no more references to it -- no matter when that is. I think Joan's point is not that there are circumstances in which the GC will never reclaim, but that it is not possible to ensure reclamation deterministically. [...] Collection is subject to interruption on user input -- with no mention of when it might be re-started. Hamish Thanks Hamish. That was exactly my point, and that citation of the documentation gives more plausibility to it. (my native language is not English, nor I live in an English speaking country so it can be sometimes difficult for me to express complex things or to know the more appropriate word to express a concept, this is why I tend to paraphrase on my writing, and I understand that it can be difficult to read). Joan Lluch ___ 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: archive only what changed?
Core Data does a really good job at what you are describing, when using SQLite as a persistent store, although this may not be what are you looking for. The only other approach to this that I think of is to cache the objects that change in your model and then only store these objects either directly or by tweaking the NSCoding protocol methods in your model, but then your code will have to be clever enough to know what files or parts will have to retrieve if a revert operation is requested. However, it looks to me too complicated or worthless to follow that route. If storing your model is really a performance issue, then you might consider going to Core Data and SQLite stores. Joan Lluch El 07/07/2008, a las 16:13, Randy Canegaly escribió: I have an application whose data model is an NSMutableArray with elements that could be pointers other NSMutableArrays, much like what you would navigate with a NSIndexPath. I am using NSKeyedArchiver to archive the data model to a file. Right now I archive the entire top level array object (and therefore all its parts) to the file using archiveRootObject:toFile. Is it possible to archive only the portion of the data model that changed rather than the entire thing every time? I need the entire data model to be archived so that it can be reloaded when the application starts but for performance reasons I am interested in seeing if it's possible upon a change to the data to only re-archive the small part that changed. ___ 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/carbonat%40grn.es 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: garbage collection and NSConnection
El 06/07/2008, a las 2:05, mmalc crawford escribió: On Jul 5, 2008, at 3:00 PM, Joan Lluch (casa) wrote: However, let me copy an excerpt of the Cocoa documentation on the GC algorithm that Cocoa uses. You haven't updated your documentation since the beginning of November last year. Oops, thanks. Looks as it is time for me to update things... I will give the Cocoa GC another try before adding another comment, (my apologies, I might be testing an earlier version) By the way, how do I know for sure that a set of documentation corresponds to a particular version of the SKD. I am using XCode 3.0 for mac development since I believe it is the latest non pre-release version of the dev-tools and the documentation files that came with it. Is 3.1 already intended for use for mac development?. Since this post will go out of topic I am also posting this on the Xcode lists, where I think I should receive a more appropriate answer. Joan Lluch___ 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: garbage collection and NSConnection
El 30/06/2008, a las 19:33, [EMAIL PROTECTED] escribió: hey, I have a project that uses Bonjour for some of its communication, theres a server and a client, and I was having tremendous difficulty getting it to work, pouring and pouring over my code, only to discover some weeks later that for some odd reason, NSConnections do not work when the project is set to support or require garbage collection. As a test I set garbage collection to: Unsupported, and the app compiled, and the NSConnection returned the proxy object as expected. But the app obviously failed to do much else, because I had no retain, release, or autorelease method calls. I am not a lazy person, but I am a novice programmer, and the retain, release, autorelease stuff in cocoa is horrible. I was very happy when garbage collection was added to Cocoa, and my projects became much easier to develop, and maintain. Now however, I find myself with a project riddled with memory problems that did Not exist just a few days ago, and as far as I can tell, I don't have any choice... My app either gives up Bonjour, or I have to retrofit the whole thing to manage its own memory with a system that is, lets face it, poorly envisioned. can anybody shed any light on this? am I really stuck managing the memory myself? This is intolerable. cheers, -eblu ___ Well, it always takes a risk to embrace a technology that is just released, such as garbage collection. Cocoa APIs and the Objective-C language was not designed from its origins with garbage collection in mind, so it must have been a really tedious and bug prone process for Apple to convert all the frameworks to properly work in a managed memory context. This is unlike Java and C#, which have been created from the beginning with such feature. In any case, Garbage collection is neither good or bad, it certainly allows you to not have to care about Zombies and Leaks, but you will still have to think about the lifetime of objects. You will still have to remove observers, or unbind objects, and think that your objects will be eventually reclaimed by the garbage collector, in an undefined order, so you will have to implement finalize methods. From my experience, at the end of the day, coding in a garbage collected environment, is not such a better deal. Obj-C, unlike C++, has a very clean way to deal with memory: the release/autorelease/ retain way to manage your memory, along with autorelease pools, and the consistence of the Cocoa APIs with respect to returned objects, are heaven compared to what you have to implement in C++, or other not managed memory languages. Basically, all you have to do is to always return autoreleased objects from your methods, and always send release to objects that you created with alloc or were returned by any method containing new or copy. Also, if you only use the standard accessor methods for setting properties, (which send release to the old object and retain the new one), you will not incur in any memory problem. It should not be that hard, and at the end your application will potentially perform better, and for sure it will eat significantly less memory. Joan Lluch. ___ 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 deal with a MenuItem with both a binded state property and an action method
El 28/06/2008, a las 18:44, Keary Suska escribió: 6/28/08 8:54 AM, also sprach [EMAIL PROTECTED]: To sumarize, the problem is that I am not able to change the menuItem state programatically (ie. in myAction) without avoiding the second call to setMenuState. However if the call to myAction comes from a button set up in IB (instead the menuItem), then everything goes ok. In that case myAction is called by the click of the button and if the state of the menuItem is updated by myAction then it is correctly changed. No second call to setMenuState is received because the originating event came from the button. On the contrary if the event originates from the menuItem, first myAction is called, and then setMenuState is called. With controls, the bound value is changed *before* the target-action is called, as you are seeing, but it seems NSMenuItem does the opposite. If the calls are sequential--i.e. without a call to the run loop--you could use performSelector:withObject:afterDelay:to make the setMenuState call. Thanks, I am not absolutely sure because I did several changes in my project but I think that this can be considered a bug of 10.5 sdk, because it started to happen when I started to compile for it. The (almost) same project when it was targeted for Tiger always changed the bound value *before* the target-action was executed, regardless if it was a button or a menuItem. Apparently this consistency has been broken in Leopard. I may post a bug report after some testing to confirm it. Joan Lluch.___ 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 deal with a MenuItem with both a binded state property and an action method
El 28/06/2008, a las 0:23, Keary Suska escribió:
6/27/08 4:06 PM, also sprach [EMAIL PROTECTED]:
I am struck in what should be a simple task so I would appreciate any
help.
I have a menu item which I want to show a default on or off state, so
I set up a binding in IB to a BOOL monitor property in my
controller. This works ok and both the check mark in the menu item
and
the property are kept in sync whatever I change.
However, the menu item I am talking about is intended to trigger an
action that can fail, so I want to keep its ultimate state unchanged
in some cases. For this purpose I added an action method that checks
the original state of the menuState property and resets it
accordingly
depending on the success status of the performed accion.
The code looks as follows
- (BOOL)menuState { return menuState ; }
- (void)setMenuState:(BOOL)value
{
NSLog(@setMenuState (%d) called,value);
menuState = value ;
}
- (IBAction) myAction:(id)sender
{
do something...
if ( fail ) [self setMenuState:NO] ;
}
I observed that when the user clicks on the menu item the action
method is called before any change is made to menuState, but then
setMenuState may be called twice: one from myAction (if it fails) and
one from the frameworks. The problem here is that after the second
call both menuState and the menuItem no longer shows the intended
state.
When using bindings always stick to MVC--i.e., don't touch the menu.
If you
have to change the state, change the monitor value to reflect the
correct
state. IN any case, you don't say how the menuState property enters
into the
picture, vs the monitor property.
In fact monitor is meant to be the same as menuState, Sorry, it
was a typo since I was trying to use more understandable names for the
dev-list. In the real app I am using monitor as the name of the
variable but I thought menuState would be more a appropriate name
for discussion here. So let's forget monitor ;) menuState is the
model property that is binded to the menuItem value.
As you suggest, I actually do stick to MVC and KVC, so I only change
the menuItem state through the model menuState property as shown in
the myAction method.
The problem remains because when the user selects the menuItem the
following happens:
FIRST- myAction is executed (possibly setting menuState to an
appropiate value)
SECOND - setMenuState is executed with a value contrary to the last
one, so if I had set it to NO in myAction, it is called now with YES,
destroying completely the intended behaviour. The menu item then shows
the wrong state in the running app.
I thought that I could get rid of the myAction method and observe the
menuState property instead, but the whole problem still would remain
because I still want to be able to set menuState to an appropriate
state while observing it. Finally I could use some flag variable to
tell me whether the setMenuState call comes from the menuItem click or
from my own code, but that seems rather weird to me and I believe that
there should be a cleaner way.
Any help is appreciated.
Joan Lluch
___
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 deal with a MenuItem with both a binded state property and an action method
El 28/06/2008, a las 9:59, Ken Thomases escribió: On Jun 28, 2008, at 2:41 AM, Joan Lluch (casa) wrote: The problem remains because when the user selects the menuItem the following happens: FIRST- myAction is executed (possibly setting menuState to an appropiate value) SECOND - setMenuState is executed with a value contrary to the last one, so if I had set it to NO in myAction, it is called now with YES, destroying completely the intended behaviour. The menu item then shows the wrong state in the running app. From where is this second call to setMenuState: coming? Put a breakpoint on it and backtrace. In Xcode's Breakpoints window (Run Show Breakpoints), toggle open the breakpoint's disclosure triangle. Click the plus button to add a debugger command. Enter bt as the command. Enable the Log checkbox beneath the debugger command field. Click the checkbox in the continue (▐▶) column, so that the program automatically continues after the breakpoint fires. With this setup, the debugger console will get a backtrace every time your setMenuState: method is called, but it won't annoying break the flow of your application or require you to hit continue each time. Cheers, Ken Thanks for the debugger tip, I didn't know it. Both calls come ultimately from AppKitMenuEventHandler, although the first one comes through myAction (as it is intended when it fails to do its thing). Actually, the menuItem event handler calls myAction because it is its action, and then calls setMenuState because menuState is binded to its value property. Looks all normal but unfortunatelly if myAction sends NO to setMenuState (first call), the following call to setMenuState (second call direct from the event hander) receives YES and vice-versa. So the second call from the event handler is always produced with the reverse state than the current menu item state (this is expected) but unfortunately it is still called after myAction has set the state, ruining the behaviour. To sumarize, the problem is that I am not able to change the menuItem state programatically (ie. in myAction) without avoiding the second call to setMenuState. However if the call to myAction comes from a button set up in IB (instead the menuItem), then everything goes ok. In that case myAction is called by the click of the button and if the state of the menuItem is updated by myAction then it is correctly changed. No second call to setMenuState is received because the originating event came from the button. On the contrary if the event originates from the menuItem, first myAction is called, and then setMenuState is called. Sure, all this can be solved by using a flag variable handling the different cases or by directly setting the menu item state without using bindings but I think that It should not be that tedious to do what I intend to. Cheers, Joan ___ 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]
Class Browser and Code Sense not fully working
Since I upgraded to XCode 3.0 the Class Browser is not longer showing frameworks methods, and also code sense is only showing methods from my own project. I am not able to figure out what setting I should change to remedy this. I have XCode 2.5 installed alongside 3.0 and it does not have this problem so it must be something related to 3.0 or my settings. Any help will be appreciated. Joan Lluch. ___ 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: NSTreeControllerTreeNode not documented? [solved]
El 08/06/2008, a las 13:31, Norbert Heger escribió: On Jun 8, 2008, at 11:28 , Joan Lluch (casa) wrote: An NSOutlineView which is binded to a NSTreeController gives instances of NSTreeControllerTreeNode in the item (or items) parameter of their datasource or delegate methods. For example: - (BOOL)outlineView:(NSOutlineView *)outlineView writeItems: (NSArray *)items toPasteboard:(NSPasteboard *)pboard would give an array of NSTreeControllerTreeNode objects in the items parameter. - (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item would give an instance of a NSTreeControllerTreeNode As far as I know, this class is not documented. How can I access (or know) the actual object in the NSTreeController that the item is refering to. See this thread: http://www.cocoabuilder.com/archive/message/cocoa/2008/3/25/202235 n.h. Thanks a lot. Somehow I hadn't figured out that a NSTreeControllerTreeNode was a subclass of a NSTreeNode.___ 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]
crash in outlineView:isGroupItem:
I am using outlineView:isGroupItem delegate method to create an
NSOutlineView that mimics the look of Mail.app or iTunes
- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item
{
return ( item [[item representedObject] isKindOfClass:
[GroupNode class]] ) ;
}
My oulineView is binded to a treeController that in turn is binded to
Core Data objects. The visual result is as expected and everything
goes ok. When I add hierarchical objects to the managedObjectContext
they correctly appear in the outlineView as expected. So far so good.
However, I observed that isGroupItem is called a lot more than
apparently necessary, and I did not not observe any clear pattern for
this. It is usually called as much as 20 or more times per item, in no
particular order and also interlacing calls for different items. This
should not be a big issue as far as the app remains responsible,
although I find it hard to understand why isGroupItem does behave that
way.
On the contrary, outlineView:willDisplayCell (below) behaves in a
completely consistent way, as it is being called exactly column times
for each row.
- (void)outlineView:(NSOutlineView *)sender willDisplayCell:(id)cell
forTableColumn:(NSTableColumn *)tableColumn item:(id)item
The problem with isGroupItem is that it crashes the app (also not
consistently) after several Undos performed on the
managedObjectContext (to remove recently added objects) as it is
eventually called with an already released item. I do not understand
it and I do not either know what to do or what to check in order to
avoid this. Since my app relies on bindings and Core Data it has not a
lot of code, and I am not able to find anything wrong in it.
Any help or hint to solve that issue will be appreciated.
___
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: Is there a way to efficiently access NSArray element contents?
El 08/06/2008, a las 20:13, Brent Fulgham escribió: I've been enjoying the NSArray/NSMutableArray classes as I work with various user interface features for a program I'm working on that interacts with a legacy C++ library. I've recently begun considering how to efficiently display the contents of a binary data stream. Currently I'm appending to an NSMutableArray of NSNumber objects, which is great for allowing me to bind to some UI elements in close to real time and has provided a simple and functional mechanism for text numerical display. Ideally, I'd like to be able to access a raw binary buffer of data so I could for example bind it to something like an OpenGL vector buffer for display. However, unlike an STL vector, I don't think the NS[Mutable]Array provides any guarantees of memory organization, nor any way to 'unbox' the NSNumber to deal with the internal values. For example, in the STL, I could make use of the fact that the vector template guarantees the storage to be in contiguous memory and accessible as raw double values through the address of the first element of the vector. However, I don't think this is possible via NSMutableArray and NSNumbers. Is my only option to periodically sync a buffer of binary double values by copying from the NSMutableArray on some periodic basis? Thanks, -Brent Since each item contained in an NSArray is a pointer to an object, you will not be able to retrieve them as raw data of different size even if the pointers in the NSArray were contiguous (which I believe they are) Did you consider using a NSMutableData object (or even a CFMutableData for efficiency) instead? You can use an intermediate (fixed length) C vector to receive the stream and transfer it in crunches to a CFMutableData object using the CFDataAppendBytes function. Then you can retrieve contiguous data of any length using the C pointer provided by CFDataBytePtr. However you will still have to transfer it to a NSArray to easily bind it to an user interface element such as a TableView. I guess you will have to consider if you give priority to the ease of binding to the UI or to the ease of accessing arbitrary length values from the stream. I would store the data in a CFMutableData object and then transfer it to a NSMutableArray when needed, not the other way round, but of course that depends on what you specifically want to achieve. ___ 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: crash in outlineView:isGroupItem:
El 08/06/2008, a las 22:11, Kyle Sluder escribió: On Sun, Jun 8, 2008 at 1:37 PM, Joan Lluch (casa) [EMAIL PROTECTED] wrote: return ( item [[item representedObject] isKindOfClass:[GroupNode class]] ) ; Style note: you don't need to do this. [[item representedObject] isKindOfClass:[GroupNode class]] will work just fine, because messages to nil return zero or their logical equivalent. So if item == nil, then [item representedObject] == nil, which means that [[item representedObject] isKindOfClass:[GroupNode class]] == NO. Of course, this all works only if the GroupNode class exists. ;-) --Kyle Sluder Yes, of course, objective-C allows you to send messages to nil but coming from a c++ background I just am used to do check for nullity first. On the other hand, checking an object for nil in an early stage will in some cases give a performance improvement. Not in the above code, obviously. :)___ 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]
How to catch all mouse clicking (or avoid multiple click filtering in startTrackingAt)
I have implemented a NSButtonCell subclass in the usual way to catch
mouse tracking. I get the startTrackingAt and stopTracking messages
called correctly on the first click of the mouse. However the
startTrackingAt is not quickly called again if I quickly click again
the mouse, such as if I did a double click. I mean, if I perform a
double or triple click I only get one pair of startTrackingAt and
stopTracking calls instead of the desired two or three pairs. So the
desired behaviour is to be able to catch all the mouse clicking
activity in almost real time. What I get instead is some filtering of
the actual mouse clicking. This is the way I implemented the methods
@implementation TrackButtonCell
+ (BOOL)prefersTrackingUntilMouseUp
{
return YES ;
}
- (BOOL)startTrackingAt:(NSPoint)startPoint inView:(NSView *)controlView
{
NSTableView *tableView = (NSTableView *)controlView ;
// do something
NSLog( @mouse down\n) ;
return YES ;
}
- (void)stopTracking:(NSPoint)lastPoint at:(NSPoint)stopPoint inView:
(NSView *)controlView mouseIsUp:(BOOL)flag
{
NSTableView *tableView = (NSTableView *)controlView ;
// do something
NSLog( @mouse up\n ) ;
}
@end
I observed that if I set the faster double click rate in System
Preferences, then I am able to catch all the clicking activity, so
the issue must be related to some multiple click filtering that Cocoa
does before calling the above code.
Sorry for my simple English, it is not my native language though I
try to do my best, I hope you all will understand.
Thanks in advance for any reply.
Joan
___
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: [solved] How to catch all mouse clicking (or avoid multiple click filtering in startTrackingAt)
Ken, you're Genius !! Overriding the mouseDown method of a subclassed control containing the cell and passing to its 'super' an identical NSEvent with clickCount always 1 did it ! Thank you for your help, I really appreciate it Joan El 25/04/2008, a las 09:02, Ken Thomases escribió: On Apr 25, 2008, at 1:29 AM, Joan Lluch (casa) wrote: I have implemented a NSButtonCell subclass in the usual way to catch mouse tracking. I get the startTrackingAt and stopTracking messages called correctly on the first click of the mouse. However the startTrackingAt is not quickly called again if I quickly click again the mouse, such as if I did a double click. I mean, if I perform a double or triple click I only get one pair of startTrackingAt and stopTracking calls instead of the desired two or three pairs. So the desired behaviour is to be able to catch all the mouse clicking activity in almost real time. What I get instead is some filtering of the actual mouse clicking. This is the way I implemented the methods I'm guessing that this filtering is being done in -[NSControl mouseDown:]. That is, if [theEvent clickCount] is greater than one, it doesn't invoke the cell's trackMouse:inRect:ofView:untilMouseUp: method. You can try subclassing the NSControl in question (presumably an NSButton?), overriding mouseDown:, and passing a different object to [super mouseDown:aDifferentEvent]. You can either create a new NSEvent whose properties are all the same as theEvent, or you can wrap theEvent in a proxy object which forwards all messages faithfully except clickCount, which it intercepts to always return 1. Good luck, 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
