set keyword

I do not understand this issue. If the problem is that selected chart objects
are not read, this one is duplicate to Issue 73747.

If the problem here is that controls of the wizard are not read, please clarify
which controls. Do you mean the "3d Look" check-box? If it is a control, then
change the summary.

Its not the control to activate. I mean the entries into the Listbox e.g. Box,
Cylinder, Cone...) there not be read.

->iha: It seems that the problem does not appear for the shapes only, but also
for other controls on the chart type tab of the wizard or the chart type dialog.
The problem is that changing a control like "3d" or the shape changes the icons.
ZoomText seems to start reading the control but immediately stops and reads the
next change which is the re-selection of the icon in the list of up to 4 icons
with chart sub-types. Maybe it is possible to update the list and re-select the
correct entry without sending change events (UpdateMode(FALSE) or sth. like that).

->bm: You can try to set that in method ChartTypeTabPage::fillAllControls
before m_aSubTypeList.SelectItem
maybe also before 'm_pCurrentMainType->fillSubTypeList' .

Accepting the issue, but not sure if this can really be fixed.

The subtype list box makes itself very important. After a new shape has been
selected, the list of subtype icons is replaced by new ones. As temporarily the
box is empty, the selection is also reset. In order to set it back, SelectItem
is called. This leads to reading the sub-type box. (Commenting-out this line
would fix the bug, but that's not possible, because no subtype would be selected
then).

I tried to remember the control that had the focus before, and set the focus
after the sub-type's SelectItem, but that doesn't help.

Only chance I see, is to do the sub-type list box rearrangement and re-selection
before the actual control does its work. Maybe Window::PreNotify can help? (But
how do you notice what kind of change is just happening).

BTW, this problem occurs also at other places in OOo. So, I haven't seen a fix
for this problem in place yet.

I think the problem may be the valueset. When a SelectItem() is called, and
there are a11y listeners attached to the control they are always notified (there
is no way to do a selection without the notifications). All other controls
notify their state changes via the internal message loop. Now, it looks to me
that the VCL-control notifications would happen synchronously or at least in
some way preferred over the notifications that are done in the value-set
implementation, where the a11y listeners are called directly.

If this is really a timing problem, the only meaningful fix for this would be to
allow selecting an entry in the value-set without sending a11y notifications.

Ok, forget the guesswork in the last comment ;-) It seems now apparent, that the
problem is the following:

ZoomText reads only events that apply to the control that has the focus. So in
principle, everything should work fine, as we don't change the focus. However,
in addition the ACTIVE_DESCENDANT_CHANGED events that are generated for
transient children in list boxes (or value sets) are also read by ZoomText.

For a value set that has at most 4 entries, it does not make much sense to have
transient children. So, if the value set in the ChartType dialog
(chart2/source/controller/dialogs/tp_ChartType.cxx) would get non-transient
children this would be a reasonable improvement and would also fix this issue.
(The alternative would be a changed behaviour of ZoomText)

->PB: As you already did some changes for the tree-list-box to enable it having
non-transient children, please apply this also to the ValueSet (svtools).

Note, that the CWS chart03 does not exist physically. Changes for the new chart
are still done in chart2mst3. But note also, that chart2mst3 is currently "ready
for QA", so no committing is allowed at the moment. If you have a fix, please
pass us the files or attach a patch. Thanks.

pb -> bm: Now the ValueSet has a new method:
void ValueSet::DisableTransientChildren().
So please take over to change your ValueSet.

Files changed:
/svtools/inc/svtools/valueset.hxx 1.2.30.1
/svtools/source/control/valueacc.cxx 1.21.2.1
/svtools/source/control/valueimp.hxx 1.15.142.1
/svtools/source/control/valueset.cxx 1.29.2.1

Solution seems to be available.

1. The method DisableTransientChildren() in the ValueSet (included in CWS
chart2mst3) implementation in principle does the right thing, but too late. It
seems necessary to provide a new CTOR that gets a parameter
bUseTransientAccChildren. This also has the advantage, that it is not possible
to change the behaviour at any time, but only on construction.

2. The role of a value set is LIST. In the access-bridge there seems to be an
automatism that sets the flag "manages descendants" for all LIST objects. That
is wrong in this context and must be changed according to the corresponding state.

Setting pb on CC.

->PB: As I wrote before, the time when DisableTransientChildern() is called is
too late. So we have to move the switch to the CTOR. You did a similar change
also in the list-box implementation. Might there be a similar problem? I heard
that that was a fix for Gnome, but maybe it is only by coincidence, that on
Gnome the call comes in time (on Windows/ZoomText it is apparently too late).

Changed target to 2.3

Fixes in chart2 and svtools done in CWS swa11y01.

->OBR: The fix in the accessbridge does not seem to work. Changing the
accessible role of the value set to PANEL, solves the problem. When it stays on
LIST, the bug still occurs.

->PB: Please have a look at the changes I did in svtools for the ValueSet in CWS
swa11y01. What I changed is the following:

1. I removed the new method and replaced it by a parameter in the CTOR of the
ValueSet. Thus, the bool parameter is set in time, and cannot be changed during
the lifetime of the ValueSet.

2. As it turns out that the Java Access Bridge (version 2.0.1) treats all a11y
object of type LIST and TREE as having the state "managesDescendants", no matter
if this state is set or not. So, when the bool flag is true, PANEL is used as
the accessible role.

3. When a different entry is selected, instead of sending an
ACTIVE_DESCENDANT_CHANGED event from the ValueSet itself, a STATE_CHANGED with a
FOCUSED state type is sent from the child.

So far, this looks good: A. the list box is read correctly, i.e. the problem of
this issue is fixed, B. selecting a different entry in the value set triggers an
event.

However, ZoomText once read: "Normal, One of Four" for the first icon (named
Normal). Now it reads "Normal, Disabled". Please check if the value set items
can be enabled, or what might be a problem here. I am not so familiar with this
a11y things for controls.

pb: I take over.

pb: I changed the summery. Now the entries were read but at the end the reader
says "Disabled". But nothing is disabled.

pb: summery changed again. Now if you select an entry of the main type list
(ListBox in the middle) the selected entry of the sub type list (ValueSet on the
right) was read.

target 3.0

pb: fixed in cws pba11y02.
Files changed:
/chart2/source/controller/dialogs/tp_ChartType.hxx 1.4.48.1
/chart2/source/controller/dialogs/tp_ChartType.cxx 1.8.48.1

pb -> es: the problem was that the screenreader added a "Disabled" or "Grayed"
after the name and type of the ValueSet-Items when you select an item of the
chart sub types. This is fixed.

pb -> es: please verify. thx.

Verified in CWS pba11y02

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues