Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Error when ListItem is child of groupbox in syslistview32, due to no self.arent.isMultiColumn attribute #2742

Closed
nvaccessAuto opened this issue Oct 24, 2012 · 8 comments
Closed

Error when ListItem is child of groupbox in syslistview32, due to no self.arent.isMultiColumn attribute #2742

nvaccessAuto opened this issue Oct 24, 2012 · 8 comments
Labels
bug/regression bug
Milestone
2012.3

Comments

@nvaccessAuto
Copy link

Reported by ragb on 2012-10-24 16:27
This was reported in the portuguese NVDA list.

A program called "agenda jobe" shows this behaviour when entering a list. For some reason the listItems are children of a group box (does this make sence?). The atached log explains the situation better than I can.

Application in question is here:
http://www.cegueta.com/download/baixar/234/1
It is sort a personal contact agenda, but it seems the itnerface is only in portuguese. It is a .net 4 application.

User reports it worked well before the sylistview enhancements so I believe this is a regression.

Quick and dirty patch attached. It seems to solve the problem and report the correct object name. I can commit if agreed.
@nvaccessAuto
Copy link
Author

Attachment Log.txt added by ragb on 2012-10-24 16:29
Description:
Log with "agenda jobe" crash.

@nvaccessAuto
Copy link
Author

Attachment syslistview-jobe.patch added by ragb on 2012-10-24 16:31
Description:

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2012-10-24 23:15
I committed a slightly different fix in a34bb0a. (I just prefer to avoid using getattr where possible.) Can you please confirm that this fixes the issue?

As a matter of curiosity, is there actually a "list" above this list item or is there only a grouping?
Changes:
Milestone changed from None to 2012.3

@nvaccessAuto
Copy link
Author

Comment 2 by ragb (in reply to comment 1) on 2012-10-25 14:51
Replying to jteh:

I committed a slightly different fix in a34bb0a. (I just prefer to avoid using getattr where possible.) Can you please confirm that this fixes the issue?

Yes, it fixes.

As a matter of curiosity, is there actually a "list" above this list item or is there only a grouping?

There seems to be a list that is considered by NVDA as a grouping, since its iaccessible role is grouping. See the following:

Dev info for the item (the self on the List class):

Developer info for navigator object:
name: u'rui'
role: ROLE_LISTITEM
states: STATE_FOCUSABLE, STATE_SELECTABLE, STATE_FOCUSED, STATE_SELECTED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.IAccessible.sysListView32.ListItem object at 0x0594AF30>
Python class mro: (<class 'NVDAObjects.IAccessible.sysListView32.ListItem'>, <class 'NVDAObjects.behaviors.RowWithFakeNavigation'>, <class 'NVDAObjects.behaviors.RowWithoutCellObjects'>, <class 'NVDAObjects.IAccessible.sysListView32.ListItemWithoutColumnSupport'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: (195, 121, 800, 17)
value: None
appModule: <'appModuleHandler' (appName u'agenda jobe', process ID 2544) at address 5ab2a50>
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 2163904
windowClassName: u'WindowsForms10.SysListView32.app.0.378734a'
windowControlID: 2163904
windowStyle: 1442938949
windowThreadID: 2116
windowText: u''
displayText: u'rui\x00214113386\n'
IAccessibleObject: <POINTER(IAccessible) ptr=0x3ff098 at 5aae9e0>
IAccessibleChildID: 1
IAccessible event parameters: windowHandle=2163904, objectID=-4, childID=1
IAccessible accName: u'rui'
IAccessible accRole: ROLE_SYSTEM_LISTITEM
IAccessible accState: STATE_SYSTEM_SELECTABLE, STATE_SYSTEM_SELECTED, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (3145734)
IAccessible accDescription: u'Telefone: 214113386'
IAccessible accValue: None

Now the grouping / list view thing (self.parent):

Developer info for navigator object:
name: u'Lista de contatos'
role: ROLE_GROUPING
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.IAccessible.Groupbox object at 0x05BA2F50>
Python class mro: (<class 'NVDAObjects.IAccessible.Groupbox'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u'Pesquisa por nome:'
location: (195, 104, 922, 496)
value: None
appModule: <'appModuleHandler' (appName u'agenda jobe', process ID 2544) at address 5ab2a50>
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 2163904
windowClassName: u'WindowsForms10.SysListView32.app.0.378734a'
windowControlID: 2163904
windowStyle: 1442938949
windowThreadID: 2116
windowText: u''
displayText: u'Nome\x00Telefone\x00Celular\x00E-mail\nrui\x00214113386\n'
IAccessibleObject: <POINTER(IAccessible) ptr=0x3ff5c0 at 587bda0>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2163904, objectID=-4, childID=0
IAccessible accName: u'Lista de contatos'
IAccessible accRole: ROLE_SYSTEM_GROUPING
IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)
IAccessible accDescription: u''
IAccessible accValue: None

This is somehow inconsistent:

windowClassName: u'WindowsForms10.SysListView32.app.0.378734a'

Versos

IAccessible accRole: ROLE_SYSTEM_GROUPING

I supose NVDA takes in account the accessible role here. And probably right. Windows forms bug? Application developer bug? No idea.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2012-10-25 22:10
I suspect the app developer intentionally overrode accRole. The question is why.

One concern I had was that information would be missed if the list weren't treated as multi-column. Unfortunately, this turns out to be true. See the info in the accDescription property.

I think the best solution is to introduce an app module for this case, since I'm not sure it generally makes sense for a list to be a grouping. The app module should remove the GroupBox class and add the sysListView32.List class.

Mick, do you think an app module is appropriate or should we just map the grouping role anyway?

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2012-10-26 02:46
e41ef5c allows groupings to be treated as lists. This should allow the additional columns of that list to be read. Please close if so.

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2012-10-31 10:54
@ragb, ping?

@nvaccessAuto
Copy link
Author

Comment 6 by ragb (in reply to comment 5) on 2012-10-31 14:16
Replying to jteh:

@ragb, ping?

God, I was almost sure I had replied to this. I really need some sleep.
Yes, it allows reading of multiple columns on that list. Closing as fixed.

Changes:
State: closed

@nvaccessAuto nvaccessAuto added this to the 2012.3 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug/regression bug
Projects
None yet
Milestone
2012.3
Development

No branches or pull requests
1 participant
@nvaccessAuto