Closed GoogleCodeExporter closed 9 years ago
That "non-editable" field is actually the header button getting the focus, as
evidenced by the fact that if you hit the spacebar while it's focused, the
WindowShade will toggle closed. This might be desirable, except that the focus
rectangle appears right below the header button, at the top of the content area,
which is weird since the header button is part of the chrome.
As an interim workaround, you could use the headerRenderer property of the
WindowShade to create your header button, and for that, use a ClassFactory that
will
set the button's tabEnabled property to false. If you do that, the focus should
move
to the first field of the next WindowShade.
Original comment by xslf...@gmail.com
on 16 Mar 2008 at 2:48
I just check in a fix for this, which is simply setting tabEnabled to false on
the
header button. I delved into it with the debugger, and the out-of-place focus
rectangle for the header button seems to be caused by a pretty deep bug in the
Flex
framework.
I also noticed that controls inside a closed WindowShade can be tabbed to,
which is
probably not desired behavior. I modified WindowShade_Sample.mxml to show how
you can
bind the tabEnabled property of each TextInput to the opened property of its
enclosing WindowShade. It works pretty well. When you tab out of the last field
on a
WindowShade, it skips completely over the next WindowShade if it's closed, and
focuses the first TexInput in the next opened WindowShade that it finds. The new
WindowShade sample app is here:
http://flexlib.googlecode.com/svn/trunk/examples/WindowShade/WindowShade_Sample.
swf
Original comment by xslf...@gmail.com
on 17 Mar 2008 at 2:50
Original issue reported on code.google.com by
sforbes...@gmail.com
on 16 Feb 2008 at 1:29