Agent that displays a window with textbox
Hi Normal applications' windows allow to copy/paste text into textboxes that are located in these windows. But if an application is an agent, when i press "Control+V", the text can't be pasted in the textbox (it can be passed using a context menu, though) Is it me that I am doing anything wrong? Or it's how all agents behave and I can't fix this? It happens in Snow Leopard. Thank you! ___ 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
attribute is an array?
Hi, I'm trying to acccess a decimal attribute of an entity, and I can't work out why it's not working. I'm using the code below; NSString *price = [[product valueForKey:@"kitFee"] stringValue]; and I get this error: 2011-06-21 12:43:34.666 ishop[30901:10b] *** -[NSCFArray stringValue]: unrecognized selector sent to instance 0xe74f030 kitFee is a decimal attribute, and I can successfully get string attributes with this code, NSString *productName = [product valueForKey:@"kitName"]; Does the error message mean that it's getting an array for kitFee when it should be a value? I've cleaned and rebuilt, and it's sticking at this line, but I just can't see my error? I'd appreciate any help, Many Thanks Amy ___ 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: attribute is an array?
On 21-Jun-2011, at 7:48 PM, Amy Heavey wrote: > Hi, > > I'm trying to acccess a decimal attribute of an entity, and I can't work out > why it's not working. I'm using the code below; > > NSString *price = [[product valueForKey:@"kitFee"] stringValue]; > > and I get this error: > > 2011-06-21 12:43:34.666 ishop[30901:10b] *** -[NSCFArray stringValue]: > unrecognized selector sent to instance 0xe74f030 > > kitFee is a decimal attribute, and I can successfully get string attributes > with this code, NSString *productName = [product valueForKey:@"kitName"]; > > Does the error message mean that it's getting an array for kitFee when it > should be a value? > > I've cleaned and rebuilt, and it's sticking at this line, but I just can't > see my error? > > I'd appreciate any help, > > Many Thanks > > Amy NSString *productName = [ product valueForKey:@"kitName" ]; just assigns blindly whatever valueForKey: returns to an productName, which is really just an id which the compiler expects to be an NSString (ie the compiler will warn you if you call non-NSString methods on it). However that line alone doesn't prove that it's a NSString, could still be a NSArray. What are you doing with productName which proves it is in fact a string? Are you logging it, do you see '[]' in the log message which might be a hint it's an array of strings? What's product? Is that an array? valueForKey: on an array returns an array of answers. ___ 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: attribute is an array?
On 21 Jun 2011, at 6:48 AM, Amy Heavey wrote: > I'm trying to acccess a decimal attribute of an entity, and I can't work out > why it's not working. I'm using the code below; > > NSString *price = [[product valueForKey:@"kitFee"] stringValue]; > > and I get this error: > > 2011-06-21 12:43:34.666 ishop[30901:10b] *** -[NSCFArray stringValue]: > unrecognized selector sent to instance 0xe74f030 > > kitFee is a decimal attribute, and I can successfully get string attributes > with this code, NSString *productName = [product valueForKey:@"kitName"]; > Does the error message mean that it's getting an array for kitFee when it > should be a value? > > I've cleaned and rebuilt, and it's sticking at this line, but I just can't > see my error? My first steps would be to break in the debugger and type these in the console: po product po [product valueForKey: @"kitFee"] If product is an array, then sending valueForKey: to it would yield another array, with the kitFee of each member. Then you can audit your code to see why you're getting an array instead of what you wanted (did you forget that executeFetchRequest:error: returns an array?). Though if the same code, but with kitName, works, it would indicate that product isn't an array. — F ___ 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: Loop between observers with KVO from UIScrollView
Thank you for the answer. It just worked!
About the notes:
1.: should I just check if the object is different from self? Or some more
"complicated"? And what should I check as keyPath?
2.: if I send a context parameter from observer (the context can be a NSString
for example, right?), should I chech if the string is expected? And I only
should call super if the context is invalid? Reading Apple documentation I saw
that I should ever call super, but when I did it, the app crashed (I did not
went look what was wrong. Should I or it's not really necessary?)
Sorry, but I'm pretty new with KVO. I'm just read the KVO quick star guide and
KVO programming guide.
Em 20/06/2011, às 02:58, Quincey Morris escreveu:
On Jun 19, 2011, at 11:59, Tales Pinheiro de Andrade wrote:
if ([keyPath isEqualToString:@"contentOffset"]) {
CGPoint newContentOffset = [(UIScrollView *)object contentOffset];
newContentOffset.y = self.contentOffset.y;
self.contentOffset = newContentOffset;
}
It may be as simple as changing the above pattern to this pattern:
if ([keyPath isEqualToString:@"contentOffset"]) {
CGPoint newContentOffset = [(UIScrollView *)object contentOffset];
newContentOffset.y = self.contentOffset.y;
if (!CGPointEqualToPoint (self.contentOffset, newContentOffset))
self.contentOffset = newContentOffset;
}
But note:
1. You should really check the object (at least its class) as well as the
keyPath.
2. You should really use a context parameter that's unique for your
observations, and call super if the context isn't what you expect.
___
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: Progress Indicators Spin vs Bar
Thanks to all that provided code examples and suggestions on programming for concurrency. I am reading the docs to learn more on this subject. Jim Merkel ___ 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: Agent that displays a window with textbox
On Jun 21, 2011, at 2:11 AM, Nick wrote: > But if an application is an agent, when i press "Control+V", the text can't > be pasted in the textbox (it can be passed using a context menu, though) [You mean Command-V, right?] I think this depends on what you mean by “agent”. In Apple’s terminology, an agent is a background process with no UI that’s running in the user’s login session. Since your process has a window, it’s not strictly speaking an agent — how is the code packaged? If you’ve packaged your code to be truly background-only, but it links against AppKit and opens a window, I think all bets are off and you can expect things to misbehave. But if you just want a process that doesn’t show up in the Dock but can still open windows, what you want is an LSUIElement (look that up in the Apple docs.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Loop between observers with KVO from UIScrollView
On Jun 21, 2011, at 07:16, talesp wrote:
> 1.: should I just check if the object is different from self? Or some more
> "complicated"? And what should I check as keyPath?
In general, different classes can use the same property names, and keyPath
refers to a property name. So, you need to be certain you're recognizing the
*right* keyPath.
If you've already checked the context parameter (to eliminate observations that
you didn't set up), then you might do one of these things:
a. If you're *certain* this observer is not observing the same keyPath for
objects of a different class, then you don't need to check the object. The
danger here is if you go back and add more observations later, you might cause
yourself some annoying bugs.
b. Or, you can just check the class of the object ('isKindOfClass:'), if you
don't care which object it is.
c. Or, you can check that the object is the one you are observing (==), if
that's easier or if you need to do different things for each observed object.
> 2.: if I send a context parameter from observer (the context can be a
> NSString for example, right?), should I chech if the string is expected? And
> I only should call super if the context is invalid? Reading Apple
> documentation I saw that I should ever call super, but when I did it, the app
> crashed (I did not went look what was wrong. Should I or it's not really
> necessary?)
Yes, a string is fine, and you should only call super if you do not recognize
the string. (If everyone played by the rules, it wouldn't matter if you called
super every time, but you can assume there's plenty of code out there that
doesn't check the context properly, perhaps even in the Cocoa frameworks.)
Just to clarify: Every KVO notification arriving at
'observeValue:forKeyPath:...' is the result of *one*
'addObserver:forKeyPath:...', and should be processed only once. If it's your
notification, process it and return. If it's not, call super to give someone
else a chance to process it.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Understanding layer-backed views
I'm getting confused and frustrated by Core Animation layers (again). Mac OS. If I simply add a NSView to a window in IB, not subclassed, but turn on Core Animation layer for that view and set a background colour, shouldn't it appear with that colour in the window? That's my expectation, but that's not what I get. Instead, I see nothing. I can log the fact that the layer exists, and it has apparently the right dimensions and so on, but nothing is actually displayed. Where are my assumptions faulty? Further to this, when I add sublayers to this backing layer (or a root layer I create, as an alternative), I give them a frame property based on the view's bounds. They do display, but in the wrong place, not aligned with the view, but with the window. Again this is not in line with my expectations, which is that the frame of a sublayer is expressed in the coordinate system of its superlayer, not the underlying window. I've been beating my head against this for a few hours now, and it's just not making sense. --Graham' ___ 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
Help Book question
This should be an easy question for someone to answer. I've got a sample application demonstrating the problem at: http://ericgorr.net/cocoadev/helpbooktest.zip After launching the application, bring up the help book from the help menu. The first about link is anchor based and should link to the about page, but clicking it causes a dialog to appear which states that the help application cannot display the content. The second about link is simply a path to the about page and does work. I would like to understand why the anchor based link isn't working. I'm sure I'm doing something obviously wrong, but I am not sure what that is. Thank you. ___ 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: Understanding layer-backed views
On Jun 21, 2011, at 9:57 PM, Graham Cox wrote: > I'm getting confused and frustrated by Core Animation layers (again). Mac OS. > > > If I simply add a NSView to a window in IB, not subclassed, but turn on Core > Animation layer for that view and set a background colour, shouldn't it > appear with that colour in the window? That's my expectation, but that's not > what I get. Instead, I see nothing. I can log the fact that the layer exists, > and it has apparently the right dimensions and so on, but nothing is actually > displayed. Setting a background color to the layer? The order of creation of the layer is the entire dependency here. This is discussed in the animation overview. There are to types of layer/view interactivity Layer-backed - the view uses the layer as a cache of sorts. You should leave the layers alone. Period. You just call setWantsLayer: and the view makes a layer. If you replace it, it still isn’t your’s to touch. (and you probably shouldn’t) Layer-hosted - the view hosts a layer-tree that you create. The difference is that you create a layer, do setLayer: on the view, and then turn on setWantsLayer:. If you don’t do it in that order, you should not touch the layers. it’s entirely the order of setLayer: setWantsLayer: that controls whether you should touch the layers. If you do it this order, you can, if you do setWantsLayer: first, hands off. > > Where are my assumptions faulty? > > Depends on the above. After knowing that, we can move forward. ___ 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: Understanding layer-backed views
On 22/06/2011, at 2:21 PM, Scott Anguish wrote: >> I'm getting confused and frustrated by Core Animation layers (again). Mac OS. >> >> >> If I simply add a NSView to a window in IB, not subclassed, but turn on Core >> Animation layer for that view and set a background colour, shouldn't it >> appear with that colour in the window? That's my expectation, but that's not >> what I get. Instead, I see nothing. I can log the fact that the layer >> exists, and it has apparently the right dimensions and so on, but nothing is >> actually displayed. > > Setting a background color to the layer? > > The order of creation of the layer is the entire dependency here. This is > discussed in the animation overview. > > There are to types of layer/view interactivity > > Layer-backed - the view uses the layer as a cache of sorts. You should leave > the layers alone. Period. You just call setWantsLayer: and the view makes a > layer. If you replace it, it still isn’t your’s to touch. (and you probably > shouldn’t) > > Layer-hosted - the view hosts a layer-tree that you create. The difference is > that you create a layer, do setLayer: on the view, and then turn on > setWantsLayer:. If you don’t do it in that order, you should not touch the > layers. > > it’s entirely the order of setLayer: setWantsLayer: that controls whether you > should touch the layers. If you do it this order, you can, if you do > setWantsLayer: first, hands off. Yep, I'm aware of the setWantsLayer/setLayer order making a difference. In my case I want a layer-hosting view, not a layer-backed view. However, my question isn't really about that, but about what is done when you check the box next to the layer in Interface Builder, in the 'setWantsLayer' panel. Does this provide layer backing or layer hosting? My thoughts were that is provides layer hosting, but I'm not 100% sure. Proceeding on the basis that this is the case, it seems to work. The next thing was having checked this box, should I see anything? I was thinking that setting a colour under the appearance section should set the background colour. It looks as if in fact that sets the SHADOW colour, though it's not that clear from the layout of the controls in IB, and the fact that it's not disabled when shadow is unchecked. So I just got a bit confused and sidetracked by that. If I set the layer's background colour in code, it shows up. Seems odd that IB provides controls to set some not very interesting layer properties (shadow) and nothing for stuff you use all the time (background, border, corner radius). > Again this is not in line with my expectations, which is that the frame of a > sublayer is expressed in the coordinate system of its superlayer, not the > underlying window. I found the cause of this issue, which was that in my layer delegate, I was not saving, setting and restoring the context passed to drawLayer:inContext:. I was assuming that the context was set, but having found a code snippet in the docs that indicated it wasn't, I added these calls and my graphics are drawing in the right place now. --Graham ___ 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
