extent of the "scratch pad" nature of a Core Data managed object context
Curious if anyone can confirm or deny a behavior of Core Data's managed object context. I understand that there is the committed/real-deal state of an on-disk, persistent store, and there is a managed object context (moc) that is described as a "scratch pad" that builds up modifications to the on-disk state and which can then be either committed or discarded. This is cool. Furthermore, the moc can be searched via a "fetch request", and I can control how a fetch treats proposed but uncommitted changes via the setIncludesPendingChanges method. Now, the question. If the pending changes within my moc includes the deletion of objects and the to-be-deleted objects include a relationship property with a "cascade" delete rule then should the pool of objects returned by an includesPendingChanges = YES fetch include the pending, directly deleted objects? What about the pending, indirectly deleted objects? It is my belief that the scratch pad nature of the moc does not extend into the full reaches of pending deletions. Thanks in advance. Mark Sanvitale Real Networks___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: predicate for a Core Data fetch request rejected by SQL
Thanks all for the sharing of thoughts. Glad someone could confirm that what I was attempting did not make sense from the SQL perspective (which I am a newbie to). But, like Sean wrote, Core Data seems to be presented as an abstraction ABOVE the layer which implements the actual storage/retrieval, thus, having to know about SQL details to get a Core Data operation to execute properly is unfortunate. Some additional thinking about things made me realize that my rant about how the docs had failed me was a bit misdirected. I pointed at the line, "You cannot necessarily translate “arbitrary” SQL queries into predicates" as being unacceptably vague. I now think that this statement is acceptable. Since Core Data is a concept separate from (though related to) SQL, you cannot expect to be able to bring every SQL-ism into the Core Data world and have it function properly (i.e. SQL ≠ Core Data). However, my experience seems to demonstrates that the statement "We (the system) cannot necessarily translate “arbitrary” predicates into SQL queries" is also true, and I believe this concept should be expanded to spell out exactly what generally legal predicates end up being illegal when applying them to a Core Data context that is backed by SQL. The only expanded discussion I can find on this subject in the official docs is, "predicates that rely on Cocoa cannot work", which, for me, does not shed enough light on the subject. Mark On Mar 5, 2010, at 3:45 PM, Joanna Carter wrote: > Hi Sean > >> But you shouldn't have to... Core Data is "not a database" and its use >> of SQL is an implementation detail. One shouldn't have to know anything >> about SQL to use Core Data. Of course, in practice, such knowledge is >> helpful, as you say. > > You have a point but, in theory, predicates against lists of objects usually > take either the form: > > > > ... or possibly: > > > > Some predicates might be usable between two constant values but I have never > seen one used, even with lists of objects, as: > > > > Such a construct might work in the context of an XML file because the > lefthand term could be interpreted as the name of a key but, not normally in > a where clause in a database. > > Joanna > > -- > Joanna Carter > Carter Consulting > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
predicate for a Core Data fetch request rejected by SQL
RANT AGAINST DOCUMENTATION:
I have searched (a lot) and found various other pleas for help of the form, "I
am trying to do a Core Date fetch on an SQL-backed store and it is failing
because something is wrong with my predicate." I thought some investigate
could promote my plea beyond this basic level, but I seem to be hitting the
same wall-of-no-information as everyone else. This wall seems to built around
Apple believing it's official Core Data docs adequately describes the issues
with fetch predicates on SQL by stating, "You cannot necessarily translate
“arbitrary” SQL queries into predicates". Translation: "The issue with
predicates and SQL is that there are issues." Thanks for all the help, docs.
BEGIN PROBLEM AND QUESTION:
So, here is my plea for help. I have a predicate of the form: " BEGINSWITH path". In other words, I am searching entities that possess
a (string) property "path" to look for one whose path is a prefix of some
string (which is inserted into the predicate via the fetch-request-template
variable substitution). This fetch executes just fine on an XML store. The
same fetch on an SQL store yields: unimplemented SQL generation for predicate
("/Volumes/MacHD/Applications/Utilities" BEGINSWITH path).
My guess (given the lack of explicit documentation) is that SQL itself (or,
perhaps, just Core Data's use of SQL) does not allow the left-hand-side to be a
literal string, rather, it wants the left-hand-side to be a property key or
key-path. Anyone know if this is actually the case?
So far, in the world of "path has to be on the left-hand-side" I have not
formulated a predicate that can determine if path is a prefix of the supplied
string. Yes, I can fetch all entities from the DB and then do an in-memory
search amongst the paths. Just hoping I could have the fetch do all the work.
Mark Sanvitale
Real Networks
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSScrollView & its width
I can't say that I have dealt with the exact situation you write of, however,
my best idea/hint is to point you to the NSTextContainer class. The NSTextView
is composed of a lot of complicated machinery and I believe you might have to
dive below the topmost layer (i.e. NSTextView itself) in order to achieve your
desired results. Your documentView (the textView) will continue to size its
width according to the contentView, but the internal "view container" for the
rich-text object being displayed inside of the textView will need to be told
not to maintain this same, width-sync'd relationship.
(I repeat, this is only a somewhat educated stab-in-the-dark, i.e. I have used
NSTextContainer's setWidthTracksTextView method. More informed people should
still be encouraged to reply.)
Good luck.
Mark Sanvitale
On Feb 4, 2010, at 1:45 PM, Knut Lorenzen wrote:
>
> Dear List,
>
> an NSScrollView ("Show Horizontal Scroller" in IB checked) contains an
> NSTextView that displays some RTFD-data, including some pictures. However,
> the Horizontal Scroller is not shown. BTW, TextEdit seems to behave exactly
> the same.
>
> Logging [[myScrollView documentView] frame].size.width shows that it has the
> same value than [[myScrollView contentView] frame].size.width. Please note
> the difference: documentView vs. contentView. That is, it looks like the
> documentView does not notice the presence of pictures wider than the
> contentView?!
>
> I've tried setting the documentView's frame width to the width of the largest
> picture. That sort of works, but as soon as the window (or the view) is
> resized, everything snaps back to the undesired state.
>
> Looking forward to ideas/hints/clues/advice.
>
> Cheers,
>
> Knut
>
>
>
>
>
> ___
>
> 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/msanvitale%40real.com
>
> This email sent to msanvit...@real.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: CoreAnimation "breaks" when switching from NSView to NSBox
Thanks for the tip Ken. It had forgot about the automatically-created contentView, and that was indeed the source of my problem. Besides setting up animation for the contentView, I also had to switch to calling replaceSubview on the contentView instead of directly on the NSBox. Thanks again. On Feb 2, 2010, at 2:56 PM, Mark Sanvitale wrote: > Hi Mark, > > You probably want to set the animations on the box's contentView in addition > to the box itself. > > Box forwards modifications to its subviews array to its contentView. > However, this is something we'd like to get rid of eventually. It's just a > question of doing it compatibly, having time to evaluate the impact on apps, > etc. > > -Ken > Cocoa Frameworks > > On Tue, Feb 2, 2010 at 10:56 PM, Mark Sanvitale wrote: > "Breaks" is a subjective description (thus the quotes) for what I > experienced, but from my perspective it is accurate. Here's what happened. > I had a custom subclass of NSView and I setup it up (in code) to be > layer-backed with a CATransition for the "subviews" key (i.e. fade in/out > animation for changes to the subviews). All is well. > > Changed this custom subclass to descend from NSBox (instead of NSView) so I > could take advantage of the selection-highlighting-within-a-Collection-View > trick demonstrated in the "IconCollection" (Apple-provided) sample project > (take an NSBox with a fill color and bind its transparent property to the > "selected" property of its associated NSCollectionViewItem). > > A day or so later I notice that my fade in/out animation is gone. Eventually > track this regression down to the change from NSView-subclass to > NSBox-subclass. > > Should I be surprised by this difference in behavior between NSView and > NSBox? I have been setting up my animation via: > >[self setWantsLayer:YES]; >[self setAnimations:[NSDictionary dictionaryWithObject:transition > forKey:@"subviews"]]; > > and then expecting animation to occur when executing this: > >[[self animator] replaceSubview:mThumbnailStandin with:mThumbnail]; > > perhaps there is some other way to install/provide my animation that NSBox > will respect? > > Any ideas? I realize there is the straightforward approach of staying with > an NSView sub-class and doing my own binding-friendly fill color. > > Thanks in advance. > > Mark Sanvitale > > ___ > > 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/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
CoreAnimation "breaks" when switching from NSView to NSBox
"Breaks" is a subjective description (thus the quotes) for what I experienced, but from my perspective it is accurate. Here's what happened. I had a custom subclass of NSView and I setup it up (in code) to be layer-backed with a CATransition for the "subviews" key (i.e. fade in/out animation for changes to the subviews). All is well. Changed this custom subclass to descend from NSBox (instead of NSView) so I could take advantage of the selection-highlighting-within-a-Collection-View trick demonstrated in the "IconCollection" (Apple-provided) sample project (take an NSBox with a fill color and bind its transparent property to the "selected" property of its associated NSCollectionViewItem). A day or so later I notice that my fade in/out animation is gone. Eventually track this regression down to the change from NSView-subclass to NSBox-subclass. Should I be surprised by this difference in behavior between NSView and NSBox? I have been setting up my animation via: [self setWantsLayer:YES]; [self setAnimations:[NSDictionary dictionaryWithObject:transition forKey:@"subviews"]]; and then expecting animation to occur when executing this: [[self animator] replaceSubview:mThumbnailStandin with:mThumbnail]; perhaps there is some other way to install/provide my animation that NSBox will respect? Any ideas? I realize there is the straightforward approach of staying with an NSView sub-class and doing my own binding-friendly fill color. Thanks in advance. Mark Sanvitale ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
can NSCollectionView be made to ask for properties in a lazy manner
I have an array within a model object that is hooked up to a NSCollectionView via an NSArrayController and NSCollectionViewItem (i.e. standard). The array elements are custom objects with a title and image property. These are bound to an NSTextField and NSImageView within the view managed by the collection-view-item. Hook all the bindings up and go. It works... basically. Problem: the properties for EVERY element within the array are requested when the collection view appears on screen. Well, really, I am binding the collection view to the array controller in code within awakeFromNib and the trouble happens at the point of binding (thus, I think the ask-for-everything really happens independent of the appear-on-screen issue). Partial/edited backtrace: my call to [collectionview bind:toObject:withKeyPath:options:] triggers [collectionview setContent:] [collectionview _getItemsToDisplay] [array-element image] I guess "_getItemsToDisplay" does not care about what is actually being displayed NOW vs. the entirety of what can be displayed. This was not what I was expecting nor wanting. My experience in the datasource flavor of NSTableView led me to believe (and be happy about) UI elements not asking for display data until view/cell associated with said data was truly on-screen. Perhaps NSTableView is just as greedy about touching every element once you depend on bindings (but I'm guessing not). Question: can this behavior be avoided through simple means? I have seen some related discussions ( http://lists.apple.com/archives/Cocoa-dev/2009/Jan/msg01536.html ) but I believe the discussed situations (and potential solutions to them) do not cover my setup (which I think would be a common one). I don't need to build the array-like structure as I go and, thus, I don't care if some part of bindings asks for the entire array of content. What I care about is the properties of the elements in this array being accessed before the associated row appears on-screen. The image property is calculated on-demand and it is better performance and memory usage to NOT pre-calculate every image. Do I have to hack away or can the collection be convinced to operate in this (I think, obvious/superior) "lazy loading" style? Thanks in advance. Mark Sanvitale Real Networks ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: compiler warning for not fully implementing protocol
I copied your code from Mail and pasted it into a text file.
[ip193:~/Desktop] mas% cc test.m -framework Foundation -o test
test.m:33: warning: incomplete implementation of class
'PortalActionView'
test.m:33: warning: method definition for '-displayCapture' not found
test.m:33: warning: class 'PortalActionView' does not fully implement
the 'ReadArchiveClient' protocol
Yes, you are correct that "PortalActionView conforms" is printed out
when you run the resulting program. That is exactly my point.
Everything is fine. The runtime knows it. But at build time the
compiler thinks otherwise.
Of course, perhaps these warnings are not actually being output on
other systems. I am running 10.4.11, 'cc --version':
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5370).
But, hey, the warnings are harmless and can even be avoided with the
elegant:
- (id)displayCapture { return [super displayCapture]; }
I will just write a bug and see what the powers that be think.
Thanks.
On Jul 31, 2008, at 8:13 PM, Adam R. Maxwell wrote:
On Jul 31, 2008, at 4:14 PM, Mark Sanvitale wrote:
I think I am doing exactly what you say is necessary (i.e. declare
the second method in the superclass's public interface).
Here are some code snippets:
Turning your code snippets into a test program, I can't reproduce
that compiler warning, or in a trivial test where the superclass
declares/implements copyWithZone: and the subclass declares
conformance. If this works for you, what did I miss?
// File test.m, compile & run with `cc test.m -framework Foundation
-o test && ./test`
#import
@protocol PortalTabProtocol
- (void)refreshDisplay:(id)capture because:(int)trigger;
@end
@interface PortalTabView : NSObject
- (NSString *)tabName;
- (void)refreshDisplay:(id)capture because:(int)trigger;
- (id)displayCapture;
@end
@protocol ReadArchiveClient
- (id)displayCapture;
- (void)processedArchive:(id)archive;
@end
@interface PortalActionView : PortalTabView
@end
@implementation PortalTabView
- (NSString *)tabName; { return nil; }
- (void)refreshDisplay:(id)capture because:(int)trigger; {}
- (id)displayCapture; { return nil; }
@end
@implementation PortalActionView
- (void)processedArchive:(id)archive {}
@end
int main (int argc, char const *argv[])
{
NSAutoreleasePool *pool = [NSAutoreleasePool new];
id obj = [[PortalActionView alloc] init];
if ([obj conformsToProtocol:@protocol(ReadArchiveClient)])
NSLog(@"PortalActionView conforms");
else
NSLog(@"PortalActionView does not conform");
[pool release];
return 0;
}
___
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: compiler warning for not fully implementing protocol
I think I am doing exactly what you say is necessary (i.e. declare
the second method in the superclass's public interface).
Here are some code snippets:
PortalTabView is the super class (which happens to also adopt a
protocol, which is not part of this issue but including it for
completeness):
@protocol PortalTabProtocol
- (void)refreshDisplay:(XBCapture *)capture because:(XBRefreshCause)
trigger;
@end
@interface PortalTabView : NSView
{}
- (NSString *)tabName;
- (void)refreshDisplay:(XBCapture *)capture because:(XBRefreshCause)
trigger;
- (XBCapture *)displayCapture;
@end
PortalActionView is the class that gets the compiler warnings about
the ReadArchiveClient protocol:
@protocol ReadArchiveClient
- (XBCapture *)displayCapture;
- (void)processedArchive:(WebArchive *)archive;
@end
@interface PortalActionView : PortalTabView
So, PortalActionView does implement processedArchive: (without
declaring it in its interface) but the displayCapture method is
coming from its super class which does declare this method in its
public interface, yet the compiler complains "method definition for '-
displayCapture' not found". Complier bug?
On Jul 31, 2008, at 1:13 PM, Bill Bumgarner wrote:
On Jul 31, 2008, at 11:36 AM, Mark Sanvitale wrote:
I have a formal protocol that declares two methods. I have a
class that adopts this protocol. This class implements one of the
protocol methods. This class inherits from another class. This
super class actually implements a method matching the signature of
the second method declared in the protocol. Everything runs just
fine, however, the compiler insists something is wrong by warning
me "incomplete implementation of class X", "method definition for
'' not found", and class 'X' does not fully implement
the 'Y' protocol".
I think the compiler is wrong. Or is this "by design" according
to some strict rule(s) of Objective-C? Am I expected to redefine
the method I inherit from my super class if the method is part of
a protocol I adopt?
The compiler has no way of knowing that the protocol's contract was
fulfilled by the superclass unless you also declare the second
method in the superclass's public interface.
If you don't want to expose the method's declaration, declare it in
a private header.
b.bum
___
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]
compiler warning for not fully implementing protocol
I have a formal protocol that declares two methods. I have a class that adopts this protocol. This class implements one of the protocol methods. This class inherits from another class. This super class actually implements a method matching the signature of the second method declared in the protocol. Everything runs just fine, however, the compiler insists something is wrong by warning me "incomplete implementation of class X", "method definition for '' not found", and class 'X' does not fully implement the 'Y' protocol". I think the compiler is wrong. Or is this "by design" according to some strict rule(s) of Objective-C? Am I expected to redefine the method I inherit from my super class if the method is part of a protocol I adopt? Mark Sanvitale Exbiblio [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: custom NSButtonCell behaves different/wrong on Leopard
Well (much experimentation and head-scratching later), it turns out that this issue is not really a bug in Leopard, rather, it appears to be a case where a bug in Tiger allowed my buggy code to execute flawlessly on Tiger while the lack of this bug on Leopard caused the same buggy code to now exhibit buggy behavior on Leopard. True, the intention is that Tiger built apps will behave the same on Leopard, but in this case I can now understand and appreciate the discrepancy. My custom NSButtonCell had an accessor and a setter method for getting/ setting the roll-over effect. This roll-over effect is a highlight so I named the methods isHighlighted and setIsHighlighted. Without realizing it, I had unintentionally overrode the standard NSCell method isHighlighted (while not overriding the setter method, which is named setHighlighted, i.e. no "Is"). On Tiger, this mistake has no visual effect on the button behavior, but on Leopard this makes the button appear in the pressed state on mouse-over because my custom isHighlighted, meant to indicate do-the- roll-over-effect, will mistakenly tell the standard NSButtonCell code to do-the-pressed-effect. Thus, I guess I should write a bug against Tiger ;-) Thanks for responding. I'm happy to have finally figured this out. On Jul 15, 2008, at 12:56 PM, Ken Ferry wrote: Hi Mark, Could you file a bug with a test app please? There are basically two reasons for a button to display alternate content. (1) The cell's state is not NSOffState and the showsStateBy mask contains NSContentsCellMask. (2) The cell is highlighted and the highlightsBy mask contains NSContentsCellMask. The 'button types' you see in IB (and in -[NSButtonCell setButtonType:]) correspond to different configurations of the showsStateBy and highlightsBy masks. A 'momentary change' button has NSContentsCellMask set in its highlightsBy mask and a 'toggle' button has NSContentsCellMask in its showsStateBy mask. -Ken On Tue, Jul 15, 2008 at 12:39 AM, Mark Sanvitale <[EMAIL PROTECTED]> wrote: Summary of the problem is that I have a custom NSButton subclass which accomplishes a roll-over effect (title and background take on a special appearance when the mouse is over the cell). On Leopard, these same cells appear to perform a state change on mouse-over (the title and the image switch to their alternate state), but the state has not actually changed (according to gdb interrogation) and the title and image return to the normal state when the mouse leaves the cell/button. Anyone seen this problem? Anyone know what is/could-be going wrong? The details: My custom NSButtonCell subclass defines some new, custom methods, and it completely overrides drawBezelWithFrame, while it augments (i.e. still call through to super) the methods drawInteriorWithFrame, drawTitle, and drawImage. These cells appear in the window inside of a custom NSMatrix subclass which does the necessary mouse event handling to accomplish roll-over. This all works fine and good on Tiger. On Leopard (with no code changes and the binary compiled on either Tiger or compiled against the 10.4 sdk on Leopard), the same button behaves wrong. The title and image being passed into the drawTitle and drawImage state are the alternates when the mouse is over the button, even though when I interrogate the cell in the debugger the state has not changed (still NSOffState, i.e. the normal, not alternate state). I can counteract the problem by ignoring the passed in title/image and determining it myself according to the current cell state, i.e. image = ([self state] == NSOffState) ? [self image] : [self alternateImage]; title = ([self state] == NSOffState) ? [self attributedTitle] : [self attributedAlternateTitle]; however, one problem still persists (beyond the obvious confusion as to why such a tactic is even necessary) whereby the dimming of the image does not happen on mouse-down but, rather, happens on roll-over when the button is in the alternate state. I'm at a loss. Please help me. Mark Sanvitale Exbiblio [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/kenferry%40gmail.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
custom NSButtonCell behaves different/wrong on Leopard
Summary of the problem is that I have a custom NSButton subclass which accomplishes a roll-over effect (title and background take on a special appearance when the mouse is over the cell). On Leopard, these same cells appear to perform a state change on mouse-over (the title and the image switch to their alternate state), but the state has not actually changed (according to gdb interrogation) and the title and image return to the normal state when the mouse leaves the cell/button. Anyone seen this problem? Anyone know what is/could-be going wrong? The details: My custom NSButtonCell subclass defines some new, custom methods, and it completely overrides drawBezelWithFrame, while it augments (i.e. still call through to super) the methods drawInteriorWithFrame, drawTitle, and drawImage. These cells appear in the window inside of a custom NSMatrix subclass which does the necessary mouse event handling to accomplish roll-over. This all works fine and good on Tiger. On Leopard (with no code changes and the binary compiled on either Tiger or compiled against the 10.4 sdk on Leopard), the same button behaves wrong. The title and image being passed into the drawTitle and drawImage state are the alternates when the mouse is over the button, even though when I interrogate the cell in the debugger the state has not changed (still NSOffState, i.e. the normal, not alternate state). I can counteract the problem by ignoring the passed in title/image and determining it myself according to the current cell state, i.e. image = ([self state] == NSOffState) ? [self image] : [self alternateImage]; title = ([self state] == NSOffState) ? [self attributedTitle] : [self attributedAlternateTitle]; however, one problem still persists (beyond the obvious confusion as to why such a tactic is even necessary) whereby the dimming of the image does not happen on mouse-down but, rather, happens on roll-over when the button is in the alternate state. I'm at a loss. Please help me. Mark Sanvitale Exbiblio [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]
