• 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
nextValidKeyView random failures
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

nextValidKeyView random failures


  • Subject: nextValidKeyView random failures
  • From: Ricky Sharp <email@hidden>
  • Date: Thu, 19 Oct 2006 18:18:56 -0500

I have a UI with the following key loop:

[help] --> [speech caricature] --> [stop drill] --> [NSTabView] --> (back to help)

Now then, the tab view may contain items that are in the key loop. If it does, everything works as expected. With full keyboard access on, I can tab amongst all the controls.

However, when the NSTabView doesn't contain items that will participate in the key loop, I get a 50% failure.

In success cases, here's the log output of my three buttons (first three things in the keyloop):

object name (<object value>) --> <next key view object> (valid: <next valid key view object>)

helpButton_II (<IIButton: 0x4f6c20>) --> <IIButton: 0x4c41c0> (valid: <IIButton: 0x4c41c0>)
speechCaricature_II (<IIButton: 0x4c41c0>) --> <IIButton: 0x49d350> (valid: <IIButton: 0x49d350>)
cancelButton_II (<IIButton: 0x49d350>) --> <NSTabView: 0x883da90> (valid: <IIButton: 0x4f6c20>)


You can see that cancelButton_II (stop drill) has the tab view as the next key view, but that the help button is ultimately the next valid key view.


In failure cases, here's the log output:

helpButton_II (<IIButton: 0x880d8a0>) --> <IIButton: 0x45e900> (valid: <IIButton: 0x45e900>)
speechCaricature_II (<IIButton: 0x45e900>) --> <IIButton: 0x8810e80> (valid: <IIButton: 0x8810e80>)
cancelButton_II (<IIButton: 0x8810e80>) --> <NSTabView: 0x881eac0> (valid: <IIButton: 0x8810e80>)


You can see here that the cancel button's next valid key view is itself.


I do have a workaround for this specific case. It happens that when I enter that UI, the tab view will either contain 'key-view-aware' objects, or it will not (i.e. the UI doesn't dynamically switch between the two). Thus, upon entry to the UI, I can set the cancel button's nextKeyView to the appropriate object.


However, this seems a bit hackish and I'd like to know the reason behind the random failures. Also, I can definitely see myself running into this issue later on at which case I'll need a proper solution.

Finally, this is all on 10.4.8 with a Universal app (running on PPC). The objects in question are my own widgets (later I'll try to reproduce this using Aqua widgets). I don't, however, have any special handling for tab keys; I let the framework do its thing. I've also cleared the key loop in IB a few times and wired things from scratch for this particular nib. No change.

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

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: NSToolbar with NSSearchField crash (caused by menu?)
  • Next by Date: Re: How Finder loads icon(specified in Resource Folder) for an application(.app).
  • Previous by thread: Re: NSToolbar with NSSearchField crash (caused by menu?)
  • Next by thread: Over-released Paragraph Style - Driving Me NUTS!
  • Index(es):
    • Date
    • Thread