Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 27 May 2015, at 11:00, Jonathan Taylor wrote: >> Of course, it’s only a runtime check, but it’s better than nothing. Sure >> would be fine if the Static Analyzer could be made to understand KVO and >> threading and complain about such uses. > > I have a suspicion that if you can get the static analyzer to understand that > then you have probably solved a number of officially Hard problems along the > way! Was thinking more of making it mark certain calls it knows aren’t thread-safe as such, and marking every method that is passed to detachNewThreadSelector: or the likes as “threaded”, and then warning if the former is used inside or in a call hanging off the latter. That sounds like it would lie well within the abilities of the static analyzer. But I’m not saying I know that would work. I’m really just saying it “Sure would be fine” :-) Sounds like a heuristic that might work if it doesn’t give too many false positives and is kept conservative, though. Doesn’t have to catch all cases, as long as it catches a few and avoids false positives. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> The closest I got was creating a macro that uses np_thread_main() (or > whatever it was called exactly, it’s part of the pthreads API, IIRC) and > throws if it’s not the main thread. I call that e.g. in > observeValueForKeyPath overrides whenever I make thread-unsafe calls, so I > don’t accidentally make a threaded call. Ah, that's a good idea. I had wanted to do something like that but had been put off by the very large number of possible entry points. observeValueForKeyPath is a great idea that is sure to fire if any GUI-bound properties change. > Of course, it’s only a runtime check, but it’s better than nothing. Sure > would be fine if the Static Analyzer could be made to understand KVO and > threading and complain about such uses. I have a suspicion that if you can get the static analyzer to understand that then you have probably solved a number of officially Hard problems along the way! ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 23 May 2015, at 10:42, Jonathan Taylor wrote: > If only there was a way of annotating properties as > only-to-be-used-from-the-main-thread. I've asked something to that effect > previously, though, and nobody had any suggestions. I feel there must be a > way of designing-in the safety that I need, but I haven't worked out what it > might be. The closest I got was creating a macro that uses np_thread_main() (or whatever it was called exactly, it’s part of the pthreads API, IIRC) and throws if it’s not the main thread. I call that e.g. in observeValueForKeyPath overrides whenever I make thread-unsafe calls, so I don’t accidentally make a threaded call. You could probably write a macro roughly equivalent to @synthesize that implements this additional behaviour. Of course, it’s only a runtime check, but it’s better than nothing. Sure would be fine if the Static Analyzer could be made to understand KVO and threading and complain about such uses. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> On 2015 May 23, at 07:10, Marek Hrušovský wrote:
>
> Haven't read all the thread but i would use a custom property with overridden
> setter to call setNeedsDisplay with combination of
> keyPathsForValuesAffectingValueForKey: I think you can get rid of the glue
> code.
Yes, but you don’t need an overridden setter. Amy Worral explains it here:
http://stackoverflow.com/questions/6354368/how-to-observe-change-in-nsobject-properties
My interpretation is to declare a phantom property such as
@property NSInteger lookMaStuffChanged ;
then,
+ (NSSet*)keyPathsForValuesAffectingValueForLookMaStuffChanged {
return [NSSet alloc] initWithObjects:
@“whatever1”,
@“whatever2”,
…
nil] ;
}
Finally, observe lookMaStuffChanged with KVO.
In fact, the phantom property lookMaStuffChanged is never affected by anything;
it’s never even set to anything.
Works for me.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
Haven't read all the thread but i would use a custom property with overridden setter to call setNeedsDisplay with combination of keyPathsForValuesAffectingValueForKey: I think you can get rid of the glue code. On Sat, May 23, 2015 at 3:42 PM, Jonathan Taylor < jonathan.tay...@glasgow.ac.uk> wrote: > On 23 May 2015, at 00:21, Graham Cox wrote: > > My advice is: forget it. What you’re doing is fine, and it’s the normal > way to make views repaint when a property changes. It’s not code ‘bloat’ > either - @synthesize produces code just as if you’d written it yourself. > Any other way than simply adding a call to -setNeedsDisplay: is MORE code > than that. > > Just to be clear, I meant source code bloat - in the process of > refactoring the code I have been rather horrified at how much of my > codebase is really just "glue" code for user interface stuff, in what > should be just a GUI wrapper on some scientific code. > > > What would be quite nice (though maybe too much of a special case and > very unlikely to happen) is a qualifier for properties that would add the > -setNeedsDisplay: automatically as part of the @synthesize, but I doubt > that will ever happen because it a) only pertains to views b) might not be > optimal for some situations, where only part of the view needs updating, > and c) made somewhat redundant by layers, which have a flag that causes a > redisplay on a property change. > > Ah, now it sounds like layers could be something I should be reading up on > then! Maybe another one of those cases of me asking the wrong question > because I don't know what the right one is... > > > All of you wrote: > > Since you're talking about properties on an NSView subclass, and NSView > is documented as being not thread-safe, the atomicity thing sounds like a > big red herring (or red flag, depending on your preference for fish or > cloth). > > [rambling off the original topic...] > > You are quite right of course. If I am concerned about atomicity on this > particular object then I am definitely doing something wrong. There was > probably some end-of-week thinking behind what I did, but the rough train > of thought went: > > - There is necessarily a fair bit of multithreading in my codebase, and I > have not found a completely foolproof way of guaranteeing it remains > isolated from GUI code (though I know I must do that). I want to use > [non-gui-related] properties on other threads, but then sooner or later I > end up accidentally causing an interaction with GUI-bound properties and > causing an obscure and hard-to-debug crash > > - A recent such crash involved a double-free of an NSNumber (where to > begin looking...!?), and brainstorming this lead me to imagine that > accessing a nonatomic property returning an objc object could lead to that > happening. > > - As a result I decided I had no good reason to have any nonatomic > properties, and that I would try and remove any use of nonatomic rather > than try and decide on a case-by-case basis > > - This led to warnings about custom setters paired with auto-synthesized > getters, which got me looking at this setNeedsDisplay code and wondering if > there was a better way of doing that anyway. > > Probably an overreaction (and very probably not the actual cause of the > crash), but I was pretty sure that technically speaking my universal use of > nonatomic [for reasons lost in the mists of time] was not correct. > > If only there was a way of annotating properties as > only-to-be-used-from-the-main-thread. I've asked something to that effect > previously, though, and nobody had any suggestions. I feel there must be a > way of designing-in the safety that I need, but I haven't worked out what > it might be. > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/xhruso00%40gmail.com > > This email sent to xhrus...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 23 May 2015, at 00:21, Graham Cox wrote: > My advice is: forget it. What you’re doing is fine, and it’s the normal way > to make views repaint when a property changes. It’s not code ‘bloat’ either - > @synthesize produces code just as if you’d written it yourself. Any other way > than simply adding a call to -setNeedsDisplay: is MORE code than that. Just to be clear, I meant source code bloat - in the process of refactoring the code I have been rather horrified at how much of my codebase is really just "glue" code for user interface stuff, in what should be just a GUI wrapper on some scientific code. > What would be quite nice (though maybe too much of a special case and very > unlikely to happen) is a qualifier for properties that would add the > -setNeedsDisplay: automatically as part of the @synthesize, but I doubt that > will ever happen because it a) only pertains to views b) might not be optimal > for some situations, where only part of the view needs updating, and c) made > somewhat redundant by layers, which have a flag that causes a redisplay on a > property change. Ah, now it sounds like layers could be something I should be reading up on then! Maybe another one of those cases of me asking the wrong question because I don't know what the right one is... All of you wrote: > Since you're talking about properties on an NSView subclass, and NSView is > documented as being not thread-safe, the atomicity thing sounds like a big > red herring (or red flag, depending on your preference for fish or cloth). [rambling off the original topic...] You are quite right of course. If I am concerned about atomicity on this particular object then I am definitely doing something wrong. There was probably some end-of-week thinking behind what I did, but the rough train of thought went: - There is necessarily a fair bit of multithreading in my codebase, and I have not found a completely foolproof way of guaranteeing it remains isolated from GUI code (though I know I must do that). I want to use [non-gui-related] properties on other threads, but then sooner or later I end up accidentally causing an interaction with GUI-bound properties and causing an obscure and hard-to-debug crash - A recent such crash involved a double-free of an NSNumber (where to begin looking...!?), and brainstorming this lead me to imagine that accessing a nonatomic property returning an objc object could lead to that happening. - As a result I decided I had no good reason to have any nonatomic properties, and that I would try and remove any use of nonatomic rather than try and decide on a case-by-case basis - This led to warnings about custom setters paired with auto-synthesized getters, which got me looking at this setNeedsDisplay code and wondering if there was a better way of doing that anyway. Probably an overreaction (and very probably not the actual cause of the crash), but I was pretty sure that technically speaking my universal use of nonatomic [for reasons lost in the mists of time] was not correct. If only there was a way of annotating properties as only-to-be-used-from-the-main-thread. I've asked something to that effect previously, though, and nobody had any suggestions. I feel there must be a way of designing-in the safety that I need, but I haven't worked out what it might be. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> On 22 May 2015, at 9:51 pm, Jonathan Taylor > wrote: > > I’m trying to think if there is an elegant way of handling the situation I > find in some of my display code. I have a class which inherits from NSView > and which overrides drawRect. The class has a number of properties, and if > they change then the view needs redrawing. At present I have custom setters > that call through to setNeedsDisplay:YES. This results in quite a lot of code > bloat (since I would otherwise just @synthesize the properties and be done > with it). My advice is: forget it. What you’re doing is fine, and it’s the normal way to make views repaint when a property changes. It’s not code ‘bloat’ either - @synthesize produces code just as if you’d written it yourself. Any other way than simply adding a call to -setNeedsDisplay: is MORE code than that. View properties can’t be usefully atomic either, so that isn’t going to matter. Really, you are trying to save yourself a tiny bit of extra work by making things far more complicated than necessary. Remember, it wasn’t very long ago that all properties had to be implemented by hand. How we used to spend many a happy hour writing endless getters and setters! What would be quite nice (though maybe too much of a special case and very unlikely to happen) is a qualifier for properties that would add the -setNeedsDisplay: automatically as part of the @synthesize, but I doubt that will ever happen because it a) only pertains to views b) might not be optimal for some situations, where only part of the view needs updating, and c) made somewhat redundant by layers, which have a flag that causes a redisplay on a property change. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> On 22 May 2015, at 15:03, Jonathan Taylor > wrote: > > Thanks for your reply Mike: > >> Well you could have a single key which you observe internally, and which all >> the other keys feed into. Whenever it “changes”, treat that as time to mark >> as needing display. That way you’re asking AppKit to do the work of creating >> all the other observations for you. > > I think this is what I was describing here, isn’t it (or am I > misunderstanding you?): >>> I could create a single “dummy” property of my own, say that changes to all >>> these other properties affect that key, and then monitor that single key >>> using KVO (and call setNeedsDisplay whenever it gets “tickled” by some >>> other property change). That would do what I want, but feels a little bit >>> hacky. Yeah, same thing I think. Was just talking it through more for my own benefit really :-) > > >> It all seems rather wasteful though. You’ve added a couple of layers of >> indirection into the system to save a handful of lines of code. Is it really >> that big a deal to write some custom setters? They’re only four lines long >> each. > > I agree that it’s extra indirection, but since performance is never going to > be an issue, I feel it’s a slight gain on tidiness and maintainability. I > agree that it’s not a big deal for one property, but when there are lots it > starts to add up. And it’s not just the setters - what finally spurred me > into action was the decision that I wanted all my properties to be atomic > (which may or may not be related to an occasional crash I have been seeing). > That means writing a correct threadsafe getter for each one as well… That’s a good point about how atomic accessors make the story a lot more complicated. BUT, why would atomic accessors help your crash? Views are pretty fundamentally tied to the main thread for the most part. Atomic accessors won’t help there. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 22 May 2015, at 6:03 am, Jonathan Taylor
wrote:
> I agree that it’s extra indirection, but since performance is never going to
> be an issue, I feel it’s a slight gain on tidiness and maintainability. I
> agree that it’s not a big deal for one property, but when there are lots it
> starts to add up.
How about cooking up a macro for defining the accessors?
#define DECLARE_PROPERTY(PROPERTY,TYPE) \
@property (nonatomic, copy) TYPE PROPERTY;
#define DEFINE_PROPERTY(PROPERTY,TYPE) \
- (TYPE)PROPERTY \
{ \
return _##PROPERTY; \
} \
\
- (void)set##PROPERTY:(TYPE)x \
{ \
_##PROPERTY = x; \
[self setNeedsDisplay]; \
} \
...
@interface Foo
DECLARE_PROPERTY(widgetName, NSString *);
@end
...
@implmenetation Foo
DEFINE_PROPERTY(widgetName, NSString *);
@end
> And it’s not just the setters - what finally spurred me into action was the
> decision that I wanted all my properties to be atomic (which may or may not
> be related to an occasional crash I have been seeing). That means writing a
> correct threadsafe getter for each one as well...
Since you're talking about properties on an NSView subclass, and NSView is
documented as being not thread-safe, the atomicity thing sounds like a big red
herring (or red flag, depending on your preference for fish or cloth).
b
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
Thanks for your reply Mike: > Well you could have a single key which you observe internally, and which all > the other keys feed into. Whenever it “changes”, treat that as time to mark > as needing display. That way you’re asking AppKit to do the work of creating > all the other observations for you. I think this is what I was describing here, isn’t it (or am I misunderstanding you?): >> I could create a single “dummy” property of my own, say that changes to all >> these other properties affect that key, and then monitor that single key >> using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other >> property change). That would do what I want, but feels a little bit hacky. > It all seems rather wasteful though. You’ve added a couple of layers of > indirection into the system to save a handful of lines of code. Is it really > that big a deal to write some custom setters? They’re only four lines long > each. I agree that it’s extra indirection, but since performance is never going to be an issue, I feel it’s a slight gain on tidiness and maintainability. I agree that it’s not a big deal for one property, but when there are lots it starts to add up. And it’s not just the setters - what finally spurred me into action was the decision that I wanted all my properties to be atomic (which may or may not be related to an occasional crash I have been seeing). That means writing a correct threadsafe getter for each one as well... ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> On 22 May 2015, at 13:51, Jonathan Taylor > wrote: > > I’m trying to think if there is an elegant way of handling the situation I > find in some of my display code. I have a class which inherits from NSView > and which overrides drawRect. The class has a number of properties, and if > they change then the view needs redrawing. At present I have custom setters > that call through to setNeedsDisplay:YES. This results in quite a lot of code > bloat (since I would otherwise just @synthesize the properties and be done > with it). > > I could set an observer on each property, but that would be a bit tedious > (especially since, as I understand it, I have to remove EACH of the observers > individually as well on dealloc). > > I am trying to think if there is a way I can leverage > keyPathsForValuesAffectingValueForKey to make things a bit simpler. I’m quite > a fan of using that where I can. It would be great if I could say that all my > properties affect some particular property of NSView that would trigger a > redraw. I can’t think of one that would do the trick, though. [If you think > about it, the property needsDisplay is NOT the one I want to say is affected > by my keys…] > > I could create a single “dummy” property of my own, say that changes to all > these other properties affect that key, and then monitor that single key > using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other > property change). That would do what I want, but feels a little bit hacky. > > Does anybody have any thoughts about what I might do? I feel this is probably > a relatively common problem that people must have a way of dealing with… Well you could have a single key which you observe internally, and which all the other keys feed into. Whenever it “changes”, treat that as time to mark as needing display. That way you’re asking AppKit to do the work of creating all the other observations for you. It all seems rather wasteful though. You’ve added a couple of layers of indirection into the system to save a handful of lines of code. Is it really that big a deal to write some custom setters? They’re only four lines long each. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Custom NSView subclass - expressing the fact that a property affects the displayed image
I’m trying to think if there is an elegant way of handling the situation I find in some of my display code. I have a class which inherits from NSView and which overrides drawRect. The class has a number of properties, and if they change then the view needs redrawing. At present I have custom setters that call through to setNeedsDisplay:YES. This results in quite a lot of code bloat (since I would otherwise just @synthesize the properties and be done with it). I could set an observer on each property, but that would be a bit tedious (especially since, as I understand it, I have to remove EACH of the observers individually as well on dealloc). I am trying to think if there is a way I can leverage keyPathsForValuesAffectingValueForKey to make things a bit simpler. I’m quite a fan of using that where I can. It would be great if I could say that all my properties affect some particular property of NSView that would trigger a redraw. I can’t think of one that would do the trick, though. [If you think about it, the property needsDisplay is NOT the one I want to say is affected by my keys…] I could create a single “dummy” property of my own, say that changes to all these other properties affect that key, and then monitor that single key using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other property change). That would do what I want, but feels a little bit hacky. Does anybody have any thoughts about what I might do? I feel this is probably a relatively common problem that people must have a way of dealing with… Cheers Jonny ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView subclass does not seem to start
Hello all, I replied last night, but my message got held up because it was too large. If it makes it through, please disregard it. The problem was that my NSWindow was not a property of my class, but rather a method-level variable. It works now. Thanks for all the help! On Dec 31, 2013, at 12:45 AM, Andy Lee wrote: > On Dec 30, 2013, at 5:34 PM, Alex Hall wrote: >> Anyway, the problem remains that I need to capture keystrokes (and >> eventually mouse movements) in a subclass of NSView, but nothing seems to >> happen. Since this is an audio game, there is no need for any UI controls to >> be drawn - I need only the keyboard/mouse event handler. Therefore, my view >> has no UI controls, it is merely a rectangle, or should be, with an origin >> of (0,0). Below, and I apologize in advance for how long this will be, I >> have laid out the path taken to get the view on the screen. Where I feel it >> is necessary, I have given source code. Note that I still have the main XIB >> file Xcode generated. Perhaps I should remove it, I don't know yet. > > I would advise against removing it. Even if you choose to create everything > else in code, your app should have a main menu so that it can provide > standard menu items like "About" and "Quit". Also, MainMenu.xib connects > your app delegate to the application object. I can think of no good reason > to remove it, even if you never use nibs elsewhere. > >> 1. My app runs, and the AppDelegate's applicationDidFinishLaunching method >> is called automatically. In here I create an AITGameController object,, >> which does the lion's share of the work. I then call this object's initGame >> and startLoop methods, the first to set up the game and the second to begin >> the game loop that will drive the app. > > I'm a little concerned about this game loop. Cocoa already provides > something called a run loop that is entered after your application launches > and initializes. You *generally* don't create a loop of your own to process > events. Rather, as you have done, you override methods like mouseDown:, > keyDown:, and keyUp:. Those messages will be sent to the appropriate object > as they occur -- be it the first responder or something else. So I wonder > if, because you are entering your own loop, you are never entering the run > loop, which would explain why events never get logged. > >> 2. The AITGameController's init method sets up the AITViewController, whose >> source is below. It then sets up the AITAudioMenu (my NSView subclass, >> which is supposed to be logging keystrokes). Now we get into the fun part, >> so here's the code I am using: >> >> //from AITGameController > init >> >> [self setViewManager:[[AITViewController alloc] init]]; >> NSRect windowSize=NSMakeRect(0.0, 0.0, 200.0, 150.0); >> NSWindow* mainWindow=[viewManager makeWindowWithRect:&windowSize >> style:NSTitledWindowMask|NSMiniaturizableWindowMask]; > > I notice makeWindowWithRect:style: takes an NSRect as its first argument, so > you should be passing windowSize and not &windowSize. Unless this is a typo > in your email, I would have expected a compiler error. > >> I hope all this makes some sense. I think what is tripping me up is trying >> to manage windows like this while IB is still being used, but I really don't >> know. Thanks for any help, and if anyone from Apple is on here: anytime you >> guys can make IB fully accessible, I and other budding developers would very >> much appreciate it. Yes, bug reports have been filed. :) > > I think it is not only okay to keep the main nib in the project, but as I > said I would advise against removing it. However, something else occurred to > me that might be coming from MainMenu.xib. The standard main nib provided by > Xcode has a window in it, which is pointed to by a property of the app > delegate. I wonder if that window is made the key window *after* your window > is, and is therefore stealing your keyboard events. I wouldn't *think* so, > but just to remove the possibility I would get rid of that window altogether. > In your case the simplest way to do that is to set the app delegate's window > property to nil. That is, in applicationDidFinishLaunching: you could add as > the first line: > > self.window = nil; > > One more suggestion. After the program has launched, you might want to see > if everything is what you think it is. Maybe you could add an action method > in the app delegate that prints out (using NSLog) the current key window, and > its first responder. Then co
Re: NSView subclass does not seem to start
On Dec 31, 2013, at 9:13 AM, Alex Hall wrote: > Sorry, I should have specified - I'm so used to seeing it I didn't even > think. The loop is based on an NSTimer and is used to process sound position > updates. Basically, I use it to pan sounds and draw updates. I'm not putting > key management in there. Here's the setup for it: >> [self setGameTimer:[NSTimer scheduledTimerWithTimeInterval:1.0/30 >> target:self selector:@selector(gameLoop:) userInfo:nil repeats:YES]]; > The docs indicate that this automatically adds itself to the app's mainLoop, > so I should be okay here, unless I've misunderstood something (a distinct > possibility). Ah, okay. I wouldn't expect that to be the cause of the problem then. > I have no idea how that got in there. :) In the code I'm working with, there > is no &. It must have been left over from when I had it in my head that > NSRect needed to be passed by reference and was using asterisks all over the > place. I'm not doing that anymore, don't worry. Got it. >> One more suggestion. After the program has launched, you might want to see >> if everything is what you think it is. Maybe you could add an action method >> in the app delegate that prints out (using NSLog) the current key window, >> and its first responder. Then connect a menu item to that method. Launch >> the program and try to invoke the menu item. If your problem is the "loop" >> thing I wondered about earlier, you won't be able to invoke the menu item. >> If not, you should get either a sanity check that you have set up the window >> and view correctly, or a possible indication of where the bug is. > > I'll have to re-visit Charles' sample code to be sure I can do this one right > as I've never done this before. Perhaps a button would work just as well? It > seems less prone to errors from me while setting up. It is a great idea > though, and will let me be sure my view is getting drawn in the first place. > Thanks for your response. Oh sure, a button would work as well. Yeah, in fact I do things like that with buttons all the time. You could also break in the debugger and print the information with debugger commands, but often I find a button is handy for this kind of sanity checking. --Andy ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView subclass does not seem to start
On Dec 31, 2013, at 12:45 AM, Andy Lee wrote: > On Dec 30, 2013, at 5:34 PM, Alex Hall wrote: >> Anyway, the problem remains that I need to capture keystrokes (and >> eventually mouse movements) in a subclass of NSView, but nothing seems to >> happen. Since this is an audio game, there is no need for any UI controls to >> be drawn - I need only the keyboard/mouse event handler. Therefore, my view >> has no UI controls, it is merely a rectangle, or should be, with an origin >> of (0,0). Below, and I apologize in advance for how long this will be, I >> have laid out the path taken to get the view on the screen. Where I feel it >> is necessary, I have given source code. Note that I still have the main XIB >> file Xcode generated. Perhaps I should remove it, I don't know yet. > > I would advise against removing it. Even if you choose to create everything > else in code, your app should have a main menu so that it can provide > standard menu items like "About" and "Quit". Also, MainMenu.xib connects > your app delegate to the application object. I can think of no good reason > to remove it, even if you never use nibs elsewhere. Okay, it will remain then. I just was not sure if something might have been conflicting. > >> 1. My app runs, and the AppDelegate's applicationDidFinishLaunching method >> is called automatically. In here I create an AITGameController object,, >> which does the lion's share of the work. I then call this object's initGame >> and startLoop methods, the first to set up the game and the second to begin >> the game loop that will drive the app. > > I'm a little concerned about this game loop. Cocoa already provides > something called a run loop that is entered after your application launches > and initializes. You *generally* don't create a loop of your own to process > events. Rather, as you have done, you override methods like mouseDown:, > keyDown:, and keyUp:. Those messages will be sent to the appropriate object > as they occur -- be it the first responder or something else. So I wonder > if, because you are entering your own loop, you are never entering the run > loop, which would explain why events never get logged. Sorry, I should have specified - I'm so used to seeing it I didn't even think. The loop is based on an NSTimer and is used to process sound position updates. Basically, I use it to pan sounds and draw updates. I'm not putting key management in there. Here's the setup for it: > [self setGameTimer:[NSTimer scheduledTimerWithTimeInterval:1.0/30 > target:self selector:@selector(gameLoop:) userInfo:nil repeats:YES]]; The docs indicate that this automatically adds itself to the app's mainLoop, so I should be okay here, unless I've misunderstood something (a distinct possibility). >> 2. The AITGameController's init method sets up the AITViewController, whose >> source is below. It then sets up the AITAudioMenu (my NSView subclass, >> which is supposed to be logging keystrokes). Now we get into the fun part, >> so here's the code I am using: >> >> //from AITGameController > init >> >> [self setViewManager:[[AITViewController alloc] init]]; >> NSRect windowSize=NSMakeRect(0.0, 0.0, 200.0, 150.0); >> NSWindow* mainWindow=[viewManager makeWindowWithRect:&windowSize >> style:NSTitledWindowMask|NSMiniaturizableWindowMask]; > > I notice makeWindowWithRect:style: takes an NSRect as its first argument, so > you should be passing windowSize and not &windowSize. Unless this is a typo > in your email, I would have expected a compiler error. I have no idea how that got in there. :) In the code I'm working with, there is no &. It must have been left over from when I had it in my head that NSRect needed to be passed by reference and was using asterisks all over the place. I'm not doing that anymore, don't worry. > >> I hope all this makes some sense. I think what is tripping me up is trying >> to manage windows like this while IB is still being used, but I really don't >> know. Thanks for any help, and if anyone from Apple is on here: anytime you >> guys can make IB fully accessible, I and other budding developers would very >> much appreciate it. Yes, bug reports have been filed. :) > > I think it is not only okay to keep the main nib in the project, but as I > said I would advise against removing it. However, something else occurred to > me that might be coming from MainMenu.xib. The standard main nib provided by > Xcode has a window in it, which is pointed to by a property of the app > delegate. I wonder if
Re: NSView subclass does not seem to start
On Dec 30, 2013, at 5:34 PM, Alex Hall wrote: > Anyway, the problem remains that I need to capture keystrokes (and eventually > mouse movements) in a subclass of NSView, but nothing seems to happen. Since > this is an audio game, there is no need for any UI controls to be drawn - I > need only the keyboard/mouse event handler. Therefore, my view has no UI > controls, it is merely a rectangle, or should be, with an origin of (0,0). > Below, and I apologize in advance for how long this will be, I have laid out > the path taken to get the view on the screen. Where I feel it is necessary, I > have given source code. Note that I still have the main XIB file Xcode > generated. Perhaps I should remove it, I don't know yet. I would advise against removing it. Even if you choose to create everything else in code, your app should have a main menu so that it can provide standard menu items like "About" and "Quit". Also, MainMenu.xib connects your app delegate to the application object. I can think of no good reason to remove it, even if you never use nibs elsewhere. > 1. My app runs, and the AppDelegate's applicationDidFinishLaunching method is > called automatically. In here I create an AITGameController object,, which > does the lion's share of the work. I then call this object's initGame and > startLoop methods, the first to set up the game and the second to begin the > game loop that will drive the app. I'm a little concerned about this game loop. Cocoa already provides something called a run loop that is entered after your application launches and initializes. You *generally* don't create a loop of your own to process events. Rather, as you have done, you override methods like mouseDown:, keyDown:, and keyUp:. Those messages will be sent to the appropriate object as they occur -- be it the first responder or something else. So I wonder if, because you are entering your own loop, you are never entering the run loop, which would explain why events never get logged. > 2. The AITGameController's init method sets up the AITViewController, whose > source is below. It then sets up the AITAudioMenu (my NSView subclass, which > is supposed to be logging keystrokes). Now we get into the fun part, so > here's the code I am using: > > //from AITGameController > init > > [self setViewManager:[[AITViewController alloc] init]]; > NSRect windowSize=NSMakeRect(0.0, 0.0, 200.0, 150.0); > NSWindow* mainWindow=[viewManager makeWindowWithRect:&windowSize > style:NSTitledWindowMask|NSMiniaturizableWindowMask]; I notice makeWindowWithRect:style: takes an NSRect as its first argument, so you should be passing windowSize and not &windowSize. Unless this is a typo in your email, I would have expected a compiler error. > I hope all this makes some sense. I think what is tripping me up is trying to > manage windows like this while IB is still being used, but I really don't > know. Thanks for any help, and if anyone from Apple is on here: anytime you > guys can make IB fully accessible, I and other budding developers would very > much appreciate it. Yes, bug reports have been filed. :) I think it is not only okay to keep the main nib in the project, but as I said I would advise against removing it. However, something else occurred to me that might be coming from MainMenu.xib. The standard main nib provided by Xcode has a window in it, which is pointed to by a property of the app delegate. I wonder if that window is made the key window *after* your window is, and is therefore stealing your keyboard events. I wouldn't *think* so, but just to remove the possibility I would get rid of that window altogether. In your case the simplest way to do that is to set the app delegate's window property to nil. That is, in applicationDidFinishLaunching: you could add as the first line: self.window = nil; One more suggestion. After the program has launched, you might want to see if everything is what you think it is. Maybe you could add an action method in the app delegate that prints out (using NSLog) the current key window, and its first responder. Then connect a menu item to that method. Launch the program and try to invoke the menu item. If your problem is the "loop" thing I wondered about earlier, you won't be able to invoke the menu item. If not, you should get either a sanity check that you have set up the window and view correctly, or a possible indication of where the bug is. --Andy ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSView subclass does not seem to start
On Dec 30, 2013, at 6:05 PM, Ken Thomases wrote:
> Hi,
>
> On Dec 30, 2013, at 4:34 PM, Alex Hall wrote:
>
>> Anyway, the problem remains that I need to capture keystrokes (and
>> eventually mouse movements) in a subclass of NSView, but nothing seems to
>> happen.
>
> In order for a view to receive key events, it must be the first responder.
> Typically, you need to override -acceptsFirstResponder to return YES to allow
> a view to become the first responder. (There are other approaches, but
> that's the normal one.)
I have done so. In AITAudioMenu (my subclass of NSView) I now have this method:
-(bool) acceptsFirstResponder{
return YES;
}
I assume, and the docs seem to indicate, that I never explicitly call this? It
seems like something Cocoa does on its own, really a property setter more than
anything.
>
> After that, you either want to set the window's initialFirstResponder to be
> that view before the window is shown or you want to call -[NSWindow
> makeFirstResponder:] to set the first responder at a later time.
I've done the latter, since the mainWindow will remain as I switch out views
and set different ones to handle the keyboard and mouse at different times.
ViewController now has a method that takes the view and window and sets the
view as the first responder.
However, I still am getting no logs of keypresses. Is it possible that my use
of mainWindow or some other variable or method name/signature is causing a
conflict?
>
> Cheers,
> Ken
>
Have a great day,
Alex (msg sent from Mac Mini)
mehg...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSView subclass does not seem to start
Hi, On Dec 30, 2013, at 4:34 PM, Alex Hall wrote: > Anyway, the problem remains that I need to capture keystrokes (and eventually > mouse movements) in a subclass of NSView, but nothing seems to happen. In order for a view to receive key events, it must be the first responder. Typically, you need to override -acceptsFirstResponder to return YES to allow a view to become the first responder. (There are other approaches, but that's the normal one.) After that, you either want to set the window's initialFirstResponder to be that view before the window is shown or you want to call -[NSWindow makeFirstResponder:] to set the first responder at a later time. Cheers, 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSView subclass does not seem to start
Hello list,
A few days ago I said I am working on an audio game, when I asked about code
organization. I have taken the advice I was given and am simply trying to get
things to work, keeping the major portions separated as much as I can but
mostly just wanting the project to do what I want. For the moment, what I want
is to log keystrokes, so I can then implement a keystroke listener on the
different views I will have. However, the single view I am trying to use logs
nothing, but neither do I get any errors.
Before I continue I need to put out a reminder: I am *not* using Interface
Builder, because there is no way for me, a Voiceover user, to reliably tie
actions to UI elements. About a year ago I emailed this list about laying out
UIs in code, and was provided with some extremely helpful code samples which I
am trying now to use. The delay of almost a year, by the way, was partly my
wanting to get more comfortable with Objective-C before taking on this type of
project, and partly hoping that Apple would fix Xcode so I could fully use it.
They have failed to do so, but I at least feel much more confident using
Objective-c, so here I am once more.
Anyway, the problem remains that I need to capture keystrokes (and eventually
mouse movements) in a subclass of NSView, but nothing seems to happen. Since
this is an audio game, there is no need for any UI controls to be drawn - I
need only the keyboard/mouse event handler. Therefore, my view has no UI
controls, it is merely a rectangle, or should be, with an origin of (0,0).
Below, and I apologize in advance for how long this will be, I have laid out
the path taken to get the view on the screen. Where I feel it is necessary, I
have given source code. Note that I still have the main XIB file Xcode
generated. Perhaps I should remove it, I don't know yet.
1. My app runs, and the AppDelegate's applicationDidFinishLaunching method is
called automatically. In here I create an AITGameController object,, which does
the lion's share of the work. I then call this object's initGame and startLoop
methods, the first to set up the game and the second to begin the game loop
that will drive the app.
2. The AITGameController's init method sets up the AITViewController, whose
source is below. It then sets up the AITAudioMenu (my NSView subclass, which
is supposed to be logging keystrokes). Now we get into the fun part, so here's
the code I am using:
//from AITGameController > init
[self setViewManager:[[AITViewController alloc] init]];
NSRect windowSize=NSMakeRect(0.0, 0.0, 200.0, 150.0);
NSWindow* mainWindow=[viewManager makeWindowWithRect:&windowSize
style:NSTitledWindowMask|NSMiniaturizableWindowMask];
NSRect menuSize=NSMakeRect(0.0, 0.0, 100.0, 100.0);
AITAudioMenu* mainMenu=[[AITAudioMenu alloc] initWithFrame:menuSize];
[viewManager makeFrontWindow:mainWindow];
[viewManager addSubview:mainMenu toWindow:mainWindow];
I thought this would be enough, that adding the subview would cause things to
start working, but it does not seem to. Now, here's the viewController code -
whatever is wrong is probably in here somewhere.
//AITViewController.m
#import "AITViewController.h"
@implementation AITViewController
-(AITViewController*) init{
self=[super init];
if(!self) return nil;
return self;
}
-(NSWindow*) makeWindowWithRect:(NSRect) rect style:(NSUInteger) style{
NSWindow* theWindow= [[NSWindow alloc] initWithContentRect:rect
styleMask:style backing:NSBackingStoreBuffered defer:YES];
return theWindow;
}
-(void) makeFrontWindow:(NSWindow*) theWindow{
[theWindow center];
[theWindow makeKeyAndOrderFront: self];
}
-(void) addSubview:(NSView*) theView toWindow:(NSWindow*) theWindow{
NSView* cv=[theWindow contentView];
[cv addSubview:theView];
}
@end
And just in case, here's the AudioMenu class:
//AITAudioMenu.m
#import "AITAudioMenu.h"
@implementation AITAudioMenu
- (id)initWithFrame:(NSRect)frame
{
self = [super initWithFrame:frame];
if (self) {
// Initialization code here.
}
return self;
}
- (void)drawRect:(NSRect)dirtyRect
{
[super drawRect:dirtyRect];
// Drawing code here.
}
-(void) keyUp:(NSEvent*) event{
NSLog(@"Key pressed: %hu. Modifiers: %lu.", [event keyCode], [event
modifierFlags]);
[super keyUp:event];
}
@end
You will notice I have done very little to the template Xcode gave me.
Eventually I will do much more, but for now I just want that keyUp method to
work. Once it is, I'll implement the actual functionality of the audio menu,
but until I can detect keystrokes, I'd have nothing to which to bind the menu's
methods anyway.
I hope all this makes some sense. I think what is tripping me up is trying to
manage windows like this while IB is still be
NSTextFinder - don't use an NSView subclass for the client
Don't use a subclass of NSView for the object that you pass as 'client'. The NSTextFinderClient protocol's -(BOOL)isEditable method will be called from -[NSView inputContext] as your view's window is being dealloc'd, and you may crash. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: rightMouseDown: never called in NSView subclass
Thank you for this tip, I had tried doing this earlier, but I was using
-hitTest: from my NSWindow to find out if the event should be passed to my
view, which obviously didn't work because NSToolbarView was overriding
-hitTest: to return itself. I got it working by converting point to the view's
local coordinates and checking whether it was within bounds. Here's the code
snippet:
- (void)sendEvent:(NSEvent *)theEvent
{
switch (theEvent.type) {
case NSRightMouseDown: {
NSPoint point = [self.toolbarView convertPoint:[theEvent
locationInWindow] fromView:nil];
if (NSPointInRect(point, [self.toolbarView bounds])) {
[self.toolbarView rightMouseDown:theEvent];
return;
}
[super sendEvent:theEvent];
break;
} default:
[super sendEvent:theEvent];
break;
}
}
On 2011-08-26, at 1:28 PM, Lee Ann Rucker wrote:
> What if you intercept the event a bit higher, in [NSWindow sendEvent:]?
>
> The right click gets intercepted by the toolbar view because it's got its own
> menu; it's likely your users won't discover your menu because they're
> expecting that one. I have toolbar items with menus, but they're NSButtons
> that show the menu on left-click. Have you considered using an NSButton and
> setting its image to NSImageNameActionTemplate ("An action menu template
> image")? That would be discoverable and accessible.
>
> (Meant to hit reply-all)
>
> On Aug 26, 2011, at 9:36 AM, Indragie Karunaratne wrote:
>
>> Thats actually what I'm doing right now, its an NSToolbarItem with a custom
>> view but like I said, the right mouse events are not passed to it by
>> NSToolbarView without that little hack. I could, as you said, circumvent
>> NSToolbar completely, but when a view is placed outside of the toolbar, it
>> disappears when Lion goes into fullscreen mode. I don't know if this is a
>> bug or intended behaviour.
>
___
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: rightMouseDown: never called in NSView subclass
What if you intercept the event a bit higher, in [NSWindow sendEvent:]?
The right click gets intercepted by the toolbar view because it's got its own
menu; it's likely your users won't discover your menu because they're expecting
that one. I have toolbar items with menus, but they're NSButtons that show the
menu on left-click. Have you considered using an NSButton and setting its image
to NSImageNameActionTemplate ("An action menu template image")? That would be
discoverable and accessible.
(Meant to hit reply-all)
On Aug 26, 2011, at 9:36 AM, Indragie Karunaratne wrote:
> Thats actually what I'm doing right now, its an NSToolbarItem with a custom
> view but like I said, the right mouse events are not passed to it by
> NSToolbarView without that little hack. I could, as you said, circumvent
> NSToolbar completely, but when a view is placed outside of the toolbar, it
> disappears when Lion goes into fullscreen mode. I don't know if this is a bug
> or intended behaviour.
___
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: rightMouseDown: never called in NSView subclass
On Fri, Aug 26, 2011 at 10:36 AM, Kyle Sluder wrote: > replace NSClipView's implementation Of course I mean NSToolbarView. --Kyle Sluder ___ 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: rightMouseDown: never called in NSView subclass
On Fri, Aug 26, 2011 at 9:51 AM, glenn andreas wrote:
> The App Store approval guidelines is pretty clear that the use of non-public
> API is grounds for rejection. NSToolbarView is undocumented, and therefore
> doing anything that depends on that class or its (undocumented) behavior
> would seem like grounds for rejection. This would include adding a category
> to replace a method (which is fraught with peril regardless - categories
> aren't designed to replace existing methods, since you can't guarantee the
> loading order of categories from OS release to OS release - including minor
> updates), subclassing, method swizzling, or even testing to see if an object
> is one of those undocumented classes.
A better idea would be to 1) file a Radar and then 2) call
method_exchangeImplementations sometime during launch to replace
NSClipView's implementation of -hitTest: with one that does the "Right
Thing". Perhaps something like this to minimize the effects of the
override:
// Warning, typed in Mail
@implementation NSToolbarView (MyFixes)
- (NSView *)replacement_hitTest:(NSPoint *)aPoint {
NSView *foundView = [super hitTest:aPoint]; // call NSView's implementation
if ([foundView tag] == MyCustomToolbarItemViewTag)
return foundView;
else
return [self replacement_hitTest:aPoint]; // note that because of
how method_exchangeImplementations works, this will call the
_ORIGINAL_ IMP
}
+ (void)swapMethods {
unsigned int methodCount = 0;
Method *instanceMethods = class_copyMethodList(self, &methodCount);
for (int i = 0; i < methodCount; i++) {
Method *original = instanceMethods[i]
if (method_getName(original) == @selector(hitTest:)) { // make
sure to only override -[NSToolbarView hitTest:]
Method *replacement = class_getMethod(self,
@selector(replacement_hitTest:));
method_exchangeImplementations(self, original, replacement);
break;
}
}
free(instanceMethods);
}
@end
Then call +[NSToolbarView(MyFixes) swapMethods] some time early in
your app's lifecycle, like -applicationWillFinishLaunching:.
> And even if it gets accepted, there is no guarantee that when you need to
> make an emergency update to fix some critical bug that somehow slipped
> through or later arose that you'd get accepted that time.
Make sure to file the Radar first so you can point at it if someone
flags your app.
--Kyle Sluder
___
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: rightMouseDown: never called in NSView subclass
OK, I misread your first message. That said, I'd go with the option to just put your "toolbar" view as part of the contentView of the window. If your view is within the contentView of the window, it will be part of the fullscreen window in Lion. Just make sure it can resize with the window. Xcode gives an example of this. All the navigation stuff that doesn't sit in the toolbar is still displayed when in fullscreen mode. You can specify a custom window to use when in fullscreen mode if you want a different layout. If you're set on doing it as an NSToolbarItem, work within its limitations. If you just need a global right-click option, consider adding a simple button to give you that access, like the Action button in the Finder. You might also employ click & hold (like the navigation buttons in Safari). I'd also file a bug so that this behavior may change in the future. Don't count on it, but it's good for Apple to know what developers need. On Fri, Aug 26, 2011 at 9:36 AM, Indragie Karunaratne wrote: > Thats actually what I'm doing right now, its an NSToolbarItem with a custom > view but like I said, the right mouse events are not passed to it by > NSToolbarView without that little hack. I could, as you said, circumvent > NSToolbar completely, but when a view is placed outside of the toolbar, it > disappears when Lion goes into fullscreen mode. I don't know if this is a bug > or intended behaviour. > > On 2011-08-26, at 12:03 AM, Mark Munz wrote: > >> The description of what you're trying to do is a bit vague, but >> couldn't you just create an NSToolbarItem with a custom view? You >> might need to do a few tweaks if it needs to resize with the window, >> but that sure seems easier than trying to circumvent the framework as >> you are describing. You'd be able to do virtually anything you want in >> that custom view and you wouldn't be necessarily fighting the >> framework. >> >> Alternatively, you could just create a custom view that is placed at >> the top of your content view of the window and just ignore the >> NSToolbar class completely. >> >> >> On Thu, Aug 25, 2011 at 9:46 PM, Indragie Karunaratne >> wrote: >>> Is there any other way to do this aside from what I'm doing right now? As >>> far as I know, I have two choices: >>> >>> a) Use this method and risk something breaking >>> b) Write an NSToolbar clone >>> >>> I know the risks, but if I could get this to pass through Mac App Store >>> submission then I'd rather deal with possibility of something breaking >>> later on that than to rewrite NSToolbar. The one last thing I can think of >>> is to use the ObjC runtime to retain the original implementation, swizzle >>> hitTest: and check whether my view is under the cursor, and if not, just >>> call the original implementation. However, method swizzling always feels >>> like a dirty workaround so I'm not sure if it would be much better than >>> this (and if it would be acceptable in the MAS). >>> >>> On 2011-08-25, at 10:40 PM, Quincey Morris wrote: >>> Ah, well, yes, if IB doesn't expose the class you need, that makes subclassing impractical. But in that case, replacing the NSToolbarView method seems even more undesirable. On Aug 25, 2011, at 20:55 , Indragie Karunaratne wrote: > I'm not sure how I would get NSToolbar to use my subclass of > NSToolbarView. I can't set the class of the toolbar *view* itself in IB > (nor programatically, as far as I know), because NSToolbarView is a > private class that NSToolbar uses to implement the UI. I can of course > change the class of the NSToolbar object itself to a subclass, but this > wouldn't help me much as there is no public NSToolbar method that allows > me to change the class of its view. >>> >>> ___ >>> >>> 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/unmarked%40gmail.com >>> >>> This email sent to unmar...@gmail.com >>> >> >> >> >> -- >> Mark Munz >> unmarked software >> http://www.unmarked.com/ > > -- Mark Munz unmarked software http://www.unmarked.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: rightMouseDown: never called in NSView subclass
The App Store approval guidelines is pretty clear that the use of non-public API is grounds for rejection. NSToolbarView is undocumented, and therefore doing anything that depends on that class or its (undocumented) behavior would seem like grounds for rejection. This would include adding a category to replace a method (which is fraught with peril regardless - categories aren't designed to replace existing methods, since you can't guarantee the loading order of categories from OS release to OS release - including minor updates), subclassing, method swizzling, or even testing to see if an object is one of those undocumented classes. And even if it gets accepted, there is no guarantee that when you need to make an emergency update to fix some critical bug that somehow slipped through or later arose that you'd get accepted that time. On Aug 25, 2011, at 11:46 PM, Indragie Karunaratne wrote: > Is there any other way to do this aside from what I'm doing right now? As far > as I know, I have two choices: > > a) Use this method and risk something breaking > b) Write an NSToolbar clone > > I know the risks, but if I could get this to pass through Mac App Store > submission then I'd rather deal with possibility of something breaking later > on that than to rewrite NSToolbar. The one last thing I can think of is to > use the ObjC runtime to retain the original implementation, swizzle hitTest: > and check whether my view is under the cursor, and if not, just call the > original implementation. However, method swizzling always feels like a dirty > workaround so I'm not sure if it would be much better than this (and if it > would be acceptable in the MAS). Glenn Andreas gandr...@gandreas.com The most merciful thing in the world ... is the inability of the human mind to correlate all its contents - HPL ___ 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: rightMouseDown: never called in NSView subclass
Thats actually what I'm doing right now, its an NSToolbarItem with a custom view but like I said, the right mouse events are not passed to it by NSToolbarView without that little hack. I could, as you said, circumvent NSToolbar completely, but when a view is placed outside of the toolbar, it disappears when Lion goes into fullscreen mode. I don't know if this is a bug or intended behaviour. On 2011-08-26, at 12:03 AM, Mark Munz wrote: > The description of what you're trying to do is a bit vague, but > couldn't you just create an NSToolbarItem with a custom view? You > might need to do a few tweaks if it needs to resize with the window, > but that sure seems easier than trying to circumvent the framework as > you are describing. You'd be able to do virtually anything you want in > that custom view and you wouldn't be necessarily fighting the > framework. > > Alternatively, you could just create a custom view that is placed at > the top of your content view of the window and just ignore the > NSToolbar class completely. > > > On Thu, Aug 25, 2011 at 9:46 PM, Indragie Karunaratne > wrote: >> Is there any other way to do this aside from what I'm doing right now? As >> far as I know, I have two choices: >> >> a) Use this method and risk something breaking >> b) Write an NSToolbar clone >> >> I know the risks, but if I could get this to pass through Mac App Store >> submission then I'd rather deal with possibility of something breaking later >> on that than to rewrite NSToolbar. The one last thing I can think of is to >> use the ObjC runtime to retain the original implementation, swizzle hitTest: >> and check whether my view is under the cursor, and if not, just call the >> original implementation. However, method swizzling always feels like a dirty >> workaround so I'm not sure if it would be much better than this (and if it >> would be acceptable in the MAS). >> >> On 2011-08-25, at 10:40 PM, Quincey Morris wrote: >> >>> Ah, well, yes, if IB doesn't expose the class you need, that makes >>> subclassing impractical. But in that case, replacing the NSToolbarView >>> method seems even more undesirable. >>> >>> >>> On Aug 25, 2011, at 20:55 , Indragie Karunaratne wrote: >>> I'm not sure how I would get NSToolbar to use my subclass of NSToolbarView. I can't set the class of the toolbar *view* itself in IB (nor programatically, as far as I know), because NSToolbarView is a private class that NSToolbar uses to implement the UI. I can of course change the class of the NSToolbar object itself to a subclass, but this wouldn't help me much as there is no public NSToolbar method that allows me to change the class of its view. >>> >>> >> >> ___ >> >> 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/unmarked%40gmail.com >> >> This email sent to unmar...@gmail.com >> > > > > -- > Mark Munz > unmarked software > http://www.unmarked.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: rightMouseDown: never called in NSView subclass
The description of what you're trying to do is a bit vague, but couldn't you just create an NSToolbarItem with a custom view? You might need to do a few tweaks if it needs to resize with the window, but that sure seems easier than trying to circumvent the framework as you are describing. You'd be able to do virtually anything you want in that custom view and you wouldn't be necessarily fighting the framework. Alternatively, you could just create a custom view that is placed at the top of your content view of the window and just ignore the NSToolbar class completely. On Thu, Aug 25, 2011 at 9:46 PM, Indragie Karunaratne wrote: > Is there any other way to do this aside from what I'm doing right now? As far > as I know, I have two choices: > > a) Use this method and risk something breaking > b) Write an NSToolbar clone > > I know the risks, but if I could get this to pass through Mac App Store > submission then I'd rather deal with possibility of something breaking later > on that than to rewrite NSToolbar. The one last thing I can think of is to > use the ObjC runtime to retain the original implementation, swizzle hitTest: > and check whether my view is under the cursor, and if not, just call the > original implementation. However, method swizzling always feels like a dirty > workaround so I'm not sure if it would be much better than this (and if it > would be acceptable in the MAS). > > On 2011-08-25, at 10:40 PM, Quincey Morris wrote: > >> Ah, well, yes, if IB doesn't expose the class you need, that makes >> subclassing impractical. But in that case, replacing the NSToolbarView >> method seems even more undesirable. >> >> >> On Aug 25, 2011, at 20:55 , Indragie Karunaratne wrote: >> >>> I'm not sure how I would get NSToolbar to use my subclass of NSToolbarView. >>> I can't set the class of the toolbar *view* itself in IB (nor >>> programatically, as far as I know), because NSToolbarView is a private >>> class that NSToolbar uses to implement the UI. I can of course change the >>> class of the NSToolbar object itself to a subclass, but this wouldn't help >>> me much as there is no public NSToolbar method that allows me to change the >>> class of its view. >> >> > > ___ > > 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/unmarked%40gmail.com > > This email sent to unmar...@gmail.com > -- Mark Munz unmarked software http://www.unmarked.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: rightMouseDown: never called in NSView subclass
Is there any other way to do this aside from what I'm doing right now? As far as I know, I have two choices: a) Use this method and risk something breaking b) Write an NSToolbar clone I know the risks, but if I could get this to pass through Mac App Store submission then I'd rather deal with possibility of something breaking later on that than to rewrite NSToolbar. The one last thing I can think of is to use the ObjC runtime to retain the original implementation, swizzle hitTest: and check whether my view is under the cursor, and if not, just call the original implementation. However, method swizzling always feels like a dirty workaround so I'm not sure if it would be much better than this (and if it would be acceptable in the MAS). On 2011-08-25, at 10:40 PM, Quincey Morris wrote: > Ah, well, yes, if IB doesn't expose the class you need, that makes > subclassing impractical. But in that case, replacing the NSToolbarView method > seems even more undesirable. > > > On Aug 25, 2011, at 20:55 , Indragie Karunaratne wrote: > >> I'm not sure how I would get NSToolbar to use my subclass of NSToolbarView. >> I can't set the class of the toolbar *view* itself in IB (nor >> programatically, as far as I know), because NSToolbarView is a private class >> that NSToolbar uses to implement the UI. I can of course change the class of >> the NSToolbar object itself to a subclass, but this wouldn't help me much as >> there is no public NSToolbar method that allows me to change the class of >> its view. > > ___ 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: rightMouseDown: never called in NSView subclass
Ah, well, yes, if IB doesn't expose the class you need, that makes subclassing impractical. But in that case, replacing the NSToolbarView method seems even more undesirable. On Aug 25, 2011, at 20:55 , Indragie Karunaratne wrote: > I'm not sure how I would get NSToolbar to use my subclass of NSToolbarView. I > can't set the class of the toolbar *view* itself in IB (nor programatically, > as far as I know), because NSToolbarView is a private class that NSToolbar > uses to implement the UI. I can of course change the class of the NSToolbar > object itself to a subclass, but this wouldn't help me much as there is no > public NSToolbar method that allows me to change the class of its view. ___ 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: rightMouseDown: never called in NSView subclass
I'm not sure how I would get NSToolbar to use my subclass of NSToolbarView. I
can't set the class of the toolbar *view* itself in IB (nor programatically, as
far as I know), because NSToolbarView is a private class that NSToolbar uses to
implement the UI. I can of course change the class of the NSToolbar object
itself to a subclass, but this wouldn't help me much as there is no public
NSToolbar method that allows me to change the class of its view.
On 2011-08-25, at 9:35 PM, Quincey Morris wrote:
> On Aug 25, 2011, at 19:48 , Indragie Karunaratne wrote:
>
>> Based on Corbin's tip, I overrode -hitTest: on NSToolbarView to call
>> NSView's implementation instead and suddenly everything works. I expected
>> something to break in NSToolbarView from doing this, but I've tested pretty
>> thoroughly and there seem to be no issues. I don't know exactly how
>> dangerous this is because I don't know what NSToolbarView's implementation
>> of hitTest: is, but so far no issues.
>>
>> @interface NSToolbarView : NSView
>> @end
>>
>> @interface NSToolbarView (RightMouse)
>> @end
>>
>> @implementation NSToolbarView (RightMouse)
>>
>> - (void)hitTest:(NSPoint)aPoint
>> {
>>[super hitTest:aPoint];
>> }
>>
>> @end
>>
>> That said, would my application get rejected from the Mac App Store for
>> overriding *public* methods of a *private* class via a category? I could
>> achieve the same result by checking the class and swizzling NSView's
>> implementation of -hitTest:, but if I could get away with this it would be a
>> lot easier (and cleaner).
>
> I think it's a misstatement to say that you "overrode" 'hitTest:'. In Obj-C,
> overriding conventionally means supplying a subclass implementation that
> takes the place of the superclass implementation. What you actually did was
> to *replace* 'hitTest:'. However, if you want to treat this as a quibble over
> usage, that's fine.
>
> The real problem with your approach is that it's a bit dangerous. You don't
> *know* that NSToolbarView's own override of 'hitTest:' isn't itself
> implemented in a category. If it is, then you are competing for the role of
> replacer, and you might lose.
>
> A better approach (if it's possible -- which it may not be if IB makes things
> hard for you) is to subclass NSToolbarView, and change the toolbar's class in
> IB after adding it to the window. (If you're creating the toolbar entirely
> programmatically, it's more straightforward, of course.) Then you can
> *really* override 'hitTest:', in the normal subclass way.
>
> Finally, although you haven't seen any side effects of throwing away the
> NSToolbarView implementation of 'hitTest:', which is what the above code
> does, you don't know what else you might have broken. It would be safer to
> put code in your override to test directly for your custom toolbar item view,
> and send the message directly to your view if it's the one under the mouse.
> If not, call the NSToolbarView method, not the NSToolbarView super method.
> Again, this is easiest to do if you're actually using a NSToolbarView
> subclass.
>
>
___
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: rightMouseDown: never called in NSView subclass
On Aug 25, 2011, at 19:48 , Indragie Karunaratne wrote:
> Based on Corbin's tip, I overrode -hitTest: on NSToolbarView to call NSView's
> implementation instead and suddenly everything works. I expected something to
> break in NSToolbarView from doing this, but I've tested pretty thoroughly and
> there seem to be no issues. I don't know exactly how dangerous this is
> because I don't know what NSToolbarView's implementation of hitTest: is, but
> so far no issues.
>
> @interface NSToolbarView : NSView
> @end
>
> @interface NSToolbarView (RightMouse)
> @end
>
> @implementation NSToolbarView (RightMouse)
>
> - (void)hitTest:(NSPoint)aPoint
> {
>[super hitTest:aPoint];
> }
>
> @end
>
> That said, would my application get rejected from the Mac App Store for
> overriding *public* methods of a *private* class via a category? I could
> achieve the same result by checking the class and swizzling NSView's
> implementation of -hitTest:, but if I could get away with this it would be a
> lot easier (and cleaner).
I think it's a misstatement to say that you "overrode" 'hitTest:'. In Obj-C,
overriding conventionally means supplying a subclass implementation that takes
the place of the superclass implementation. What you actually did was to
*replace* 'hitTest:'. However, if you want to treat this as a quibble over
usage, that's fine.
The real problem with your approach is that it's a bit dangerous. You don't
*know* that NSToolbarView's own override of 'hitTest:' isn't itself implemented
in a category. If it is, then you are competing for the role of replacer, and
you might lose.
A better approach (if it's possible -- which it may not be if IB makes things
hard for you) is to subclass NSToolbarView, and change the toolbar's class in
IB after adding it to the window. (If you're creating the toolbar entirely
programmatically, it's more straightforward, of course.) Then you can *really*
override 'hitTest:', in the normal subclass way.
Finally, although you haven't seen any side effects of throwing away the
NSToolbarView implementation of 'hitTest:', which is what the above code does,
you don't know what else you might have broken. It would be safer to put code
in your override to test directly for your custom toolbar item view, and send
the message directly to your view if it's the one under the mouse. If not, call
the NSToolbarView method, not the NSToolbarView super method. Again, this is
easiest to do if you're actually using a NSToolbarView subclass.
___
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: rightMouseDown: never called in NSView subclass
Based on Corbin's tip, I overrode -hitTest: on NSToolbarView to call NSView's
implementation instead and suddenly everything works. I expected something to
break in NSToolbarView from doing this, but I've tested pretty thoroughly and
there seem to be no issues. I don't know exactly how dangerous this is because
I don't know what NSToolbarView's implementation of hitTest: is, but so far no
issues.
@interface NSToolbarView : NSView
@end
@interface NSToolbarView (RightMouse)
@end
@implementation NSToolbarView (RightMouse)
- (void)hitTest:(NSPoint)aPoint
{
[super hitTest:aPoint];
}
@end
That said, would my application get rejected from the Mac App Store for
overriding *public* methods of a *private* class via a category? I could
achieve the same result by checking the class and swizzling NSView's
implementation of -hitTest:, but if I could get away with this it would be a
lot easier (and cleaner).
On 2011-08-25, at 4:52 PM, Raleigh Ledet wrote:
> A contextual menu in a toolbar? Lets think about this for a moment.
>
> A) such a command would be hard to discover. Your customers have other ways
> to activate the same commands right? If not, why not use a popup button here?
> B) I assume that's because you have an action tied to single click…. why not
> look for a click and hold, then pop-up a menu a' la Safari's back/forward
> tool bar buttons. Oh! and users have an alternate way to get to these actions
> / settings right?
>
> -raleigh
>
> On Aug 25, 2011, at 3:39 PM, Indragie Karunaratne wrote:
>
>> I just need to present a contextual menu from my custom view toolbar item,
>> but NSToolbarView is not passing the right mouse events down, so
>> -menuForEvent: is never called.
>>
>> On 2011-08-25, at 4:27 PM, Corbin Dunn wrote:
>>
>>> ToolbarView overrides hitTest; to do some magic; that is probably the
>>> source of your problem.
>>>
>>> What are you trying to do?
>>>
>>> corbin
>>>
>>> On Aug 25, 2011, at 3:14 PM, Indragie Karunaratne wrote:
>>>
>>>> Just realized something interesting, and remembered a key detail that I
>>>> forgot to mention. The view in question is a custom view inside the
>>>> toolbar of the window. The NSToolbar by default has a contextual menu that
>>>> appears when the customizable property is set to YES. However, even though
>>>> there is no menu when customizable is set to NO, I suspected that it was
>>>> still trapping right mouse events. So I used a category on the private
>>>> NSToolbarView class that manages the UI for NSToolbar to check whether it
>>>> was receiving the events:
>>>>
>>>> @interface NSToolbarView : NSView
>>>> @end
>>>>
>>>> @interface NSToolbarView (RightMouse)
>>>> @end
>>>>
>>>> @implementation NSToolbarView (RightMouse)
>>>>
>>>> - (void)rightMouseDown:(NSEvent*)theEvent
>>>> {
>>>> NSLog(@"right mouse");
>>>> }
>>>>
>>>> @end
>>>>
>>>> And as expected, the method is called. This leaves me wondering how the
>>>> toolbar view can receive the events when my own view inside the toolbar
>>>> can not (as the event would have to be forwarded up the responder chain to
>>>> the toolbar in order for it to receive it).
>>>>
>>>> On 2011-08-25, at 1:58 PM, Ken Thomases wrote:
>>>>
>>>>> On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne
>>>>> wrote:
>>>>>
>>>>>> I have an NSView subclass that I'm trying to capture right clicks in. I
>>>>>> override the rightMouseDown: method but it is never called.
>>>>>
>>>>> Any chance you simply have a typo or misspelling in your method signature?
>>>>>
>>>>> -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/corbind%40apple.com
>>>>
>>>> This email sent to corb...@apple.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/ledet%40apple.com
>>
>> This email sent to le...@apple.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: rightMouseDown: never called in NSView subclass
This would make more sense if I explained what the view itself was. Long story
short, it's a pretty huge (and important) custom control that runs all the way
across the toolbar. There are other ways to access the commands (via the
application menus + shortcuts) but I would also like to have a contextual menu.
On 2011-08-25, at 4:52 PM, Raleigh Ledet wrote:
> A contextual menu in a toolbar? Lets think about this for a moment.
>
> A) such a command would be hard to discover. Your customers have other ways
> to activate the same commands right? If not, why not use a popup button here?
> B) I assume that's because you have an action tied to single click…. why not
> look for a click and hold, then pop-up a menu a' la Safari's back/forward
> tool bar buttons. Oh! and users have an alternate way to get to these actions
> / settings right?
>
> -raleigh
>
> On Aug 25, 2011, at 3:39 PM, Indragie Karunaratne wrote:
>
>> I just need to present a contextual menu from my custom view toolbar item,
>> but NSToolbarView is not passing the right mouse events down, so
>> -menuForEvent: is never called.
>>
>> On 2011-08-25, at 4:27 PM, Corbin Dunn wrote:
>>
>>> ToolbarView overrides hitTest; to do some magic; that is probably the
>>> source of your problem.
>>>
>>> What are you trying to do?
>>>
>>> corbin
>>>
>>> On Aug 25, 2011, at 3:14 PM, Indragie Karunaratne wrote:
>>>
>>>> Just realized something interesting, and remembered a key detail that I
>>>> forgot to mention. The view in question is a custom view inside the
>>>> toolbar of the window. The NSToolbar by default has a contextual menu that
>>>> appears when the customizable property is set to YES. However, even though
>>>> there is no menu when customizable is set to NO, I suspected that it was
>>>> still trapping right mouse events. So I used a category on the private
>>>> NSToolbarView class that manages the UI for NSToolbar to check whether it
>>>> was receiving the events:
>>>>
>>>> @interface NSToolbarView : NSView
>>>> @end
>>>>
>>>> @interface NSToolbarView (RightMouse)
>>>> @end
>>>>
>>>> @implementation NSToolbarView (RightMouse)
>>>>
>>>> - (void)rightMouseDown:(NSEvent*)theEvent
>>>> {
>>>> NSLog(@"right mouse");
>>>> }
>>>>
>>>> @end
>>>>
>>>> And as expected, the method is called. This leaves me wondering how the
>>>> toolbar view can receive the events when my own view inside the toolbar
>>>> can not (as the event would have to be forwarded up the responder chain to
>>>> the toolbar in order for it to receive it).
>>>>
>>>> On 2011-08-25, at 1:58 PM, Ken Thomases wrote:
>>>>
>>>>> On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne
>>>>> wrote:
>>>>>
>>>>>> I have an NSView subclass that I'm trying to capture right clicks in. I
>>>>>> override the rightMouseDown: method but it is never called.
>>>>>
>>>>> Any chance you simply have a typo or misspelling in your method signature?
>>>>>
>>>>> -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/corbind%40apple.com
>>>>
>>>> This email sent to corb...@apple.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/ledet%40apple.com
>>
>> This email sent to le...@apple.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: rightMouseDown: never called in NSView subclass
A contextual menu in a toolbar? Lets think about this for a moment.
A) such a command would be hard to discover. Your customers have other ways to
activate the same commands right? If not, why not use a popup button here?
B) I assume that's because you have an action tied to single click…. why not
look for a click and hold, then pop-up a menu a' la Safari's back/forward tool
bar buttons. Oh! and users have an alternate way to get to these actions /
settings right?
-raleigh
On Aug 25, 2011, at 3:39 PM, Indragie Karunaratne wrote:
> I just need to present a contextual menu from my custom view toolbar item,
> but NSToolbarView is not passing the right mouse events down, so
> -menuForEvent: is never called.
>
> On 2011-08-25, at 4:27 PM, Corbin Dunn wrote:
>
>> ToolbarView overrides hitTest; to do some magic; that is probably the source
>> of your problem.
>>
>> What are you trying to do?
>>
>> corbin
>>
>> On Aug 25, 2011, at 3:14 PM, Indragie Karunaratne wrote:
>>
>>> Just realized something interesting, and remembered a key detail that I
>>> forgot to mention. The view in question is a custom view inside the toolbar
>>> of the window. The NSToolbar by default has a contextual menu that appears
>>> when the customizable property is set to YES. However, even though there is
>>> no menu when customizable is set to NO, I suspected that it was still
>>> trapping right mouse events. So I used a category on the private
>>> NSToolbarView class that manages the UI for NSToolbar to check whether it
>>> was receiving the events:
>>>
>>> @interface NSToolbarView : NSView
>>> @end
>>>
>>> @interface NSToolbarView (RightMouse)
>>> @end
>>>
>>> @implementation NSToolbarView (RightMouse)
>>>
>>> - (void)rightMouseDown:(NSEvent*)theEvent
>>> {
>>> NSLog(@"right mouse");
>>> }
>>>
>>> @end
>>>
>>> And as expected, the method is called. This leaves me wondering how the
>>> toolbar view can receive the events when my own view inside the toolbar can
>>> not (as the event would have to be forwarded up the responder chain to the
>>> toolbar in order for it to receive it).
>>>
>>> On 2011-08-25, at 1:58 PM, Ken Thomases wrote:
>>>
>>>> On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne
>>>> wrote:
>>>>
>>>>> I have an NSView subclass that I'm trying to capture right clicks in. I
>>>>> override the rightMouseDown: method but it is never called.
>>>>
>>>> Any chance you simply have a typo or misspelling in your method signature?
>>>>
>>>> -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/corbind%40apple.com
>>>
>>> This email sent to corb...@apple.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/ledet%40apple.com
>
> This email sent to le...@apple.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: rightMouseDown: never called in NSView subclass
I just need to present a contextual menu from my custom view toolbar item, but
NSToolbarView is not passing the right mouse events down, so -menuForEvent: is
never called.
On 2011-08-25, at 4:27 PM, Corbin Dunn wrote:
> ToolbarView overrides hitTest; to do some magic; that is probably the source
> of your problem.
>
> What are you trying to do?
>
> corbin
>
> On Aug 25, 2011, at 3:14 PM, Indragie Karunaratne wrote:
>
>> Just realized something interesting, and remembered a key detail that I
>> forgot to mention. The view in question is a custom view inside the toolbar
>> of the window. The NSToolbar by default has a contextual menu that appears
>> when the customizable property is set to YES. However, even though there is
>> no menu when customizable is set to NO, I suspected that it was still
>> trapping right mouse events. So I used a category on the private
>> NSToolbarView class that manages the UI for NSToolbar to check whether it
>> was receiving the events:
>>
>> @interface NSToolbarView : NSView
>> @end
>>
>> @interface NSToolbarView (RightMouse)
>> @end
>>
>> @implementation NSToolbarView (RightMouse)
>>
>> - (void)rightMouseDown:(NSEvent*)theEvent
>> {
>> NSLog(@"right mouse");
>> }
>>
>> @end
>>
>> And as expected, the method is called. This leaves me wondering how the
>> toolbar view can receive the events when my own view inside the toolbar can
>> not (as the event would have to be forwarded up the responder chain to the
>> toolbar in order for it to receive it).
>>
>> On 2011-08-25, at 1:58 PM, Ken Thomases wrote:
>>
>>> On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne
>>> wrote:
>>>
>>>> I have an NSView subclass that I'm trying to capture right clicks in. I
>>>> override the rightMouseDown: method but it is never called.
>>>
>>> Any chance you simply have a typo or misspelling in your method signature?
>>>
>>> -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/corbind%40apple.com
>>
>> This email sent to corb...@apple.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: rightMouseDown: never called in NSView subclass
ToolbarView overrides hitTest; to do some magic; that is probably the source of
your problem.
What are you trying to do?
corbin
On Aug 25, 2011, at 3:14 PM, Indragie Karunaratne wrote:
> Just realized something interesting, and remembered a key detail that I
> forgot to mention. The view in question is a custom view inside the toolbar
> of the window. The NSToolbar by default has a contextual menu that appears
> when the customizable property is set to YES. However, even though there is
> no menu when customizable is set to NO, I suspected that it was still
> trapping right mouse events. So I used a category on the private
> NSToolbarView class that manages the UI for NSToolbar to check whether it was
> receiving the events:
>
> @interface NSToolbarView : NSView
> @end
>
> @interface NSToolbarView (RightMouse)
> @end
>
> @implementation NSToolbarView (RightMouse)
>
> - (void)rightMouseDown:(NSEvent*)theEvent
> {
>NSLog(@"right mouse");
> }
>
> @end
>
> And as expected, the method is called. This leaves me wondering how the
> toolbar view can receive the events when my own view inside the toolbar can
> not (as the event would have to be forwarded up the responder chain to the
> toolbar in order for it to receive it).
>
> On 2011-08-25, at 1:58 PM, Ken Thomases wrote:
>
>> On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne
>> wrote:
>>
>>> I have an NSView subclass that I'm trying to capture right clicks in. I
>>> override the rightMouseDown: method but it is never called.
>>
>> Any chance you simply have a typo or misspelling in your method signature?
>>
>> -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/corbind%40apple.com
>
> This email sent to corb...@apple.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: rightMouseDown: never called in NSView subclass
Just realized something interesting, and remembered a key detail that I forgot
to mention. The view in question is a custom view inside the toolbar of the
window. The NSToolbar by default has a contextual menu that appears when the
customizable property is set to YES. However, even though there is no menu when
customizable is set to NO, I suspected that it was still trapping right mouse
events. So I used a category on the private NSToolbarView class that manages
the UI for NSToolbar to check whether it was receiving the events:
@interface NSToolbarView : NSView
@end
@interface NSToolbarView (RightMouse)
@end
@implementation NSToolbarView (RightMouse)
- (void)rightMouseDown:(NSEvent*)theEvent
{
NSLog(@"right mouse");
}
@end
And as expected, the method is called. This leaves me wondering how the toolbar
view can receive the events when my own view inside the toolbar can not (as the
event would have to be forwarded up the responder chain to the toolbar in order
for it to receive it).
On 2011-08-25, at 1:58 PM, Ken Thomases wrote:
> On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne
> wrote:
>
>> I have an NSView subclass that I'm trying to capture right clicks in. I
>> override the rightMouseDown: method but it is never called.
>
> Any chance you simply have a typo or misspelling in your method signature?
>
> -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 arch...@mail-archive.com
Re: rightMouseDown: never called in NSView subclass
Triple checked, I even copy/pasted the method directly from the docs to make
sure:
- (void)rightMouseDown:(NSEvent *)theEvent
{
NSLog(@"right mouse");
[super rightMouseDown:theEvent];
}
Could it be something to do with the fact that it's a layer hosting view? I
don't see how that would make a difference in the responder chain but that's
all I can think of.
On 2011-08-25, at 1:58 PM, Ken Thomases wrote:
> On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne
> wrote:
>
>> I have an NSView subclass that I'm trying to capture right clicks in. I
>> override the rightMouseDown: method but it is never called.
>
> Any chance you simply have a typo or misspelling in your method signature?
>
> -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 arch...@mail-archive.com
Re: rightMouseDown: never called in NSView subclass
On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne wrote: > I have an NSView subclass that I'm trying to capture right clicks in. I > override the rightMouseDown: method but it is never called. Any chance you simply have a typo or misspelling in your method signature? -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 arch...@mail-archive.com
Re: rightMouseDown: never called in NSView subclass
I'm on Lion, and I did find this bit in the AppKit Release Notes: NSView now passes unhandled -rightMouseDown: events up the responder chain Prior to 10.7, NSView did not pass unhandled -rightMouseDown: events up the responder chain. On 10.7, NSView passes -rightMouseDown: up the responder chain, if AppKit doesn’t find an associated context menu to display for the view. To avoid binary compatibility issues, this new behavior is enabled only for applications linked on 10.7 or later. I'm not sure how this would cause my issue though, because I'm overriding -rightMouseDown:. On 2011-08-25, at 12:56 PM, Kyle Sluder wrote: > On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne > wrote: >> I have an NSView subclass that I'm trying to capture right clicks in. I >> override the rightMouseDown: method but it is never called. This is the >> first time I've come across this issue as it has always worked fine for me >> before. All of the other mouse event methods (mouseDown:, mouseUp:, >> mouseDragged: etc.) work just fine. The view itself is a CALayer-hosting >> view embedded inside an NSScrollView (unless I'm screwing up something >> really obvious, I'm pretty sure the issue is related to this). > > There's something in the release notes about this… what OS are you on? > > --Kyle Sluder ___ 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: rightMouseDown: never called in NSView subclass
On Thu, Aug 25, 2011 at 11:45 AM, Indragie Karunaratne wrote: > I have an NSView subclass that I'm trying to capture right clicks in. I > override the rightMouseDown: method but it is never called. This is the first > time I've come across this issue as it has always worked fine for me before. > All of the other mouse event methods (mouseDown:, mouseUp:, mouseDragged: > etc.) work just fine. The view itself is a CALayer-hosting view embedded > inside an NSScrollView (unless I'm screwing up something really obvious, I'm > pretty sure the issue is related to this). There's something in the release notes about this… what OS are you on? --Kyle Sluder ___ 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
rightMouseDown: never called in NSView subclass
I have an NSView subclass that I'm trying to capture right clicks in. I override the rightMouseDown: method but it is never called. This is the first time I've come across this issue as it has always worked fine for me before. All of the other mouse event methods (mouseDown:, mouseUp:, mouseDragged: etc.) work just fine. The view itself is a CALayer-hosting view embedded inside an NSScrollView (unless I'm screwing up something really obvious, I'm pretty sure the issue is related to this). Any help is appreciated, Thanks___ 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
rightMouseDown: never called in NSView subclass
I have an NSView subclass that I'm trying to capture right clicks in. I override the rightMouseDown: method but it is never called. This is the first time I've come across this issue as it has always worked fine for me before. All of the other mouse event methods (mouseDown:, mouseUp:, mouseDragged: etc.) work just fine. The view itself is a CALayer-hosting view embedded inside an NSScrollView (unless I'm screwing up something really obvious, I'm pretty sure the issue is related to this). Any help is appreciated, Thanks___ 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: NSView subclass does not call designated initializer
it's calling initWithCoder:
read the NIB Object Life Cycle section in the documentation
"In iOS, any object that conforms to the NSCoding protocol is initialized using
the initWithCoder: method. This includes all subclasses of UIView and
UIViewController whether they are part of the default Interface Builder library
or custom classes you define."
On Aug 22, 2011, at 8:57 PM, allan greenier wrote:
> This is for an iPhone app.I've made a subclass (named Box) of NSView, Xcode
> 4.1 made it with a designated initializer for me to fill out.
> - (id)initWithFrame:(CGRect)frame
> I've dropped a view into my window in Interface Builder, set it's class to
> Box.
> I am *positive* that the view is my class.
> When I run the app, the designated initializer does not run.
> I have an NSLog in there to prove it to myself.
>
> Is there something else I have to do to get IB to call the designated
> Initializer?
> It acts as if it's calling [[Box alloc] init] instead ...
>
> Here's the implementation code.
>
> - (id)initWithFrame:(CGRect)frame
> {
> NSLog(@"Box initWithFrame");
> self = [super initWithFrame:frame];
> if (self)
> {
> // Initialization code
> // [self hookMeUpBaby];
>
> }
> return self;
> }
> ___
>
> 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/rols%40rols.org
>
> This email sent to r...@rols.org
___
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: NSView subclass does not call designated initializer
On 22/08/2011, at 10:57 PM, allan greenier wrote: > This is for an iPhone app.I've made a subclass (named Box) of NSView, ??? iPhone has no class called NSView... > Xcode 4.1 made it with a designated initializer for me to fill out. > - (id)initWithFrame:(CGRect)frame > I've dropped a view into my window in Interface Builder, set it's class to > Box. > I am *positive* that the view is my class. > When I run the app, the designated initializer does not run. Assuming you meant UIView, when views are dearchived from a nib, they are initialised using -initWithCoder:, not initWithFrame: --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
NSView subclass does not call designated initializer
This is for an iPhone app.I've made a subclass (named Box) of NSView, Xcode 4.1
made it with a designated initializer for me to fill out.
- (id)initWithFrame:(CGRect)frame
I've dropped a view into my window in Interface Builder, set it's class to Box.
I am *positive* that the view is my class.
When I run the app, the designated initializer does not run.
I have an NSLog in there to prove it to myself.
Is there something else I have to do to get IB to call the designated
Initializer?
It acts as if it's calling [[Box alloc] init] instead ...
Here's the implementation code.
- (id)initWithFrame:(CGRect)frame
{
NSLog(@"Box initWithFrame");
self = [super initWithFrame:frame];
if (self)
{
// Initialization code
// [self hookMeUpBaby];
}
return self;
}
___
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: Tutorial for writing a bindings-compliant NSView subclass?
On Feb 1, 2010, at 11:38 AM, Matt Neuburg wrote: > On Mon, 1 Feb 2010 08:43:27 -0500, Alexander Heinz > said: >> Hello fellow Cocoa-devs, >> >> Does anyone know where to find a good tutorial or more information about > writing a bindings-compatible subclass of NSView? > > Did you even *try* google? Searching on "bindings tutorial nsview subclass" > led almost directly to this. > > http://homepage.mac.com/mmalc/CocoaExamples/controllers.html > > m. Yep, I'm an idiot. I must have been using some really stupid search terms or something. The link you gave didn't have what I needed, but I found another page using the same search terms that told me what I needed to know. Thanks, - Alex___ 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: Tutorial for writing a bindings-compliant NSView subclass?
On Mon, Feb 1, 2010 at 8:38 AM, Matt Neuburg wrote: > Did you even *try* google? Searching on "bindings tutorial nsview subclass" > led almost directly to this. The OP explained that he was confused by the sample code. --Kyle Sluder ___ 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: Tutorial for writing a bindings-compliant NSView subclass?
On Mon, 1 Feb 2010 08:43:27 -0500, Alexander Heinz said: >Hello fellow Cocoa-devs, > >Does anyone know where to find a good tutorial or more information about writing a bindings-compatible subclass of NSView? Did you even *try* google? Searching on "bindings tutorial nsview subclass" led almost directly to this. http://homepage.mac.com/mmalc/CocoaExamples/controllers.html m. -- matt neuburg, phd = m...@tidbits.com, <http://www.tidbits.com/matt/> A fool + a tool + an autorelease pool = cool! AppleScript: the Definitive Guide - Second Edition! http://www.tidbits.com/matt/default.html#applescriptthings ___ 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
Tutorial for writing a bindings-compliant NSView subclass?
Hello fellow Cocoa-devs, Does anyone know where to find a good tutorial or more information about writing a bindings-compatible subclass of NSView? I've seen Apple's example code on the subject, but it looks like it's a lot more complicated than it should be. I don't need Interface Builder support, either, just a straightforward description of what methods I need to provide and/or override to make is possible to (programmatically) bind some property of my view to a key path of another object. By the way, how come this stuff doesn't have any documentation in the Developer Reference? Help appreciated, Alex___ 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: drag and drop form NSViewController or NSView subclass
HEHEH ok.. I have realized that it can't be done through the NSViewController but its view... G. On Dec 7, 2009, at 2:38 PM, Gustavo Pizano wrote: > Hello. > > Sorry I have answered my own question, I can use the NSViewController, but to > register the types I must do it in the view of the controller, even if I do > [[self view] registerForDraggedTypes: ] for the rest of the dragging > destination methods it seems I can use the NSViewcontroller... > > G. > > > On Dec 7, 2009, at 10:42 AM, Gustavo Pizano wrote: > >> Hello.. >> >> I implemented in the past drag and drop, but I did it from within the sub >> classes of NSView, Im wondering if I can do the same from within the >> NSViewControllers that control the view.. what implications it has? what you >> recommend best? >> >> Thanks >> >> Gustavo > ___ 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: drag and drop form NSViewController or NSView subclass
Hello. Sorry I have answered my own question, I can use the NSViewController, but to register the types I must do it in the view of the controller, even if I do [[self view] registerForDraggedTypes: ] for the rest of the dragging destination methods it seems I can use the NSViewcontroller... G. On Dec 7, 2009, at 10:42 AM, Gustavo Pizano wrote: > Hello.. > > I implemented in the past drag and drop, but I did it from within the sub > classes of NSView, Im wondering if I can do the same from within the > NSViewControllers that control the view.. what implications it has? what you > recommend best? > > Thanks > > Gustavo ___ 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
drag and drop form NSViewController or NSView subclass
Hello.. I implemented in the past drag and drop, but I did it from within the sub classes of NSView, Im wondering if I can do the same from within the NSViewControllers that control the view.. what implications it has? what you recommend best? Thanks Gustavo ___ 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: -[CALayer hitTest:] incorrect when embedding layer-backed NSView subclass inside NSScrollView
On Mon, May 4, 2009 at 6:19 PM, Steven Degutis wrote:
> Specifically, you'll notice that the -hitTest: returns the correct
> layer *only* if you click the view while it is fully visible in the
> window, and before you have made it not-fully-visible for the first
> time. After you resize the scroll view to hide any portion of this
> NSView subclass, -hitTest: will consistently return the wrong layer
> every time.
[...]
> - (void) mouseDown:(NSEvent*)event {
> NSPoint point = [self convertPoint:[event locationInWindow]
> fromView:nil];
> CALayer *layer = [self.layer hitTest:NSPointToCGPoint(point)];
> NSLog(@"%@", [layer name]);
> }
>
> I've tried to replace `self` with the enclosing scroll view, or its
> content view or document view, in the -mouseDown: method, and many
> combinations of this. Nothing seems to do the trick.
-hitTest on CALayer, like NSView, takes a point in the superlayer's coordinate
system.
Jim
___
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
-[CALayer hitTest:] incorrect when embedding layer-backed NSView subclass inside NSScrollView
Hello.
The basic problem boils down to -hitTest: returning a completely
incorrect layer when the layer-backed NSView with the root layer is
inside a scroll view.
I've provided some sample code to demonstrate this problem. To see it
in action, just put the code into an NSView class, and stick an NSView
in your NIB with the custom class name, and embed this in an
NSScrollView.
Specifically, you'll notice that the -hitTest: returns the correct
layer *only* if you click the view while it is fully visible in the
window, and before you have made it not-fully-visible for the first
time. After you resize the scroll view to hide any portion of this
NSView subclass, -hitTest: will consistently return the wrong layer
every time.
- (void) awakeFromNib {
[self setFrameSize:NSMakeSize(300, 300)];
[[self enclosingScrollView] setWantsLayer:YES];
int i;
for (i = 0; i < 6; i++) {
CALayer *layer = [CALayer layer];
layer.frame = CGRectMake(0, i * 50, 300, 50);
float r = (float)(random() % 100) / 100.0;
float g = (float)(random() % 100) / 100.0;
float b = (float)(random() % 100) / 100.0;
CGColorRef color = CGColorCreateGenericRGB(r,g,b,1.0);
layer.backgroundColor = color;
CGColorRelease(color);
layer.name = [NSString stringWithFormat:@"%d", i];
[self.layer addSublayer:layer];
}
}
- (void) drawRect:(NSRect)rect {
[[[NSColor greenColor] colorWithAlphaComponent:0.5]
drawSwatchInRect:[self bounds]];
}
- (void) mouseDown:(NSEvent*)event {
NSPoint point = [self convertPoint:[event locationInWindow]
fromView:nil];
CALayer *layer = [self.layer hitTest:NSPointToCGPoint(point)];
NSLog(@"%@", [layer name]);
}
I've tried to replace `self` with the enclosing scroll view, or its
content view or document view, in the -mouseDown: method, and many
combinations of this. Nothing seems to do the trick. I've also not
seen anybody have this same problem on cocoa-dev, google, et al.
Thanks in advance for any help!
-Steven Degutis
___
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: NSView subclass
Now another problem! When I put this in the MyViewSubclass header: @interface NSObject (MyViewSubclassDelegation) - (void)pointClicked:(NSPoint)point; @end I get an XCode internal error: Uncaught Exception: *** -[NSCFString substringWithRange:]: Range or index out of bounds It was actually preventing me from typing the category name: I had to type the name first, and put the parentheses around after. The error message appears whenever I click inside the category name parentheses. But I can click "continue" and then build without any trouble. What could be causing this? Has it something to do with code completion? dkj ___ 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: NSView subclass
On Oct 15, 2008, at 2:30 PM, Scott Andrew wrote:
If its a delegate you would want to check if the delegate handles
the selector with respondsToSelector and the use performSelector to
make the call. For example
if ([delegate respondsToSelector:@selector(pointClicked:)])
[delegate performSelector:@selector(pointClicked:) withObject:
[NSValue valueWithPoint:(pt)]];
NSValue is a normal class just like any other class. KVO, and KVC
happen to use NSValue to box and unbox non object types. If you pass a
function or method an NSValue, it will receive an NSValue. Methods
like setValue:forKey: actually receive an NSValue object, but then
manually unbox the value before calling the methods indicated by the
second key argument.
Since you've declared your delegate method in a header, you can call
it directly. This eliminates the need for performSelector:withObject:,
which is probably what caused Scott to try to use NSValue.
You can now write:
if ([delegate respondsToSelector:@selector(pointClicked:)]) {
[delegate pointClicked:pt];
}
Also, instead of this:
@interface NSObject ()
- (void)pointClicked:(NSPoint)point;
@end
You should write
@interface NSObject (MyViewSubclassDelegation)
- (void)pointClicked:(NSPoint)point;
@end
Having the category name is more descriptive. Also, having an empty
category name is a special form and means you're using a class
extension. You can read about those here: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_5.html#/
/apple_ref/doc/uid/TP30001163-CH20-SW2
Good Luck -
Jon Hess
This should work. I believe the NSValue will resolve to the NSPoint
in runtime.
Scott Andrew
On Oct 15, 2008, at 2:15 PM, DKJ wrote:
I've written a subclass of NSView. It calls a method its delegate
can implement to detect mouse clicks. I've put something like this
in the header file:
// delegate method:
@interface NSObject ()
- (void)pointClicked:(NSPoint)point;
@end
This is enough to prevent a "no -pointClicked: method found"
compiler warning. But is it the best way to do it?
dkj
___
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/scottandrew%40roadrunner.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/jhess%40apple.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]
Re: NSView subclass
You should really name your category. Something like: @interface NSObject (MyViewDelegate) Even better if you're targeting Leopard only is to use a formal protocol, but with optional methods. e.g. @protocol MyViewDelegate @optional - (void)pointClicked:(NSPoint)point; @end On 15 Oct 2008, at 22:15, DKJ wrote: I've written a subclass of NSView. It calls a method its delegate can implement to detect mouse clicks. I've put something like this in the header file: // delegate method: @interface NSObject () - (void)pointClicked:(NSPoint)point; @end This is enough to prevent a "no -pointClicked: method found" compiler warning. But is it the best way to do it? dkj ___ 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/cocoadev%40mikeabdullah.net 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: NSView subclass
If its a delegate you would want to check if the delegate handles the selector with respondsToSelector and the use performSelector to make the call. For example if ([delegate respondsToSelector:@selector(pointClicked:)]) [delegate performSelector:@selector(pointClicked:) withObject: [NSValue valueWithPoint:(pt)]]; This should work. I believe the NSValue will resolve to the NSPoint in runtime. Scott Andrew On Oct 15, 2008, at 2:15 PM, DKJ wrote: I've written a subclass of NSView. It calls a method its delegate can implement to detect mouse clicks. I've put something like this in the header file: // delegate method: @interface NSObject () - (void)pointClicked:(NSPoint)point; @end This is enough to prevent a "no -pointClicked: method found" compiler warning. But is it the best way to do it? dkj ___ 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/scottandrew%40roadrunner.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]
NSView subclass
I've written a subclass of NSView. It calls a method its delegate can implement to detect mouse clicks. I've put something like this in the header file: // delegate method: @interface NSObject () - (void)pointClicked:(NSPoint)point; @end This is enough to prevent a "no -pointClicked: method found" compiler warning. But is it the best way to do it? dkj ___ 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: add dummy NSView subclass to framework?
Thanks Graham So then I should have an nsobjectcontroller subclass which is then available as the interface to my framework and not as it currently is with just a nsobject subclass. the nsobject subclass would then become the "model" as such. is this right? Thanks On 22/08/2008, at 12:47 PM, Graham Cox wrote: On 22 Aug 2008, at 1:53 pm, Kieren Eaton wrote: With bindings I cant connect to the framework classes directly so should I add a dummy nsview subclass that will allow my interface bindings access to the frameworks ivars etc? A dummy NSView? No. A controller? Yes. This is what controllers are for. hth, Graham Kieren Olearia - Talking Books on the Mac http://olearia.googlecode.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 [EMAIL PROTECTED]
Re: add dummy NSView subclass to framework?
On 22 Aug 2008, at 1:53 pm, Kieren Eaton wrote: With bindings I cant connect to the framework classes directly so should I add a dummy nsview subclass that will allow my interface bindings access to the frameworks ivars etc? A dummy NSView? No. A controller? Yes. This is what controllers are for. hth, 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 [EMAIL PROTECTED]
add dummy NSView subclass to framework?
Hi I have lately been struggling with bindings A LOT. I have looked at a lot of tutorials but they have not seemed to be what I need. I have a framework which does all the grunt work for my application and the app controller is just a frontend to the framework. With bindings I cant connect to the framework classes directly so should I add a dummy nsview subclass that will allow my interface bindings access to the frameworks ivars etc? Also is this a good programming/code technique to use? as my interface only has a few buttons and text fields this would seem like a good idea for more modular contruction with my framework in other apps. More Panels will be added later referencing other data from the framework as it expands. comments appreciated Thanks Kieren Olearia - Talking Books on the Mac http://olearia.googlecode.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 [EMAIL PROTECTED]
Re: Separating elements in an NSView subclass
On Aug 8, 2008, at 8:54 AM, Graham Cox wrote: Are you checking the view's -needsToDrawRect: when you actually iterate through your rectangles? For a view like this it will be essential to avoid drawing anything that doesn't need drawing - even checking thousands of rects for intersection with the update area is much faster than actually drawing the same rects. And the flip-side of that is, are you ensuring that when an individual rectangle is moved or its contents changed, you just invalidate that rectangle and not the whole view? These two together should sort out your framerate problems - the screen shot is busy but it's not unreasonable - I wouldn't expect 1.2 fps even with this many rects as long as you are doing the two key things above. Dear Graham: Thank you for the reply. The way you worded the above kind of snapped me out of a "thinking too much" situation that I must have been in, because I scrapped my 2nd view idea and implemented the above and now I'm at 12 fps which is fantastic for my one user :) Throwing a backing layer at the problem isn't going to magically fix it if there's a basic problem with drawing too much. Ultimately it doesn't matter that everything is drawn in the same view. It might make sense to break it down just to keep the code sensible, but it won't automatically fix up drawing speed problems - after all, you're blitting into the same pixel buffer whoever draws them. Thanks for this too. I was under the mistaken impression that I had to make this separation in order to move forward. You mention a background view - is that really a separate view, or just a term you're using for your grid graphics? In my original design, it was just a term, but I was starting to split it into its own view due to my misunderstanding of what I had to do. Either way, if you decide to invalidate the whole view at any point you are going to stuff yourself. There's rarely a reason to ever invalidate a whole view (except for maybe the first time it's drawn, and that's handled by Cocoa, not you). The grid doesn't need to be repainted in its entirety for every change for example - again, just draw the little piece revealed by the update event. Doing that is actually less work for you to code than not doing it - when drawRect: is called it's already clipped to the update region, so just repaint the grid - pixels outside the clip region are not drawn so do not impose a drag on the drawing speed (cache the grid path also to avoid recalculating it every time). The key is never to call setNeedsDisplay:, but ALWAYS use setNeedsDisplayInRect:. Search your code for uses of -setNeedsDisplay: and change it. Perfect. Even though I had read the view guide several times, I didn't have it solidified in my mind that when you use - setNeedsDisplayInRect: that Quartz (if that is the correct term here) clips any drawing that occurs outside of the collection of dirty rects. Now I can see it in action. I am also testing each of my rects now to see if it is within the area needing drawing (I am using -needsToDrawRect:). All the rest of the elements I just go ahead and draw since they always drew very fast anyway. Incidentally, this looks like an ideal project to use my own DrawKit framework for, if you'll permit me the shameless plug. I just tried drawing about 460 small rects with text in them similar to yours and on my lowly MacBook 1st gen I get no framerate problems moving them around. Dragging a semi-transparent selection rect over them is a little stuttery, but usable. I also have a full-view grid behind everything (much more complex than yours too) so it's doable. I'm not doing any CALayer backing (incidentally on 10.4 you have CGLayer which provides similar functionality though much more basic). If you want to look at DrawKit, you can d/l it here: http://apptree.net/drawkitmain.htm . Even if you don't want to use the framework you may find the code worth a look to see how I draw stuff quickly without any tricky stuff. I have downloaded your framework and I am amazed at how much is in there and how neatly coded it looks! I think for this project it would take me too long to learn enough about your framework and to implement it into my (currently working) app. My user is going to be thrilled with 12fps and for that I am very thankful to you and the others who helped me before. ___ 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: Separating elements in an NSView subclass
Are you checking the view's -needsToDrawRect: when you actually iterate through your rectangles? For a view like this it will be essential to avoid drawing anything that doesn't need drawing - even checking thousands of rects for intersection with the update area is much faster than actually drawing the same rects. And the flip-side of that is, are you ensuring that when an individual rectangle is moved or its contents changed, you just invalidate that rectangle and not the whole view? These two together should sort out your framerate problems - the screen shot is busy but it's not unreasonable - I wouldn't expect 1.2 fps even with this many rects as long as you are doing the two key things above. Throwing a backing layer at the problem isn't going to magically fix it if there's a basic problem with drawing too much. Ultimately it doesn't matter that everything is drawn in the same view. It might make sense to break it down just to keep the code sensible, but it won't automatically fix up drawing speed problems - after all, you're blitting into the same pixel buffer whoever draws them. You mention a background view - is that really a separate view, or just a term you're using for your grid graphics? Either way, if you decide to invalidate the whole view at any point you are going to stuff yourself. There's rarely a reason to ever invalidate a whole view (except for maybe the first time it's drawn, and that's handled by Cocoa, not you). The grid doesn't need to be repainted in its entirety for every change for example - again, just draw the little piece revealed by the update event. Doing that is actually less work for you to code than not doing it - when drawRect: is called it's already clipped to the update region, so just repaint the grid - pixels outside the clip region are not drawn so do not impose a drag on the drawing speed (cache the grid path also to avoid recalculating it every time). The key is never to call setNeedsDisplay:, but ALWAYS use setNeedsDisplayInRect:. Search your code for uses of - setNeedsDisplay: and change it. Incidentally, this looks like an ideal project to use my own DrawKit framework for, if you'll permit me the shameless plug. I just tried drawing about 460 small rects with text in them similar to yours and on my lowly MacBook 1st gen I get no framerate problems moving them around. Dragging a semi-transparent selection rect over them is a little stuttery, but usable. I also have a full-view grid behind everything (much more complex than yours too) so it's doable. I'm not doing any CALayer backing (incidentally on 10.4 you have CGLayer which provides similar functionality though much more basic). If you want to look at DrawKit, you can d/l it here: http://apptree.net/ drawkitmain.htm. Even if you don't want to use the framework you may find the code worth a look to see how I draw stuff quickly without any tricky stuff. hth, Graham On 8 Aug 2008, at 10:14 pm, Paul Bruneau wrote: Hi- Some time ago I got some great advice to help me optimize the refresh rate of my NSView subclass (the answer is, just draw the minimum that you need to). So I am working to do this, but I am having some trouble with the inter-dependence of various elements that appear in my view. Here is the screenshot of it: http://special-lite.com/satellite/Schedule.pdf Currently, everything is a single NSView subclass that does too much (the docs refer to such a view as "monolithic" and I'm sure mine qualifies). I believe this is making it hard for me to draw the minimum. The elements consist of: - the order steps (all those colorful rectangles) - the list of workcenters on the left - the grid drawn behind the order steps (including the pink grid rectangles indicating "off-line" time) - The timeline along the bottom - lines that connect order steps to "sibling" order steps (you can see an example of this on the right side--when a particular order is selected, it is highlighted green with connecting lines) I have started by creating a new view that has the workcenters, the timeline, and the grid, and a second view with just the order steps on it. The problem that I think I have is that if the user moves an order step, it reveals some of the "background" view below it. This will then cause the background view to be redrawn, which, if I understand things, is going to force the "order step" view to be completely redrawn. This would not help me any, since I am redrawing everything on every update now. I think I have read enough about CALayer to think that it could help me with caching that it does, but I am writing for 10.4. I'm hopeful that I am missing something, or thinking about this incorrectly and that someone
Separating elements in an NSView subclass
Hi- Some time ago I got some great advice to help me optimize the refresh rate of my NSView subclass (the answer is, just draw the minimum that you need to). So I am working to do this, but I am having some trouble with the inter-dependence of various elements that appear in my view. Here is the screenshot of it: http://special-lite.com/satellite/Schedule.pdf Currently, everything is a single NSView subclass that does too much (the docs refer to such a view as "monolithic" and I'm sure mine qualifies). I believe this is making it hard for me to draw the minimum. The elements consist of: - the order steps (all those colorful rectangles) - the list of workcenters on the left - the grid drawn behind the order steps (including the pink grid rectangles indicating "off-line" time) - The timeline along the bottom - lines that connect order steps to "sibling" order steps (you can see an example of this on the right side--when a particular order is selected, it is highlighted green with connecting lines) I have started by creating a new view that has the workcenters, the timeline, and the grid, and a second view with just the order steps on it. The problem that I think I have is that if the user moves an order step, it reveals some of the "background" view below it. This will then cause the background view to be redrawn, which, if I understand things, is going to force the "order step" view to be completely redrawn. This would not help me any, since I am redrawing everything on every update now. I think I have read enough about CALayer to think that it could help me with caching that it does, but I am writing for 10.4. I'm hopeful that I am missing something, or thinking about this incorrectly and that someone can point me in the right direction. If you look in the lower left corner, you can see that with the increased number of orders we have during our busy season, I am down to an abysmal 1.2 fps. Thank you all for you help, past and future. ___ 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: Handling keyDown events results in beeping from a NSView subclass...
Excellent! Thanks Pete!
-graham
On May 24, 2008, at 9:56 PM, Peter Burtis wrote:
Add the method -(BOOL)acceptsFirstResponder { return YES; } in the
custom and it will work as desired. By default, just clicking on an
custom NSView *doesn't* make it the first responder, and keyboard
events are sent to the first responder and then up the responder
chain, unlike mouse events which are sent to the actual object
clicked.
-Pete
On May 24, 2008, at 10:37 PM, Graham Reitz wrote:
1) Create a simple Cocoa application
2) Open IB and drag a Custom View over to the Window
3) Name the Custom View class
4) Write the class files and add them to the project
5) Derive a class from NSView and implement the keyDown method.
- (void)keyDown:(NSEvent *)theEvent;
6) Run the program and hitting a key on the keyboard results in a
beep with no call to the key Down method.
What am I missing?
Mouse events come through without any issue.
thanks,
-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/pete%40glossysheep.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]
Re: Handling keyDown events results in beeping from a NSView subclass...
Add the method -(BOOL)acceptsFirstResponder { return YES; } in the
custom and it will work as desired. By default, just clicking on an
custom NSView *doesn't* make it the first responder, and keyboard
events are sent to the first responder and then up the responder
chain, unlike mouse events which are sent to the actual object clicked.
-Pete
On May 24, 2008, at 10:37 PM, Graham Reitz wrote:
1) Create a simple Cocoa application
2) Open IB and drag a Custom View over to the Window
3) Name the Custom View class
4) Write the class files and add them to the project
5) Derive a class from NSView and implement the keyDown method.
- (void)keyDown:(NSEvent *)theEvent;
6) Run the program and hitting a key on the keyboard results in a
beep with no call to the key Down method.
What am I missing?
Mouse events come through without any issue.
thanks,
-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/pete
%40glossysheep.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]
Handling keyDown events results in beeping from a NSView subclass...
1) Create a simple Cocoa application 2) Open IB and drag a Custom View over to the Window 3) Name the Custom View class 4) Write the class files and add them to the project 5) Derive a class from NSView and implement the keyDown method. - (void)keyDown:(NSEvent *)theEvent; 6) Run the program and hitting a key on the keyboard results in a beep with no call to the key Down method. What am I missing? Mouse events come through without any issue. thanks, -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 [EMAIL PROTECTED]
Getting selected object in NSView-subclass in NSCollectionView
Hi, when dragging an CD-Entity into a Window in InterfaceBuilder then IB automatically creates a CollectionView. This works fine but how do I get the selected Object in the ArrayController for a View? I tried subclassing the NSView and NSCollectionViewItem and put a IBOutlet for NSArrayController so that I could work with the selected Object, but unfortunately it doesn't work. How can I get the selected object? Thank you very much in advance. best regards, matthias ___ 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: drawRect: called twice for NSView subclass.
On Apr 19, 2008, at 6:28 PM, Scott Thompson wrote: On Apr 19, 2008, at 7:15 PM, William Hunt wrote: Essentially I have a window with a custom view atop a button. What happens at each refresh, however, is that the custom view's drawRect: is called twice. First it is called with the whole window's NSRect, then it is called with the "proper" NSRect. The result is that if I draw a circle at (0,0), it gets drawn twice at different locations: +--+ |++| || Custom || ||o View || |++| |o == | +--+ What is going on here? Is this buggy behavior or correct behavior? My code is basically a new Cocoa application with a single NSView subclass. There is absolutely nothing funny (that I know of) going on here. That leads me to believe that the behavior is "correct," and that I'm just missing something. For the record, I only want the one call to drawRect:, the one with the "proper" NSRect. It sounds like you've somehow ended up with the content rect of the window as an instance of your custom view class. How do you create your view hierarchy (i.e. in Interface Builder) or "by hand"? Scott Indeed, somehow the class for the content window got changed. Of course, that somehow was me making the change. Grr. Thanks again, Wil -- Wil Hunt "Life is the art of drawing sufficient conclusions from insufficient premises." -- Samuel Butler ___ 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: drawRect: called twice for NSView subclass.
On Apr 19, 2008, at 5:15 PM, William Hunt wrote: Essentially I have a window with a custom view atop a button. What happens at each refresh, however, is that the custom view's drawRect: is called twice. First it is called with the whole window's NSRect, then it is called with the "proper" NSRect. The result is that if I draw a circle at (0,0), it gets drawn twice at different locations: What is going on here? Is this buggy behavior or correct behavior? My code is basically a new Cocoa application with a single NSView subclass. There is absolutely nothing funny (that I know of) going on here. That leads me to believe that the behavior is "correct," and that I'm just missing something. For the record, I only want the one call to drawRect:, the one with the "proper" NSRect. FYI, the "proper" rect is not guaranteed to be the bounds rect of your view either. If Cocoa only needs you to refresh a subsection of your view, then you will get a -drawRect: with just that subsection. In general, you should only use the rect passed to you in -drawRect: as a guideline for what needs to be updated (i.e. for rejection tests) rather than to define the coordinate system to draw into. -- David Duncan Apple DTS Animation and Printing [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: drawRect: called twice for NSView subclass.
On Apr 19, 2008, at 7:15 PM, William Hunt wrote: Essentially I have a window with a custom view atop a button. What happens at each refresh, however, is that the custom view's drawRect: is called twice. First it is called with the whole window's NSRect, then it is called with the "proper" NSRect. The result is that if I draw a circle at (0,0), it gets drawn twice at different locations: +--+ |++| || Custom || ||o View || |++| |o == | +--+ What is going on here? Is this buggy behavior or correct behavior? My code is basically a new Cocoa application with a single NSView subclass. There is absolutely nothing funny (that I know of) going on here. That leads me to believe that the behavior is "correct," and that I'm just missing something. For the record, I only want the one call to drawRect:, the one with the "proper" NSRect. It sounds like you've somehow ended up with the content rect of the window as an instance of your custom view class. How do you create your view hierarchy (i.e. in Interface Builder) or "by hand"? Scott ___ 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]
drawRect: called twice for NSView subclass.
Ok, it's been a while since I've bugged you guys, so I thought I'd get back into the fold. Note that I'm very new to graphics programming in general, and even more so for Cocoa. So be prepared for an easy fix! Anyway, the problem I have is this. +--+ |++| || Custom || || View || |++| | == | +--+ (The graphic looks a little better if you switch to a fixed pitch font..) Essentially I have a window with a custom view atop a button. What happens at each refresh, however, is that the custom view's drawRect: is called twice. First it is called with the whole window's NSRect, then it is called with the "proper" NSRect. The result is that if I draw a circle at (0,0), it gets drawn twice at different locations: +--+ |++| || Custom || ||o View || |++| |o == | +--+ What is going on here? Is this buggy behavior or correct behavior? My code is basically a new Cocoa application with a single NSView subclass. There is absolutely nothing funny (that I know of) going on here. That leads me to believe that the behavior is "correct," and that I'm just missing something. For the record, I only want the one call to drawRect:, the one with the "proper" NSRect. Ideas? Wil -- Wil Hunt "Life is the art of drawing sufficient conclusions from insufficient premises." -- Samuel Butler ___ 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]
