On 1/29/05 6:22 PM, Mike Lazear didst favor us with:
>> I'm not sure why you even need to test this. Why do you have a
>> kEventMouseDown handler attached to your window? Most low-level events like
>> this are handled by the views/controls in the window or handlers attached to
>> the controls.
>>
> I don't have a keventMouseDown handler attached to the window. I only have
> two events attached: kEventCommandProcess and kEventControlHit.
>
> When I click on an area of the window without a control one of those events is
> getting called. I don't know which one (or really care) since clicking
> outside of a control for these particular dialogs should do nothing. I just
> need to add the signature test as suggested so it doesn't call code that
> shouldn't be called.
Why do you need a kEventControlHit handler on the window? The OK button
should handle all tracking and just send a kHICommandOK event when the user
clicks it.
>
>> Sorry, but changing the content view's signature would a be a flat out hack,
>> and an ugly one at that.
>>
> Easy, Larry. I wasn't trying to argue that it was not a hack. I was trying
> to find out if that's what I was suppose to be doing or if I was suppose to be
> testing the signature. Per your recommendation I will check the signature and
> won't mess with the signature and ID of the content view. All I was saying
> was I was looking for the correct solution and not a way to "hack around my
> problem". If changing the content view is a hack, which you have clearly
> stated, then I don't want to change it.
I can't help but wonder if your design is what it should be if you have a
kEventControlHit handler installed on the window handling an OK button. I've
never heard of that before and I can't imagine why you'd want to handle it
that way.
I have 50+ windows in my application. I install only a handful of
kEventControlHit handlers, and in every case I install them on the controls
that need them.
>>> I find many things in IB are not intuitively obvious and I wanted to make
>>> sure I wasn't just missing the "right way" to click to select the window, or
>>> as you corrected the content view.
>>>
>> You shouldn't have to do anything to select the window. Do you not have the
>> standard handler installed?
>>
> Sorry, I don't think I made this clear enough. While running IB you have to
> click on controls to select them. If you want to change the window Attributes
> you have to select the window (I'm not talking about code here). For Popup
> menus in IB if you click on it one way you get the root of the menu if you
> click another way you get something else. I was thinking maybe I just didn't
> know the secret clicking method that took you to the signature and ID of the
> window (content view). Clearly that is all a mute point because I'm not going
> to mess with it since that would be a hack. =)
Also a moot point because IB doesn't let you edit anything about the root
control aka the content view. You can install handlers on it, but beyond
that you shouldn't mess with it because the Window Manager relies on certain
assumptions about it.
>>> This seems like a major overkill to try and have every control on every
>>> window be unique throughout the entire app. Much simpler to just make
>>> controls unique to the window.
>>>
>> Correct.
>>
> Larry, do you ever sleep? It seems like you are always on here. =) Thanks
> again for your help.
Yes, I sleep just sleep at odd hours by most people's standard and they
change from day to day.
Larry
_______________________________________________
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
