So, if I remove the short-circuit from LzInputTextSprite/__textEvent
to not ignore events depending on the state of __shown, the test case
seems to work fine. I'm sending a change your way. I have a few more
questions:
1) If __textEvent was ignoring these events, was there someplace else
that was handling them instead that I need to address?
2) Can you think of any residual case where these events still need to
be ignored, or was the only purpose to ignore them when the input div
was reparented?
3) I wonder if there is still a purpose to __show and __hide, or if
these are more vestiges of the 'reparenting' mechanism and should just
be removed?
On 2009-08-12, at 13:27EDT, Max Carlson wrote:
I think that's right - before, when __hide was called the inputtext
changed location in the DOM and physically couldn't send keyboard
events - because focus would have been lost.
P T Withington wrote:
This is because when you mouse out of an inputtext element, the
internal __hide method is called, and when the element is hidden
it ignores most events. This seems broken to me, but I need some
input from the designer as to what __hide and __show are really
trying to accomplish. If the inputtext element still has keyboard
focus, I would think you would want to still handle keyboard events.
[[#LPP-8378] lzedittext doesn't fire onvalue events in dhtml unless
mouse is over the textfield - OpenLaszlo Jira](http://jira.openlaszlo.org/jira/browse/LPP-8378
)
--
Regards,
Max Carlson
OpenLaszlo.org
