On 31/01/2005 05:32 Pm, Bryan Pietrzak wrote:
> On Jan 31, 2005, at 4:50 AM, Mike Kluev wrote:
>
>> on 30/01/2005 5:25 Am, Bryan Pietrzak at email@hidden wrote:
>>
>>> On Jan 30, 2005, at 12:23 PM, Mike Kluev wrote:
>>>
>>>>> I only use commands for menu items. All my control handling goes
>>>>> through control hit events.
>>>>
>>>> Including kEventControlSimulateHit, right?
>>>
>>> I've never used that event.
>>
>> Then, doesn't your app have problems on selecting controls with
>> keyboard (default/cancel buttons, full keyboard access, universal
>> access, etc).
>
> No. Works just fine.
Correct, see below.
>> I believe kEventControlSimulateHit event is sent
>> instead of the usual kEventControlHit in such cases.
>
> That does not seem to be true. Reading through CarbonEvents.h I don't
> see how you could reach that conclusion,
>From CarbonEvents.h:
* kEventClassControl / kEventControlHit
*
* Summary:
* Sent by TrackControl and HandleControlClick after handling a
* click in a control.
*
* Discussion: ...
(says about mouse access (TrackControl and HandleControlClick) but
doesn't say about keyboard access)
and
* kEventClassControl / kEventControlSimulateHit
*
* Summary:
* Sent when your control should simulate a click in response to
* some other action, such as a return key for a default button.
> and in practice, it doesn't
> seem to true as my dialogs all work fine with Full Keyboard Access.
Correct. I rechecked it and it turns out that in these situations
kEventControlSimulateHit is sent prior to kEventControlHit to a
handler installed on the control target (and it is not sent at all
to a handler installed on the window target).
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
