P T Withington wrote:
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?
Not that I can think of, no.
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?
I don't think so. The context when it gets reparented changed - now
it's onmouseover/out. Before it was much more granular: shown when the
inputtext was focused, hidden onblur.
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?
They're still important as far as mouse activation/disabling global
clickability goes...
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
--
Regards,
Max Carlson
OpenLaszlo.org
