How to GetNextEvent in XCode
Ski
Dymo LabelWriter, and a Desk Accessory for FileMaker.
Have been reading about Carbon and Cocoa. It appears they will only pass me
events that occur in MY apps windows.
I need to write a reader for a barcode scanner, so I need access to all
that comes on the keyboard.
I used to use a product called KeyQuencer by Montalcini in Italy which
he said could never be converted to OS X and I suspect it is the event
police that cause the problem. It was somewhat like Automator.
Is there, in fact, a way to gain access to ALL events or even just keyboard
events? Is Carbon or Cocoa the only way to program for Mac?
Is there an asm compiler for OSX?
Thanks,
Ski
Reinder Verlinde
Ski <acroby...@cox.net> wrote:
A:
> I need to write a reader for a barcode scanner,
B:
> so I need access to all that comes on the keyboard.
I do not see how B follows logically from A.
<http://developer.apple.com/referencelibrary/GettingStarted/GS_HardwareDr
ivers/index.html>
> I used to use a product called KeyQuencer by Montalcini in Italy which
> he said could never be converted to OS X and I suspect it is the event
> police that cause the problem. It was somewhat like Automator.
AFAIK, Automator does nothing that you could not also do on the system.
> Is there, in fact, a way to gain access to ALL events or even just keyboard
> events?
<http://developer.apple.com/documentation/Carbon/Reference/QuartzEventSer
vicesRef/index.html>
> Is Carbon or Cocoa the only way to program for Mac?
No. Other options include Java and wxWidgets, but there are many, many
more.
> Is there an asm compiler for OSX?
If you have installed the developer tools: /usr/bin/as.
From your question, it lt looks like you think you will need to use
assembler to do what you want. I doubt that.
Reinder
Ski
>A:> I need to write a reader for a barcode scanner,
>B:> so I need access to all that comes on the keyboard.
> I do not see how B follows logically from A.
Let me explain more of the operation.
I set up a barcode scanning system for a school library on Mac OS9.
It scans into FileMaker files.
Normally this requires a person to be present to start up the system,
open FileMaker, create a new record and position the cursor into the
field for the barcode.
Then for the next scan, the operator would create a new record and put
the cursor into the field.
I automated the system for completely unattended operation.
The teachers just scan the bacodes and nobody pays any attention to the
monitor display.
The barcode scanner has pre-scan and post-scan ability.
Pre-scan is currently set to F5, Cmd-1.
F5 is grabbed by KeyQuencer and causes FileMaker to become the front most
application. Cmd-1 runs a script in FileMaker that forces the cursor into
the correct file, layout and field, and creates a new record.
Basically it is the F5 operation I need to reproduce because there is no
version of KeyQuencer for OSX. Also, the barcode producer has no plans to
make an OSX version of the pre-scan/post-scan software.
So I need to write code that will grab the event stream watch for a
barcode
then bring FileMaker to the front and type the Cmd-1.
What I read about Carbon and Cocoa is that only events that occur in an
apps own windows are sent to the app.
Ski
Gregory Weston
Ski <acroby...@cox.net> wrote:
If you want to set up a single global hot-key like what you seem to be
describing, it borders on trivial. Mostly depending on whose definition
of trivial you use.
Look for a function named RegisterEventHotKey. Then create an event
handler for kEventHotKeyPressedSubtype.
There may even be a way to do it just by configuring something the right
way in the keyboard system preferences.
Ski
news:uce-7E3B98.2...@comcast.dca.giganews.com:
It is not a hot key I need.
Teachers scanning books never come near the keyboard or the monitor.
It all has to happen automatically including the fact that FileMaker
may not even be the front app. MacOSX was specifically hampered
for security by sending events to an app only if the event occurs
in one of the apps windows.
I think Reinder gave me the right clue yesterday.
Mac OSX10.4 came forward with EventTaps which apparently recognized the
problem of OSX in overprotecting memory from any app by allowing it to
only get events originating in its own windows.
EventTaps are documented here:
<http://developer.apple.com/documentation/Carbon/Reference/QuartzEventServicesRef/index.html>
David Phillip Oster
Ski <acroby...@cox.net> wrote:
> I think Reinder gave me the right clue yesterday.
> Mac OSX10.4 came forward with EventTaps which apparently recognized the
> problem of OSX in overprotecting memory from any app by allowing it to
> only get events originating in its own windows.
> EventTaps are documented here:
> <http://developer.apple.com/documentation/Carbon/Reference/QuartzEventServices
> Ref/index.html>
The modern way for apps to communicate with each other is to send them
an appleEvent. look into osascript, Script Editor, and AESend().
To support the disabled, a user can even turn on U.I. scripting, which
allows programs to send each other click on controls, on menu items, and
arbitrary mouse clicks and keydowns.
The security in OS X is there for a reason. Professional quality
programs on Macintosh should not require the user to turn off security
for the entire machine.
Ski
news:oster-4031A1....@newsclstr02.news.prodigy.com:
> In article <Xns993C60F12EA...@69.28.173.184>,
> Ski <acroby...@cox.net> wrote:
>
>> I think Reinder gave me the right clue yesterday.
>> Mac OSX10.4 came forward with EventTaps which apparently recognized
>> the problem of OSX in overprotecting memory from any app by allowing
>> it to only get events originating in its own windows.
>> EventTaps are documented here:
>> <http://developer.apple.com/documentation/Carbon/Reference/QuartzEvent
>> Services Ref/index.html>
>
> The modern way for apps to communicate with each other is to send them
> an appleEvent. look into osascript, Script Editor, and AESend().
>
> To support the disabled, a user can even turn on U.I. scripting, which
> allows programs to send each other click on controls, on menu items,
> and arbitrary mouse clicks and keydowns.
>
> The security in OS X is there for a reason. Professional quality
> programs on Macintosh should not require the user to turn off security
> for the entire machine.
Thanks for the suggestion but it does not address my problem.
(I have made apps AE scriptable)
I have to have an app that watches EVERY keyboard character and
detects a barcode scan, switch to FileMaker and send the barcode
on to Filemaker. I can use AE cause Filemaker to come to the front
but that doesn't solve the problem of the OS only sending the KB strokes
to the app that has its window in front.
Ski
David Phillip Oster
Ski <acroby...@cox.net> wrote:
Use a faceless background task to open the scanner as a USB device, have
it send an appleEvent to Filemaker to create an appropriate record.
Filemaker need not come to the front.
Reinder Verlinde
A)
> The barcode scanner has pre-scan and post-scan ability.
> Pre-scan is currently set to F5, Cmd-1.
> F5 is grabbed by KeyQuencer and causes FileMaker to become the front most
> application. Cmd-1 runs a script in FileMaker that forces the cursor into
> the correct file, layout and field, and creates a new record.
>
> Basically it is the F5 operation I need to reproduce because there is no
> version of KeyQuencer for OSX. Also, the barcode producer has no plans to
> make an OSX version of the pre-scan/post-scan software.
B)
> So I need to write code that will grab the event stream watch for a
> barcode then bring FileMaker to the front and type the Cmd-1.
Again, I do not see how B follows from A. Apparently, under Mac OS 9,
the scanner has custom software that:
1) detects that a barcode is scanned
2) executes some user pre-scan code
3) emulates a keyboard to emulate a keyboard that types the barcode
4) executes some user post-scan code
I also guess that the scanner claims to be a USB keyboard. So, under Mac
OS X, without any custom driver for the device, the scanner types
barcodes into the frontmost application.
You seem focussed on step 2 only, but if the above is true, you will
have to write code for steps 1 through 4. If you do not, there is no way
to fire step 2 at the right time or to have step 3 wait until step 2 has
finished.
If so, your best route probably is a USB driver for the specific vendor
ID/product ID. You might be able to get away with a user-level one, but
I doubt it.
Googling on this gave me the following links that you might want to be
aware of: <http://lists.apple.com/archives/usb/2004/Mar/msg00062.html>
shows that you are not the first trying this.
<http://www.easybarcodetech.com/ebr.html> shows a reader that does what
you want. It seems that $256/unit solves your problem (just buy new
scanners)
<http://www.delicious-monster.com/> also sells a scanner that may or may
not be usable for you.
> What I read about Carbon and Cocoa is that only events that occur in an
> apps own windows are sent to the app.
That is not much different from Mac OS 9, except that Mac OS 9 made it,
in some sense, easier to hack around this (Mac OS X probably makes it
easier to do so without disrupting system stability)
Reinder
Chris Hanson
> I am just getting re-started in Mac coding. Wrote the software for original
> Dymo LabelWriter, and a Desk Accessory for FileMaker.
> Have been reading about Carbon and Cocoa. It appears they will only pass me
> events that occur in MY apps windows.
That's correct. Generally speaking, the only events your application
should be concerned with are those that occur when the user interacts
with it. This has some significant benefits. For example, application
code can become a lot simpler, since it only needs to deal with
situations it's affirmatively prepared for. Application code can also
block when it has nothing to do, freeing up CPU for other operations or
even (if the event load on the overall system is low enough) for the
CPU to be slowed or suspended by power management. No application on
Mac OS X should *ever* spin-wait for events.
> I need to write a reader for a barcode scanner, so I need access to all
> that comes on the keyboard.
The antecedent does not follow from the precedent. I worked on a suite
of applications that leveraged a barcode scanner that behaved as a USB
keyboard. All it required was using a custom subclass of NSApplication
and overriding -sendEvent: to observe keyboard events within my
application.
Sure, if the user pulled the trigger to scan something and the
application wasn't active, they got essentially random typing. For
this application - a custom line-of-business application - we could
just say "don't do that." Before making more work for yourself, see if
you can do the same thing.
If you *do* want to get lower-level access to the event stream, say
because you intend to filter it, there's pretty much only one way to
go: A Core Graphics event tap, described in the Quartz Event Services
Reference:
<http://developer.apple.com/documentation/Carbon/Reference/QuartzEventServicesRef/Reference/reference.html>
Note
that due to the low level of the interface and the secure, multiuser
nature of Mac OS X, it won't be nearly as simple as (say) just
installing a jGNEFilter to monitor events. Also note that event taps
are only supported in Mac OS X 10.4 or later.
> I used to use a product called KeyQuencer by Montalcini in Italy which
> he said could never be converted to OS X and I suspect it is the event
> police that cause the problem. It was somewhat like Automator.
>
> Is there, in fact, a way to gain access to ALL events or even just keyboard
> events?
Event taps, as above.
> Is Carbon or Cocoa the only way to program for Mac?
> Is there an asm compiler for OSX?
Cocoa and Carbon are pretty much the only game in town for high-end
native applications. Java is also available and well-supported. If
you want to write command-line utilities only, you can of course use
the wealth of BSD-derived and POSIX APIs available on Mac OS X.
I would seriously question your priorities if you wanted to write
production code in assembly rather than leveraging high-level
frameworks like Cocoa. After all, if nothing else you'll have to write
your code twice, once for PowerPC-based Macs and once for Intel-based
Macs.
Assembly is great to use when you absolutely need it. But it should be
avoided at all costs when you don't. That's why you won't get very far
asking for an "asm compiler" for Mac OS X -- why would anyone bother
with anything like that standalone? -- but the Xcode suite does include
assemblers in addition to compilers.
-- Chris
Ski
> In article <Xns993C79D34AF...@69.28.173.184>,
> Ski <acroby...@cox.net> wrote:
> [snip]
>> David Phillip Oster <os...@ieee.org> wrote in
>> news:oster-4031A1....@newsclstr02.news.prodigy.com:
>>
>> > In article <Xns993C60F12EA...@69.28.173.184>,
>
> Use a faceless background task to open the scanner as a USB device,
> have it send an appleEvent to Filemaker to create an appropriate
> record. Filemaker need not come to the front.
Thanks for this advise. May be the best idea.
Ski
David Phillip Oster
Ski <acroby...@cox.net> wrote:
I personally, inspired by HID Explorer,
http://developer.apple.com/samplecode/HID_Explorer/ , wrote a program
that a Dance Dance Revolution style USB Dancepad, opens it as a USB
device, decodes it, and sends AppleEvents to Google Earth,
http://www.google.com/mac.html , so you can run in place on the dance
pad and stride over the earth like a giant. It isn't faceless
background task, since it draws a "keycaps" style animation of the state
of the dancepad, just an ordinary app, bit it works even if it, and/or
Google Earth, are not the front app.
I also used the open source barcode scanner software,
http://www.bruji.com/cocoa/ , put a Firewire DV video camera on a
tripod, and used it to scan a few dozen DVDs. This software also works
with the iSight camera built in to recent Macs.
Nick Tamburri
> Look for a function named RegisterEventHotKey. Then create an event
> handler for kEventHotKeyPressedSubtype.
I'd like to intercept the Spotlight hot-key (e.g. <cmd>+<space>) while
in my application so that Spotlight doesn't put up it's search
"pop-up" and I can use the sequence as a command. I thought that the
above might be a good starting point toward the solution, but the docs
don't seem to address Spotlight.
Is there a standard way of suppressing Spotlight.
/nt
--
Delete this to reply directly.
glenn andreas
Nick Tamburri <n...@thistamburri.net> wrote:
Command-space is also assigned to "Select previous input source", so if
you disable Spotlight somehow, it will be used by that.
That being said, the "Keyboard Shortcuts" panel in the Keyboard & Mouse
preference pane handles this sort of assignment, allowing pretty much
arbitrary uses of them, so the user may have command-space assigned to
something that they consider even more important than either Spotlight,
input sources, or your application.
Nick Tamburri
> That being said, the "Keyboard Shortcuts" panel in the Keyboard & Mouse
> preference pane handles this sort of assignment, allowing pretty much
> arbitrary uses of them, so the user may have command-space assigned to
> something that they consider even more important than either Spotlight,
> input sources, or your application.
Good point, and it makes me realize I didn't ask the right
question. What I'm really interested in is making sure the keycode for
<cmd>+<space> gets to my application wether it's assigned to some
other system function or not. I would have thought that having a
keyDown: method defined in my first responder view would have done it,
but that doesn't seem to be the case.
Ideally, the solution would let me intercept all key-codes and let me
consume the ones I'm interested in, and pass the rest to the
system. So for example, I'd act on <cmd>+<space> but allow other keys
like Volume+/- or Brightness*/- pass to the system.
Thanks for the reply.
/nt
--
Delete this to reply.