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 stat
> 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 accid
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
> 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 ne
ange.
>
> 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
e 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
> 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
> th
> 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
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
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 fo
> 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
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 set
st 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
>
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
:
> [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
ts 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 cod
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
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
itGame 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 lo
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 m
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
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 t
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
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 s
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
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 ca
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
di
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 a
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 po
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 N
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
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
t 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
&g
gt;>
>>>> @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
t;> }
>>>
>>> @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 respon
ering 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
y 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
oolbar 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&
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
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 signa
n:.
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
>&g
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
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
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
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 Int
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 int
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.
Whe
iew?
>
> 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 o
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
__
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 subcla
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 supp
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 c
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...
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 __
er 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];
>
ime. 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];
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
I
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 perfo
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, a
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:
[NS
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
008, 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 contr
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
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
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 wi
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
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
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
eve
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 even
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 prog
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 NSArrayCon
---+|
|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 &qu
he "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 n
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
+
|++|
|| 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
75 matches
Mail list logo
