Re: WM_KEYDOWN
Re: WM_KEYDOWN
- Subject: Re: WM_KEYDOWN
- From: Alastair Houghton <email@hidden>
- Date: Thu, 12 Apr 2007 11:31:10 +0100
On 12 Apr 2007, at 09:14, Uli Kusterer wrote:
Am 11.04.2007 um 21:56 schrieb xcocoa:
So you're trying to implement a programming language on the Mac?
Which one? Give us some hints as to the high-level thing you're
trying to achieve.
Its already implemented. We are on pre-release status.
Sorry we can't provide more details. We will submit a demo version
to Apple software once its at RC stage.
Please tell us what company you work for. I want to make sure I
don't accidentally buy from you.
This is all getting a bit immature. I do share the frustration of
some of the others, but even though the silly behaviour was arguably
initiated by "Smith", I'm inclined to think we should rise above it.
"Smith", I'm sure you think that a lot of the people who have tried
to help you are being obtuse, but you must understand that Mac OS X
*is not* Windows, so trying to go about something in the same way you
would on Windows often won't achieve the results you want.
Actually, even on Windows, the situation isn't as straightforward as
people sometimes make out (e.g. you may need to handle additional
messages besides WM_KEYDOWN, and you may need to write (or alter)
your application's message dispatch loop to avoid problems caused by
TranslateMessage(); that can be complicated, especially if you're
using an application framework as they commonly have heavily
customised message dispatch loops already).
That said, there are a number of solutions to your problem depending
on what you're trying to achieve; you can:
1. Write an NSFormatter.
2. Subclass NSTextView and create a variant that has custom
processing for -keyDown:, then in your NSWindow delegate, implement -
windowWillReturnFieldEditor:toObject: to return your custom field
editor. (You could instead subclass NSWindow and override -
fieldEditor:forObject:, though generally speaking it's better to use
delegation unless you need to subclass for some other reason.)
3. As above, but instead of implementing -keyDown:, implement some of
the NSTextInput methods instead.
4. Create your own custom text field by subclassing NSView and
implementing NSTextInput for your custom view.
5. Observe the -controlTextDidChange: notification from the field in
question.
6. Subclass NSApplication and override -sendEvent: to process the key
events you're looking for.
7. Use the IOKit's HID functionality to obtain raw keyboard events.
8. Write your application using Carbon instead (Carbon is much closer
in design to the Win32 API, which might make porting easier if you're
trying to achieve a similar application structure).
There are probably some other approaches as well that I haven't
thought of right now, but perhaps the fact that I can come up with
eight different ideas off the top of my head (some of which were
mentioned previously by others) helps you to understand why the
people trying to help you were asking for more information.
The problem is that because none of us know quite what you're trying
to achieve (i.e. what this functionality will typically be used for,
if you're talking about a programming language), it's hard to give
specific advice. All of these different methods have their uses; my
guess is that you probably want #1, since usually people asking about
key events are actually after controlling what the user can or cannot
enter into an editable field (and the equivalent, functionality-wise,
on Cocoa, is an NSFormatter subclass; it doesn't work the same way at
all, however). But #6 and #7 (and maybe #8) are closest to the
question you asked; it's just that they probably aren't the right
solution to the problem you're trying to solve.
One thing I will encourage you to check is that your code works
properly when you: (a) cut, copy and paste text to and from your text
field, and (b) drag and drop text into your text field. It would
also be a good plan to find someone who speaks a language like
Chinese or Japanese for which there is an IME, and ask them to try
using it. It's very easy to make assumptions that break one or more
of these cases.
Oh, and as for Windows... if you're only handling WM_KEYDOWN, then I
think you'll probably find that there are some bugs there too (e.g.
try copy & paste and drag & drop in Windows too; depending on your
assumptions, other things could be broken also, e.g. CJK input or
input of accented characters using dead keys, which is very common on
European keyboards).
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden