ThinkSSL🔒 一键申购 5分钟快速签发 30天无理由退款 购买更放心 广告
# 开发笔记 ## 文件布局 \# 几乎所有都会使用(并且被认为是块!) win32defines.py win32functions.py win32structures.py \# 查找窗口及其属性 findwindows.py handleprops.py \# wrap windows, get extra info for particular controls # set the friendly class name controlscommon\_controls.py controlscontrolactions.py controlshwndwrapper.py controlswin32\_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 testsallcontrols.py testsasianhotkey.py testscomboboxdroppedheight.py testscomparetoreffont.py testsleadtrailspaces.py testsmiscvalues.py testsmissalignment.py testsmissingextrastring.py testsoverlapping.py testsrepeatedhotkey.py teststranslation.py teststruncation.py controlproperties.py xml\_helpers.py > FindDialog.py PyDlgCheckerWrapper.py application.py test\_application.py ## 最佳匹配 difflib提供此支持对于菜单,我们很简单地匹配菜单项的文本。 对于控件来说,故事更复杂,因为我们希望与以下内容相匹配: > * 控制文本(如果存在) > * 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 ## 属性解决方案 再想一想...... app.dlg.control 两个级别 * application.member (Python resolves) an attribute of application object * application.dialog a dialog reference 三个级别 * 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 四个级别(废弃Python解决) * application.dialog.member.member * application.dialog.control.member 延迟解决成功,举个例子 ~~~ app.dlg.control.action() ~~~ 如果我们忽略语法和编程错误,仍有许多原因导致它失败。 可能找不到dlg可能无法找到控件dlg或控件可能被禁用 可以在错误的对话框中找到对话框和控件(例如在记事本中,您可以使用“确定”按钮调出2个“页面设置”对话框) 一个解决方案就是在尝试找到每个新对话框之前添加一个“睡眠”(以确保它在那里并准备就绪) - 但这将意味着许多不必要的等待。 所以我尝试的解决方案是: * 在最近的可能时间执行完整的属性访问解析 * 如果失败则等待再试一次 * 在指定的超时失败后引发原始异常。 这意味着在正常情况下,您没有不必要的等待 - 并且在失败的情况下 - 您仍然会收到错误的异常。 同时,如果路径的早期部分成功,则等待尽可能晚地执行解决方案会停止错误,但会发现错误项。 因此,例如,如果在记事本中找到页面设置对话框,请打开打印机设置对话框(标题为“页面设置”)app.PageSetup.Printer.Click() \# 如果运行得太快,它会在下一个对话框打开之前找到当前页面设置对话框#,但该对话框没有Properties#按钮 - 因此会引发错误。 #因为我们从一开始就重新运行分辨率,我们找到了新的pagesetup对话框。app.PageSetup.Properties.Click() ## 写入对话框 我们需要一种确保对话框处于活动状态而无需访问控件的方法。 例如 ~~~ app.MainWin.MenuSelect("Something That->Loads a Dialog") app.Dlg._write("dlg.xml") ~~~ 或者更难的问题: ~~~ app.PageSetup.Printer.Click() app.PageSetup._write("pagesetup.xml") ~~~ 在第二个示例中,很难确定是否显示了正确的页面设置对话框。 唯一能真正确定的方法是检查某些控件(ID、类、文本等)的存在性,但最好不要处理这些控件:-( 另一个较少声明(更神奇?)是扫描可用窗口/控件列表,如果它们没有改变,则接受显示正确的窗口/控件。 当测试和拥有XML文件时,我们应该使用这些文件来确保有正确的对话框(通过使用class/id)