Hi Fred,
>> On Cocoa this happens.
>>
>>> 13/05/20 17:23:40,783 InterfaceBuilder[93679]: <FormTextField: 0x102cd30>
>>> acceptsFirstMouse 1
>>> 13/05/20 17:23:40,783 InterfaceBuilder[93679]: <FormTextField: 0x102cd30>
>>> becomeFirstResponder 0
>>> 13/05/20 17:23:40,784 InterfaceBuilder[93679]: <FormTextField: 0x102cd30>
>>> mouseDown ..
>>
>> So we might want to call acceptsFirstResponder: but not drop out if the
>> answer is NO but call mouseDown: anyway!? This would probably mimic the
>> Cocoa behaviour!
>
>
> In your Cocoa output acceptsFirstMouse comes before becomeFirstResponder so
> maybe we need to move line 3972 "if (wasKey == YES || [v acceptsFirstMouse:
> theEvent] == YES)“ further up. But what should we do with the result of
> makeFirstResponder just ignore it?And what should we do with
> _lastLeftMouseDownView? At what point should that be cleared? This variable
> gets used for drag or mouse up events later on to make sure these go to the
> same view as the mouse down event. The current way of setting this value just
> before we send the mouse down event to the view seems correct. But why do we
> destroy it?
>
> I hope to find time for a few tests on Cocoa later today or on the weekend.
That would be great. For now I have done
if (_firstResponder != v && ![v isKindOfClass: [NSButton class]])
{
// Only try to set first responder, when the view wants it.
if ([v acceptsFirstResponder] && ![self makeFirstResponder:
v])
{
// return;
}
}
This at least works for me though there might be a better solution.
Best wishes,
Andreas
