Bug 485965 - CheckedListBox, tree table: with wrong name
Summary: CheckedListBox, tree table: with wrong name
Status: VERIFIED FIXED
Alias: None
Product: UI Automation
Classification: Mono
Component: Winforms - ATK Spec (show other bugs)
Version: Release 1.0
Hardware: x86 openSUSE 11.1
: P3 - Medium : Normal
Target Milestone: Release 1.1
Assignee: Andres Aragoneses
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-17 12:10 UTC by Feng Xia Mu
Modified: 2009-05-13 03:22 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
accerciser shows the bug (70.01 KB, image/png)
2009-03-17 12:10 UTC, Feng Xia Mu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Feng Xia Mu 2009-03-17 12:10:51 UTC
Created attachment 279991 [details]
accerciser shows the bug

PROBLEM STATEMENT:
in checkedlistbox.py , we add two "tree table", there are no name for two "tree table", but from accerciser I find that the first "tree table" has name, whose name is as same as the first "check box", besides if first "check box"'s name has changed it's name will change according with the fist "check box" as well.


REPRO:

1. run accerciser
2. run uia2atk/test/samples/checkedlistbox.py
3. in accerciser, expand 'ipy' , we can see that "tree table" and the first "check box" has the same name "0".
4. If we modify the  checkedlistbox.py, in line 97 , change "for i in range(20):" to "for i in range(2,20):"
5. from the accerciser we can see that their name are changed from "0" to "2"

RESULTS:
the "tree table" has an extra name 

 
EXPECTED RESULTS:
1.if we don't set a name for "tree table" control, it should not has name.
2.the "tree table"'s name should not be changed as same as the "check box"
Comment 1 Andres Aragoneses 2009-05-07 15:53:02 UTC
This bug depends on a regression caused by the fix to bug 486721.
Comment 2 Feng Xia Mu 2009-05-08 09:23:48 UTC
hi Andres,

the bug is still exists because the bug 486721 is not fixed.
Comment 3 Andres Aragoneses 2009-05-11 15:36:11 UTC
Felicia, it's not dependant anymore. I'm working on it.
Comment 4 Andres Aragoneses 2009-05-13 00:53:13 UTC
Fixed in r133999 (trunk and 1.0).
Comment 5 Feng Xia Mu 2009-05-13 03:22:09 UTC
verify in trunk r134030