/
dev_notes.txt
179 lines (117 loc) · 4.64 KB
/
dev_notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
++++++++++++++++++++
Dev Notes
++++++++++++++++++++
===========
FILE LAYOUT
===========
# used by just about everything (and considered a block!)
win32defines.py
win32functions.py
win32structures.py
# Find windows and their attributes
findwindows.py
handleprops.py
# wrap windows, get extra info for particular controls
# set the friendly class name
controls\common_controls.py
controls\controlactions.py
controls\hwndwrapper.py
controls\win32_controls.py
# currently depends on the Friendly class name
# probably needs to be refactored to make it independent of controls!
# maybe move that stuff to _application_?
findbestmatch.py # currently depends on controls!
controlactions.py
tests\allcontrols.py
tests\asianhotkey.py
tests\comboboxdroppedheight.py
tests\comparetoreffont.py
tests\leadtrailspaces.py
tests\miscvalues.py
tests\missalignment.py
tests\missingextrastring.py
tests\overlapping.py
tests\repeatedhotkey.py
tests\translation.py
tests\truncation.py
controlproperties.py
xml_helpers.py
FindDialog.py
PyDlgCheckerWrapper.py
application.py
test_application.py
====================
Best matching
====================
difflib provides this support
For menu's it is simple we match against the text of the menu item.
For controls the story is more complicated because we want to match
against the following:
- Control text if it exists
- Friendly Class name
- Control text + Friendly class name (if control text exists)
- (Possibly) closest static + FriendlyClassName
e.g.
FindWhatCombo, ComboBox1,
or
Text, TextRiadio, RadioButton2
1) the control itself knows what it should be referred to
2) Need to disambiguate across all controls in the dialog
3) then we need to match
====================
ATTRIBUTE RESOLUTION
====================
Thinking again...
app.dlg.control
TWO LEVELS
* application.member (Python resolves)
an attribute of application object
* application.dialog
a dialog reference
THREE LEVELS
* application.member.attr (Python resolves)
another attribute of the previous member
* application.dialog.member
a member of the dialog object
* application.dialog.control
a control on the dialog
FOUR LEVELS (leaving out Python resolved)
* application.dialog.member.member
* application.dialog.control.member
DELAYED RESOLUTION FOR SUCCESS
Taking the example ::
app.dlg.control.action()
If we leave out syntax and programming errors there are still a number of reasons why it could fail.
dlg might not be found
control might not be found
either dlg or control may be disabled
dialog and control may be found but on the wrong dialog (e.g. in Notepad you can bring up 2 "Page Setup" dialogs both with an OK button)
One solution would just be to add a "sleep" before trying to find each new dialog (to ensure that it is there and ready) - but this will mean lots of unnecessary waiting.
So the solution I have tried is:
- perform the complete attribute access resolution at the latest possible time
- if it fails then wait and try again
- after a specified timeout fail raising the original exception.
This means that in the normal case you don't have unnecessary waits - and in the failure case - you still get an exception with the error.
Also waiting to do resolution as late as possible stops errors where an earlier part of the path succeedes - but finds the wrong item.
So for example if finds the page setup dialog in Notepad
# open the Printer setup dialog (which has "Page Setup" as title)
app.PageSetup.Printer.Click()
# if this runs too quickly it actually finds the current page setup dialog
# before the next dialog opens, but that dialog does not have a Properties
# button - so an error is raised.
# because we re-run the resolution from the start we find the new pagesetup dialog.
app.PageSetup.Properties.Click()
==================
WRITING TO DIALOGS
==================
We need a way of making sure that the dialog is active without having to access a control on it.
e.g. ::
app.MainWin.MenuSelect("Something That->Loads a Dialog")
app.Dlg._write("dlg.xml")
or a harder problem::
app.PageSetup.Printer.Click()
app.PageSetup._write("pagesetup.xml")
In this second example it is very hard to be sure that the correct Page Setup dialog is shown.
The only way to be realy sure is to check for the existance of certain control(s) (ID, Class, text, whatever) - but it would be nice to not have to deal with those :-(
Another less declarative (more magic?) is to scan the list of available windows/controls and if they haven't changed then accept that the correct one is shown.
When testing and having XML files then we should use those to make sure that we have the correct dialog up (by using Class/ID)