macOS No More "keyDown" Event???

[GothicChess.Com]

I read this tech note which was authored on July 17, 2006:

http://developer.apple.com/qa/qa2005/qa1446.html

...wherein it states:


A modern Mac OS X application should not react to keyboard events but either to commands (when the Command key is down) or to high level Unicode text input, handling the kEventTextInputUnicodeForKeyEvent Carbon Event.

You should not care even if your application is older and still processes keyboard events the old-fashioned way handling the keyDown event.


OK, when did all of this happen ????

Is kEventTextInputUnicodeForKeyEvent superceding keyDown ???

 

[garethlewis2]

It depends on what you are coding in. If it is Cocoa, then you still use keyDownNSEvent *)input and as usual you use interpretKeyEvents to get the character representing the modifier plus keys. This technote is only if you are using Carbon, and you should not really be using Carbon unless you are unwilling to port your application to Cocoa. The only two companies react like that are Microsoft and Adobe.

 

[GothicChess.Com]

It depends on what you are coding in. If it is Cocoa, then you still use keyDownNSEvent *)input and as usual you use interpretKeyEvents to get the character representing the modifier plus keys. This technote is only if you are using Carbon, and you should not really be using Carbon unless you are unwilling to port your application to Cocoa. The only two companies react like that are Microsoft and Adobe.

If you were correct, I would agree with you.

There is a very large installed based using Carbon, not just Microsoft and Adobe.

 

[iMeowbot]

All of the old Event Manager stuff is marked "not recommended" these days, it's been that way for a while. They've been pushing Carbon Events as a replacement.

 

[GothicChess.Com]

All of the old Event Manager stuff is marked "not recommended" these days, it's been that way for a while. They've been pushing Carbon Events as a replacement.

I understand this, but I still see no source examples using the new stuff in the listings shown online. For example, no listing showing how to handle the new replacement of the old "keyDown" with kEventTextInputUnicodeForKeyEvent.

 

[garethlewis2]

Scroll down to the bottom of the technote. There is an entire function and shows to use it.

If there are a lot of developers still using Carbon, then good riddance to them. Apple have given them 7 years to move across to Cocoa.

 

[whooleytoo]

. Apple have given them 7 years to move across to Cocoa.

You're enjoying the (Carbon) Finder, I assume?

 

[wrldwzrd89]

You're enjoying the (Carbon) Finder, I assume?

Not to mention that huge parts of Cocoa draw upon Carbon to work internally...

 

[MongoTheGeek]

Scroll down to the bottom of the technote. There is an entire function and shows to use it.

If there are a lot of developers still using Carbon, then good riddance to them. Apple have given them 7 years to move across to Cocoa.

Actually as of WWDC last year Carbon was full partner with Cocoa. Not quite this year though. In the HIToolbox session the atmosphere was rather lynch mobbish. Carbon will be around and supported for a few years and apps I am sure will continue to run for a long time

 

[garethlewis2]

Cocoa doesn't use any libs from Carbon. Your getting confused with CoreFoundation. Which Carbon and Cocoa both use.

Finder is a piece of shi*. Everybody hates it. I actually PathFinder.

 

[gnasher729]

It depends on what you are coding in. If it is Cocoa, then you still use keyDownNSEvent *)input and as usual you use interpretKeyEvents to get the character representing the modifier plus keys. This technote is only if you are using Carbon, and you should not really be using Carbon unless you are unwilling to port your application to Cocoa. The only two companies react like that are Microsoft and Adobe.

And a few hundred others. BTW I have been told by my boss that our application will stay 32 bit for the next few years. I wonder why that is. (Well, I know why. It is because I told him that switching to Cocoa would be an awful amount of work, would require a complete test cycle, and wouldn't give us or our customers any measurable benefit).

 

[wrldwzrd89]

Cocoa doesn't use any libs from Carbon. Your getting confused with CoreFoundation. Which Carbon and Cocoa both use.

Finder is a piece of shi*. Everybody hates it. I actually PathFinder.

Oh, thanks. I didn't know that about CoreFoundation.

As for the Finder... who says everybody hates it? I, for one, don't "hate" it per se, though I do find some of its quirks irritating. I do believe that Apple fixed my biggest gripe with the Finder in Leopard, though - that being the beachball of death when a network share suddenly becomes unavailable.

 

[gnasher729]

Scroll down to the bottom of the technote. There is an entire function and shows to use it.

If there are a lot of developers still using Carbon, then good riddance to them. Apple have given them 7 years to move across to Cocoa.

I haven't received any offers from Apple compensating us for the time and effort that moving to Cocoa would cost us, and I don't think any other developers have. From my point of view, if you want my code to come in 64 bit, then better ask Apple to get going with 64 bit Carbon.

 

[gnasher729]

I read this tech note which was authored on July 17, 2006:

http://developer.apple.com/qa/qa2005/qa1446.html

...wherein it states:


A modern Mac OS X application should not react to keyboard events but either to commands (when the Command key is down) or to high level Unicode text input, handling the kEventTextInputUnicodeForKeyEvent Carbon Event.

You should not care even if your application is older and still processes keyboard events the old-fashioned way handling the keyDown event.


OK, when did all of this happen ????

Is kEventTextInputUnicodeForKeyEvent superceding keyDown ???

It happened long, long time ago.

You should only handle key down events if you are actually interested in the fact that the user pressed a key. For example, if you have a video game that can be controlled through mouse and keyboard.

If you are interested in the actual text that is entered, you should use the new events like kEventTextInputUnicodeForKeyEvent. They will work for example if the user is using a Japanese input method, entering characters in Romanji which are then translated into proper Japanese characters. Your application will not get all the dozens of key presses that are completely irrelevant, but only the actual Japanese characters that you want.

 

[Krevnik]

Cocoa doesn't use any libs from Carbon. Your getting confused with CoreFoundation. Which Carbon and Cocoa both use.

Finder is a piece of shi*. Everybody hates it. I actually PathFinder.

Cocoa does leverage a couple pieces of Carbon beyond CoreFoundation, but tries not to. (At least according to the Apple dev on the bit 64-bit Carbon discussion rampaging about Apple's mailing lists)

Honestly though, I would rather use the Finder than PathFinder. PathFinder's UI does not help me get work done, and shoves way too much functionality into a single window by default. It has a couple really nice features, but beyond that, it is a power-user's dungeon toy. Powerful, but with a serious lack of finesse or ease that makes it user-friendly for the masses. (And remember, we aren't everybody, we may hate the Finder, but we are not the masses)