• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Locking key window
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking key window


  • Subject: Re: Locking key window
  • From: Ricky Sharp <email@hidden>
  • Date: Wed, 7 Mar 2007 20:11:07 -0600


On Mar 7, 2007, at 7:58 PM, Rick Hoge wrote:

I know that normally this would be bad bad bad from an HIG standpoint, but I have a particular application where it makes sense.

I wrote an app for doing psychophysical and cognitive testing which has two main windows which would normally run on separate monitors.

One window is for the subject to view prompts and provide responses by the keyboard, while the other is used for the researcher to monitor the experiment.

The app runs fine at present, but I would like to find a way to ensure that, while an experimental run is in progress, all keyboard activity is processed by the window presented to the subject, even if another window is clicked with the mouse. I had a vague feeling that this might be achievable using either a run loop or one of the firstResponder methods defined in NSResponder. However I have yet to find a solution.

If anyone has any tips on how this might be achieved, it will probably save some aggravation one day when someone clicks the experimenter's window by mistake and later realizes that none of the subject's responses were recorded!

It sounds like a kiosk-type setup would work best for you.

What I'd do is use the SetSystemUIMode API as needed (perhaps you'd also like to hide the dock, prevent switching to other apps, etc.)

Then, put up blanking windows that would be full-screen on all displays. I use a subclass of NSWindow for such windows (mainly for the overrides for both canBecomeKeyWindow and canBecomeMainWindow).

The subject's window can probably remain as-is (i.e. no need to subclass). However, look at also a subclass of NSWindow for your presenter's window (where you'd also override those two methods mentioned above).

Finally, look at the 'child window' APIs of NSWindow to ensure that the presenter's and subject's windows are children of the blanking windows.

Ultimately, this should give you a collection of windows such that mouse clicks on blanking windows will be ignored (won't bring them to the front either), and mouse clicks in the presenter's window will also be ignored. The only window that will be both main and key will be the subject's window.

___________________________________________________________
Ricky A. Sharp         mailto:email@hidden
Instant Interactive(tm)   http://www.instantinteractive.com

_______________________________________________

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


  • Follow-Ups:
    • Re: Locking key window
      • From: Rick Hoge <email@hidden>
References: 
 >Locking key window (From: Rick Hoge <email@hidden>)

  • Prev by Date: Re: What is the easy way to plot data?
  • Next by Date: Re: Locking key window
  • Previous by thread: Locking key window
  • Next by thread: Re: Locking key window
  • Index(es):
    • Date
    • Thread