Re: Sudden and hard to reproduce crashes in libcache

[Dragan Milić]

Just an update on this issue:

On čet 23.02.2012., at 20.00, Greg Parker wrote:

> Yep, that's CFRelease(NULL), plus ExceptionHandling.framework catching the 
> Unix signal and trying to turn it into an Objective-C exception.
> 
> That background thread is part of NSCache. This could be a bug in your use of 
> NSCache, a memory smasher somewhere, or a bug in NSCache itself. 
> 
> You may be able to reproduce this by forcing the app into a low memory 
> situation. That background thread is evicting NSCache contents in responds to 
> low memory. Once you can reproduce, you should try zombies and guard malloc.

Apparently, it's a bug in NSCache. On http://files.me.com/milke/t5ufx5 can you 
find a super simple sample app to reproduce it every time without any problem. 
It looks like -[NSString stringWithFormat:] (and possibly other calls) can 
return the same pointer rather than creating new object every call.  Perhaps 
it's trying to reuse strings to save memory?  NSCache seems not to like that 
and crashes. If I wrap the strings in a simple holder object, which has nothing 
more than a string as it's content ivar, that solves the crashing problem. But 
it's still completely incorrect behaviour on NSCache part.

I think this makes NSCache (at the moment) almost unusable in real world 
applications, because you never now whether and when it's going to crash. Maybe 
never, maybe immediately. I encourage everyone (especially those using NSCache) 
to file a bug report to Apple. If they get a lot of duplicates on the same 
issue, they may hopefully do something quicker. NSCache was introduced for 
object caching and memory saving and having to wrap every cached object in a 
holder object defies cache's purpose (kind of).

-- Dragan
___

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

NSMatrix, NSForm - addRow - why above and not below?

[Grandinetti Philip]

I'm running into a strange behavior with NSForm (and also NSMatrix).

(1) Using interface builder (in Xcode 4.3.1) I place an NSForm in a window. I 
add a NSButton and wire it to an IBAction that sends addRow to the NSForm.

- (IBAction) addRow:(id)sender
{
[form addRow];
   [form sizeToCells];
}

The problem is that the new row is added ABOVE the existing row, not below as 
it's supposed to. I thought this was a problem coming from somewhere else in my 
app, but I created a new project in Xcode and this happens even in the simplest 
app.

I must be doing something stupid wrong, but I can't find it. Any suggestions 
would be appreciated.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSMatrix, NSForm - addRow - why above and not below?

[Keary Suska]

On Mar 13, 2012, at 8:55 AM, Grandinetti Philip wrote:

> I'm running into a strange behavior with NSForm (and also NSMatrix).
> 
> (1) Using interface builder (in Xcode 4.3.1) I place an NSForm in a window. I 
> add a NSButton and wire it to an IBAction that sends addRow to the NSForm.
> 
> - (IBAction) addRow:(id)sender
> {
>[form addRow];
>   [form sizeToCells];
> }
> 
> The problem is that the new row is added ABOVE the existing row, not below as 
> it's supposed to. I thought this was a problem coming from somewhere else in 
> my app, but I created a new project in Xcode and this happens even in the 
> simplest app.
> 
> I must be doing something stupid wrong, but I can't find it. Any suggestions 
> would be appreciated.


It is a bit deceptive, but the problem is not what you think. The row is in 
fact added at the bottom, but when the view is resized it is sized from the 
bottom left corner, instead of the top left, which is intuitive for humanity 
but not apparently for the founders of Cocoa.

To get the behavior you expect you need to either flip the coordinate system of 
the enclosing view or move the view back as such:

- (IBAction) addRow:(id)sender
{
  NSRect originalFrame = [form frame];
  [form addRow];
  [form sizeToCells];
  NSRect newFrame = [form frame];
  CGFloat delta = newFrame.size.height - originalFrame.size.height;
  newFrame.origin.y -= delta;
  [form setFrame:newFrame];
}

Note that -sizeToCells does not cause the view to be redrawn, so you will get 
drawing artifacts. You may use -selectTextAtIndex: to set focus on the new form 
field, which will avoid the drawing issues (maybe a little more functional than 
just calling -setNeedsDisplay:).

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: NSMatrix, NSForm - addRow - why above and not below?

[Fritz Anderson]

On 13 Mar 2012, at 12:49 PM, Keary Suska wrote:

> It is a bit deceptive, but the problem is not what you think. The row is in 
> fact added at the bottom, but when the view is resized it is sized from the 
> bottom left corner, instead of the top left, which is intuitive for humanity 
> but not apparently for the founders of Cocoa.

