windows message pump equivalent?
vinny
I am looking to develop an application in Cocoa using Xcode that is
based on an existing app I have written for Windows. The Win32 app uses
a WindowProc() method to process the incoming windows messages from a
USB HID device (using custom Windows messages). I would like to know
how something similar would be implemented using Cocoa? Also, if any
sample code or tutorials could be provided, it'd be greatly
appreciated.
Thanks,
Vinny.
Michael Ash
I think you'll need to explain more about what you're trying to do.
"Equivalent" questions are worthless without an explanation of what is
desired, because the people you're asking probably don't know what the
original is. I personally haven't the slightest clue what a "Windows
message pump" would be.
From the bits I do understand it sounds to me like you want to communicate
with a USB device, is that all you're really after?
--
Michael Ash
Rogue Amoeba Software
vinny
> "Equivalent" questions are worthless without an explanation of what is
> desired, because the people you're asking probably don't know what the
> original is. I personally haven't the slightest clue what a "Windows
> message pump" would be.
From: http://en.wikipedia.org/wiki/Event_loop
"The Microsoft Windows operating system requires user-interactive
processes that wish to run on the operating system to construct a
message loop for responding to events. In this operating system, a
message is equated to an event created and imposed upon the operating
system. An event can range from user interaction, network traffic,
system processing, timer activity, and interprocess communication among
others.
The "heart" of most Win32 applications is the WinMain function, which
calls GetMessage(), in a loop. GetMessage blocks until a message, or
"event", is received. After some optional processing, it will call
DispatchMessage(), which dispatches the message to the relevant
handler, also known as WindowProc. Normally, messages that have no
special WindowProc are dispatched to DefWindowProc, the default one.
DispatchMessage calls the window-proc of the HWND handle of the message
(Registered with the RegisterClass function)."
I wish to handle certain events which occur when a key is pressed on
the USB device. For example, a keypress (on the USB device) under
Windows will send WM_HID_KEY_DOWN and WM_HID_KEY_UP messages to the
WindowProc handler. Once these messages have been detected (using a
switch case statement on the incoming message), it is possible to
perform some action (such as display notification of a keypress).
Example:
WindowProc(UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case MESSAGE 1:
...
break;
case MESSAGE 2:
...
break;
}
}
> From the bits I do understand it sounds to me like you want to communicate
> with a USB device, is that all you're really after?
Not quite, the message pump could also deal with messages being sent
from other applications, as well as the OS itself (program termination
messages, shutdown messages, etc).
Patrick Machielse
> I wish to handle certain events which occur when a key is pressed on
> the USB device. For example, a keypress (on the USB device) under
> Windows will send WM_HID_KEY_DOWN and WM_HID_KEY_UP messages to the
> WindowProc handler. Once these messages have been detected (using a
> switch case statement on the incoming message), it is possible to
> perform some action (such as display notification of a keypress).
If your device is recognized by Mac OS as a keyboard, your application
will automatically receive NSEvents through -[NSWindow sendEvent:] or
-[NSApplication sendEvent:]. Override these to do what you want them to
do. You'll want to read up on the Cocoa 'responder chain'.
This works only when your app is the actve application. If you want to
receive keyboard events in the background, you could register a hotkey,
but you must use Carbon functions.
> > From the bits I do understand it sounds to me like you want to communicate
> > with a USB device, is that all you're really after?
>
> Not quite, the message pump could also deal with messages being sent
> from other applications, as well as the OS itself (program termination
> messages, shutdown messages, etc).
Inter-application communication for tasks like these works with
'notifications'. Consult the documentation on NSNotificationCenter and
NSDistributedNotificationCenter.
patrick
vinny
If anyone else has any other comments / help to add, I'd really
appreciate it.
Thanks,
Vinny.
Chris Hanson
> Thanks, Patrick. I will check these out.
>
> If anyone else has any other comments / help to add, I'd really
> appreciate it.
I have a comment to add, and I hope you will not take offense with it:
Mac OS X is not Windows, and Cocoa is not Win32.
Your messages in this thread have presumed that Win32 is somehow
"definitive" in its behavior and that Cocoa must be implemented in the
same fashion. Neither of the above is the case. In particular, the
Windows "message pump" model is not at all how Macintosh applications
work whether they are written against the Carbon or Cocoa frameworks.
Both Carbon and Cocoa applications will run an event loop, but this is
not exactly equivalent to how Win32 works; Win32 posts many more kinds
of messages to its event loop than either Mac OS X framework does. For
example, file handle notifications, communication with I/O devices,
etc. are all handled through different mechanisms than the application
event loop, whereas they (may) all use the same "message pump" in Win32.
Your best bet for getting help in developing Mac OS X applications is
to always phrase your requests in terms of the goal you wish to
accomplish, rather than the implementation you think you need. After
all, the implementation that is best may be radically different than
the one you are thinking of right now, because you may not yet have the
background knowledge to head in the right direction. Asking about
goals can help you much more easily gather that background knowledge
and develop your skill set more quickly.
As an example, what do you hope to accomplish using the events that
notify you of keypresses? Are you trying to limit the way text is
entered into a text field? If that's the case, you *do not* achieve
this in Cocoa by overriding -[NSWindow sendEvent:] or -[NSApplication
sendEvent:]. You don't even create an NSTextField or NSTextFieldCell
subclass. Instead, you create a subclass of NSFormatter, and attach an
instance of your formatter to your text field's cell. This gets you a
way to limit field input that will be invoked at the correct times in
the correct way by the formatter, and can even be re-used in other
situations such as table or outline view columns. (It's also easier to
unit test.)
In summary: Ask in terms of your end goals, and don't assume that the
way you would implement something on one platform is the way you would
do so on another. And have fun writing clean, reusable code on a
platform that works hard to enable it!
-- Chris
vinny
Win32 way is the definitive way of doing this, it is because it is the
only way I know how to implement it at the moment. I am aware that the
Carbon and Cocoa way will be much different.
Anyway, back to the problem at hand:
The USB HID device I wish to use is a standard phone keypad (numbers 0
to 9, call, hang up, volume up/down). At the moment, I am awaiting the
Mac OS X keypad driver, but when the device is plugged in, the volume
control will control the OS volume (so I am assuming there is some
default HID driver for this).
So, my question is this: how would I go about detecting the volume
control event in my own app, so I could go about performing some action
(such as scrolling through a contacts list) when the volume key is
pressed?
Thanks,
Vinny.
Michael Ash
> Thanks for the response. If it seems like I am "assuming" that the
> Win32 way is the definitive way of doing this, it is because it is the
> only way I know how to implement it at the moment. I am aware that the
> Carbon and Cocoa way will be much different.
>
> Anyway, back to the problem at hand:
>
> The USB HID device I wish to use is a standard phone keypad (numbers 0
> to 9, call, hang up, volume up/down). At the moment, I am awaiting the
> Mac OS X keypad driver, but when the device is plugged in, the volume
> control will control the OS volume (so I am assuming there is some
> default HID driver for this).
>
> So, my question is this: how would I go about detecting the volume
> control event in my own app, so I could go about performing some action
> (such as scrolling through a contacts list) when the volume key is
> pressed?
I know almost nothing about talking to HID devices.
However, when I wanted to read a joystick throttle, knowing nothing about
talking to HID devices, I used the HID Utilities which you can download
here:
http://developer.apple.com/samplecode/HID_Utilities_Source/index.html
It has a lot of convenience methods and generally makes the task pretty
simple. I simply polled the joystick since I had to send the data out to
another app 20 times a second anyway, but it looks like you can set it up
to invoke a callback when something changes if you prefer.
vinny
and the HID Explorer sample application and have managed to get it to
buil successfully. It's picking up the USB HID device as a USB Audio
Device, and I can see the values changing when pressing the volume up
and down keys, as expected. I'll have to take a look at how I'd go
about accessing this information (probably using a callback, like you
said).
Thanks,
Vinny.
Chris Hanson
> Anyway, back to the problem at hand:
>
> The USB HID device I wish to use is a standard phone keypad (numbers 0
> to 9, call, hang up, volume up/down). At the moment, I am awaiting the
> Mac OS X keypad driver, but when the device is plugged in, the volume
> control will control the OS volume (so I am assuming there is some
> default HID driver for this).
>
> So, my question is this: how would I go about detecting the volume
> control event in my own app, so I could go about performing some action
> (such as scrolling through a contacts list) when the volume key is
> pressed?
I don't know the answer, but the first place I'd look would be at the
HID Manager and HID Utilities which Michael pointed you too.
I would like to say, though, that the above is a *great* way to
describe what you're trying to achieve. I'm not being sarcastic: I'll
find your post in Google Groups in the future and refer others to it
when I ask them to state the goal they have in mind rather than the
technologies they'd use on another platform.
Seriously, thanks!
-- Chris