It's intuitive if your graphical model is built on Display Postscript, which in 
turn is built on mathematical Cartesian coordinates.

Not that I'm not grateful for the top-left system in UIKit.

— F


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSMatrix, NSForm - addRow - why above and not below?

[Grandinetti Philip]

Thanks Keary,

It all makes sense.Deceptive is the word "below" in the reference guide, 
which I usually interpret using the direction of gravity.

Philip


On Mar 13, 2012, at 1:49 PM, Keary Suska wrote:

> On Mar 13, 2012, at 8:55 AM, Grandinetti Philip wrote:
> 
>> I'm running into a strange behavior with NSForm (and also NSMatrix).
>> 
>> (1) Using interface builder (in Xcode 4.3.1) I place an NSForm in a window. 
>> I add a NSButton and wire it to an IBAction that sends addRow to the NSForm.
>> 
>> - (IBAction) addRow:(id)sender
>> {
>>   [form addRow];
>>  [form sizeToCells];
>> }
>> 
>> The problem is that the new row is added ABOVE the existing row, not below 
>> as it's supposed to. I thought this was a problem coming from somewhere else 
>> in my app, but I created a new project in Xcode and this happens even in the 
>> simplest app.
>> 
>> I must be doing something stupid wrong, but I can't find it. Any suggestions 
>> would be appreciated.
> 
> 
> It is a bit deceptive, but the problem is not what you think. The row is in 
> fact added at the bottom, but when the view is resized it is sized from the 
> bottom left corner, instead of the top left, which is intuitive for humanity 
> but not apparently for the founders of Cocoa.
> 
> To get the behavior you expect you need to either flip the coordinate system 
> of the enclosing view or move the view back as such:
> 
> - (IBAction) addRow:(id)sender
> {
>  NSRect originalFrame = [form frame];
>  [form addRow];
>  [form sizeToCells];
>  NSRect newFrame = [form frame];
>  CGFloat delta = newFrame.size.height - originalFrame.size.height;
>  newFrame.origin.y -= delta;
>  [form setFrame:newFrame];
> }
> 
> Note that -sizeToCells does not cause the view to be redrawn, so you will get 
> drawing artifacts. You may use -selectTextAtIndex: to set focus on the new 
> form field, which will avoid the drawing issues (maybe a little more 
> functional than just calling -setNeedsDisplay:).
> 
> HTH,
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 


___

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

Undomanager for custom object?

[Luc Van Bogaert]

Hi,

In my document-based app, I am using NSDocument's NSUndoManager to implement 
undo/redo. As part of my document objects, I have to deal with a custom object, 
for which I would also like to implement undo/redo. I know NSResponder has 
undo/redo features, but how should I implement this for a custom object?

Thanks,

-- 
Luc Van Bogaert




___

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: Undomanager for custom object?

[Kyle Sluder]

On Mar 13, 2012, at 1:49 PM, Luc Van Bogaert wrote:

> Hi,
> 
> In my document-based app, I am using NSDocument's NSUndoManager to implement 
> undo/redo. As part of my document objects, I have to deal with a custom 
> object, for which I would also like to implement undo/redo. I know 
> NSResponder has undo/redo features, but how should I implement this for a 
> custom object?

Not sure what you're asking here. What is your custom object--a view, a 
controller, a model object? Should it use the same undo manager as all the 
other objects?

--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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[Q] Why is the threading and UI updating designed to be done only on a main thread?

[JongAm Park]

Hello,

While doing projects with Cocoa and Objective-C, I have always thought 
that allowing UI update only on main thread was a weak point of 
Cocoa/Objective-C.
Especially, when gracefully terminating threads which would be better 
update some UI stuff and if main thread is required to wait until those 
threads finishes for clean exit, it can cause dead lock condition.
In other words, the thread function may want to update UI like inserting 
a log message to a text field on a window and thus asking main thread to 
do so, and main thread is waiting to acquire a lock or waiting using 
"Join", then either the main thread and the other thread can't progress.


But, I also noticed the same pattern with C# .NET. Unlike Win32/MFC and 
like Objective-C/Cocoa, it also asks a main thread to update UI widgets.


Is there any reason to design threading and UI update model like this?
At first I thought it was due to somehow Obj-C/Cocoa sticks to some old 
model, but C# .NET is fairly new architecture. They could have avoided 
it if doing so was better. So, I guess there must be some reason behind it.


Can anyone explain the rationale behind it?
Also, is there a way to gracefully terminate an app by quitting threads 
and main thread?


Thanks,
JongAm Park
___

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: Undomanager for custom object?

[Seth Willits]

On Mar 13, 2012, at 1:49 PM, Luc Van Bogaert wrote:

> In my document-based app, I am using NSDocument's NSUndoManager to implement 
> undo/redo. As part of my document objects, I have to deal with a custom 
> object, for which I would also like to implement undo/redo. I know 
> NSResponder has undo/redo features, but how should I implement this for a 
> custom object?

It's covered pretty well in the documentation.

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/UndoArchitecture/UndoArchitecture.html#//apple_ref/doc/uid/1010i


--
Seth Willits


___

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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Jens Alfke]

On Mar 13, 2012, at 2:09 PM, JongAm Park wrote:

> Is there any reason to design threading and UI update model like this?

Yes. Parallel computing with shared state is extremely hard. So hard that I 
don’t think it’s even well-understood yet, in particular how one can properly 
test such a system. (See the classic paper “The Problem With Threads”*.)

Back in 1998-2000 I was tech lead for Java frameworks at Apple, which mostly 
involved getting AWT and Swing to run well on Mac OS. It was a very painful 
task, and one of the biggest problems was thread-safety. Code that started out 
clean, readable and maintainable turned into a mess once we’d gone through and 
fixed a seemingly-endless series of deadlock and race-condition bugs. 
Performance suffered because of all the lock contention. I was very happy to 
put that problem behind me forever and turn to Cocoa.

Parallel processing is of course getting more and more important, but I think 
the old approach of “let’s spawn lots of threads and have all of them try to 
access everything at once” is dead. Systems that limit the use of shared state, 
like the “actor” model used by Erlang and Scala, seem pretty promising. GCD and 
blocks make it easier to implement that kind of code.

So my contention, based on my experience, is that if you have a design where a 
lot of threads find themselves wanting to access the UI, you should think about 
redesigning your architecture.

—Jens

* http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
___

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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Stephen J. Butler]

On Tue, Mar 13, 2012 at 4:09 PM, JongAm Park  wrote:
> In other words, the thread function may want to update UI like inserting a
> log message to a text field on a window and thus asking main thread to do
> so, and main thread is waiting to acquire a lock or waiting using "Join",
> then either the main thread and the other thread can't progress.

You should really be rethinking your design if your main thread is
waiting on long held locks or waiting for threads to join. There are
ways around this, and the main thread shouldn't block long at all.
___

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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Brian Lambert]

The short answer is that:

1) Given our current languages and tools, parallel programming is hard.
2) For the moment, it is generally the case that one thread is enough to
keep a UI updated and responding to events, thus avoiding #1.
3) When one thread isn't enough to keep a UI updated and responding to
events, other threads can be used, and then the output of those threads can
be fed to the UI thread.

On Tue, Mar 13, 2012 at 2:09 PM, JongAm Park wrote:

> Hello,
>
> While doing projects with Cocoa and Objective-C, I have always thought
> that allowing UI update only on main thread was a weak point of
> Cocoa/Objective-C.
> Especially, when gracefully terminating threads which would be better
> update some UI stuff and if main thread is required to wait until those
> threads finishes for clean exit, it can cause dead lock condition.
> In other words, the thread function may want to update UI like inserting a
> log message to a text field on a window and thus asking main thread to do
> so, and main thread is waiting to acquire a lock or waiting using "Join",
> then either the main thread and the other thread can't progress.
>
> But, I also noticed the same pattern with C# .NET. Unlike Win32/MFC and
> like Objective-C/Cocoa, it also asks a main thread to update UI widgets.
>
> Is there any reason to design threading and UI update model like this?
> At first I thought it was due to somehow Obj-C/Cocoa sticks to some old
> model, but C# .NET is fairly new architecture. They could have avoided it
> if doing so was better. So, I guess there must be some reason behind it.
>
> Can anyone explain the rationale behind it?
> Also, is there a way to gracefully terminate an app by quitting threads
> and main thread?
>
> Thanks,
> JongAm Park
> __**_
>
> 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/**
> brianlambert%40gmail.com
>
> This email sent to brianlamb...@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

NSTextField not consuming keyDown events; How do I prevent super view from receiving those events?

[Eric Wing]

I have a very simple custom view where I override keyDown: and keyUp:.

I just put an NSTextField on top of my custom view in Interface
Builder (subview of my custom view). When I type in the text field (it
has focus), I noticed that my custom view is picking up all the
keyEvents. I wasn't expecting that and was expecting the text field to
consume all the key events since it is already processing them to add
to the field.

Is there a way to get the text field (and any other widgets that might
do this like NSTextView) to consume the events they process so my
custom view doesn't receive them?


Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
___

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: NSTextField not consuming keyDown events; How do I prevent super view from receiving those events?

[jonat...@mugginsoft.com]

On 13 Mar 2012, at 22:50, Eric Wing wrote:

> I have a very simple custom view where I override keyDown: and keyUp:.
> 
> 
> Is there a way to get the text field (and any other widgets that might
> do this like NSTextView) to consume the events they process so my
> custom view doesn't receive them?

Are you sure you aren't accidentally passing the event on up the responder 
chain?

- (void)keyDown:(NSEvent *)theEvent {

// consume event
if ([theEvent modifierFlags] & NSNumericPadKeyMask) {
[self processtEvent:theEvent];
} 

// pass on up the responder chain
[super keyDown:theEvent];
   
}


Regards

Jonathan Mitchell
Mugginsoft LLP


___

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

NSDrawTiledRects Only Draws One Side

[Chris Tracewell]

Using XCode 3.2.6, OSX 10.6.8 - GC is on


I have three rects I am trying to stroke on all four sides using 
NSDrawTiledRects however only the first side listed in my NSRectEdge list gets 
drawn. I'm using the boundsRect as the clippingRect but that shouldn't should 
it? I did experiment with insetting the bounds rect 10 points as you can see 
bleow just in case it was getting clipped but it makes no diff.

NSRectEdge theSides[] = {NSMinXEdge,NSMaxXEdge,NSMinYEdge,NSMaxYEdge};
CGFloat theGrays[] = {NSBlack,NSBlack,NSBlack,NSBlack};

NSDrawTiledRects(NSInsetRect(theVendorTextRect,10,10), theVendorTextRect, 
theSides, theGrays, 1);
NSDrawTiledRects(theBillToTextRect, theBillToTextRect, theSides, theGrays, 1);
NSDrawTiledRects(theShipToTextRect, theShipToTextRect, theSides, theGrays, 1);

Anyone have any suggestions?


--Chris
___

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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Jay Reynolds Freeman]

Notwithstanding the good advice about parallel programming given earlier in 
this thread, there are still possible problems.  By way of illustration, a year 
or two ago I submitted a bug report (#8338166) about a problem of this sort in 
iOS.  I will describe the problem here.  (I am not looking for a workaround, I 
have one -- here I am just providing a real example from the past that may be 
of interest.)

Consider UIApplicationDelegate method "applicationWillTerminate:":  
Multithreaded applications may not be able to use it to shut down, because of 
the possibility of deadlock in communications between the main thread and other 
application threads.

Suppose we have a multithreaded iOS application whose non-main threads 
occasionally use "performSelectorOnMainThread:withObject:waitUntilDone:" to 
interact with the main thread.  Now suppose the following things happen, in 
this order:

1) "applicationWillTerminate:" is called (by the OS, on the main thread).

2) Immediately thereafter, before "applicationWillTerminate" has completed, 
some other thread calls 
"performSelectorOnMainThread:withObject:waitUntilDone:", with 
"waitUntilDone:"'s value set to YES.

3) Suppose the application needs to get the other thread to do some shut-down 
work -- the kind of thing that is supposed to happen in 
"applicationWillTerminate:"

4) We now have a problem with deadlock.  The application *cannot* communicate 
with the other thread from inside "applicationWillTerminate:", because the 
other thread is waiting for "performSelector ..." to run, and that won't happen 
until "applicationWillTerminate:" has itself returned.  And if the application 
posts an event to the other thread and then returns from 
"applicationWillTerminate:", it is highly likely that the OS will terminate the 
application before the other thread has had a chance to act.  So there is no 
reliable way to get the other thread to do its cleanup.

The point here is that since "applicationWillTerminate:" is called 
asynchronously from the point of view of the app, the app can *NEVER* 
communicate with any thread that may have to do clean-up work, by any 
communication protocol that requires the other thread to wait for the main 
thread to do something, for fear of a deadlock such as I have just described.  
That is a substantial restriction.  

There are certainly other ways to do an iOS app shutdown, but this case 
illustrates the kind of deadlock that can happen if you do not think carefully 
about how things interact. The original intended use of 
"applicationWillTerminate:" is indeed a setup for deadlock to happen.

One should be on the lookout for similar situations with other iOS or MacOS 
methods.

--  Jay Reynolds Freeman
-
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)

___

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: NSTextField not consuming keyDown events; How do I prevent super view from receiving those events?

[Eric Wing]

On 3/13/12, jonat...@mugginsoft.com  wrote:
>
> On 13 Mar 2012, at 22:50, Eric Wing wrote:
>
>> I have a very simple custom view where I override keyDown: and keyUp:.
>>
>>
>> Is there a way to get the text field (and any other widgets that might
>> do this like NSTextView) to consume the events they process so my
>> custom view doesn't receive them?
>
> Are you sure you aren't accidentally passing the event on up the responder
> chain?
>
> - (void)keyDown:(NSEvent *)theEvent {
>
> // consume event
> if ([theEvent modifierFlags] & NSNumericPadKeyMask) {
> [self processtEvent:theEvent];
> }
>
> // pass on up the responder chain
> [super keyDown:theEvent];
>
> }
>
>
> Regards
>
> Jonathan Mitchell
> Mugginsoft LLP
>

I am not calling [super keyDown:event] in my custom subclass. But the
problem is that it is the NSTextField that is passing the event to my
class, not the other way around. I did not subclass NSTextField (nor
do I really want to).

So I found a few solutions, but I'm hoping for something a little
better, or perhaps assurance that this is a legitimate solution and I
won't totally break things in some other way. (I'm wondering what the
use case is for NSTextField not consuming the events.)

- Put the text field inside another custom view that consumes the
events before it reaches my real custom view.

- Create a new responder that eats events and set the nextResponder of
the NSTextField to this responder object.

- Track the becomesFirstResponder and resignFirstResponder in my
custom view and disregard all events that come it when it is NOT the
firstResponder.


An aside, I'm wondering if this NSTextField not consuming key events
is a potentional security risk. For fun, I tried using an
NSSecureTextField the same way and my custom view is receiving the
echo of all the key strokes. I know Apple does things to fortify
NSSecureTextField from external examination for security. However, I
wonder if some kind of injection attack could be made on the superview
hosting the text field. Simply doing the equivalent of setting a
category on the super view for keyDown and inspecting the results. (I
don't really know what I'm talking about so don't take me too
seriously. I have no idea how to attack an app. It's just an
observation.)

Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
___

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: NSDrawTiledRects Only Draws One Side

[Jens Alfke]

On Mar 13, 2012, at 4:33 PM, Chris Tracewell wrote:

> NSDrawTiledRects(NSInsetRect(theVendorTextRect,10,10), theVendorTextRect, 
> theSides, theGrays, 1);
> NSDrawTiledRects(theBillToTextRect, theBillToTextRect, theSides, theGrays, 1);
> NSDrawTiledRects(theShipToTextRect, theShipToTextRect, theSides, theGrays, 1);

The last parameter is 1, so you’re only telling it to draw one edge. It looks 
like you meant to specify 4. (The count parameter should match the sizes of the 
arrays you pass for sides and grays.)

—Jens
___

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: String Constants the solution

[William Squires]

I just do a #define in the header like

#define kDictionayKey1 @"key1"
#define kDictionaryKey2 @"key2"

then use it somewhere in the .m file

foo = [myDic objectForKey:kDictionaryKey1];

and so on...

On Mar 8, 2012, at 6:29 PM, Prime Coderama wrote:

> I have references to 'ground' and 'air' in multiple files. It is usually used 
> in this context, but not always.
>>  if ([transport.type isEqualToString:@"ground"]) {
>>// do something for automobiles
>>  }
>>  else if ([transport.type isEqualToString:@"air"]) {
>>// do something else for planes
>>  }
>>  else {
>>// we don't care
>>  }
> 
> Should I be using string constants to represent 'ground' and 'air' so if I 
> ever change their literal, I just update it in one place? e.g.
>>  NSString * const TransportGround = @"ground";
>>  NSString * const TransportAir = @"air";
> 
> I then decide I want to rename 'ground' to be 'wheels', then I would only 
> update the above string constant.
> ___
> 
> 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/wsquires%40satx.rr.com
> 
> This email sent to wsqui...@satx.rr.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

Memory, Swap used by whom?

[Gerriet M. Denkmann]

Is there a Cocoa method which gives me to any (physical) memory address the 
status - like "used by process a" or: "shared by processes a, b, ..., z" or 
"free"?

And also I would like to know, which processes have things swapped out.

If there is no Cocoa way, any C-Api would be welcome as well.

Or, if this is altogether off-topic for Cocoa: what other list would be more 
appropriate?


Kind regards,

Gerriet.


___

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