用AI赚第一桶💰低成本搭建一套AI赚钱工具,源码可二开。 广告
# PYWINAUTO TODO’s * 确保为所有未记录的方法/函数添加文档字符串 * 检查测试的覆盖范围并努力增加测试。 * 添加SendInput单击方法的测试 * 使用FuzzyDict实现findbestmatch。 * 找到一种更好地处理应用程序数据的方法。 目前,如果有人甚至添加了对print_control_identifiers()的调用,它将破坏匹配算法! * 需要移动检查,如果一个控件是一个来自__init__方法的Ownerdrawn /位图控件,并进入它自己的方法,如IsNormallyRendered()(为什么?) * 举例说明如何使用Tray Window * 修复ToolbarWrapper.PressButton()似乎不起作用(发现在IE示例脚本上工作) * 也许提供一个选项,以便可以使用以下命令运行脚本: ~~~ pywinauto.exe yourscript.py ~~~ 这可以通过创建一个导入脚本的Py2exe包装器(并可选地调用特定的函数?)来实现。 这样pywinauto可以在没有安装python的情况下使用(无论这是一个很大的要求,我不知道,因为自动化语言无论如何都是python! * 消息陷阱 - 如何处理不需要的消息框弹出? 1. 等待Exception然后在那里处理它 2. 设置陷阱等待特定对话框 3. 在调用窗口规范时,如果我们找不到窗口,那么我们可以快速浏览可用的指定陷阱以查看是否有任何陷阱 - 如果他们这样做我们可以运行相关的操作 - 然后再次尝试我们的原始对话框 * 处理添加引用控件(因为它们应该是用于查找窗口的控件) * 找到一个变量的引用名称,例如在Dialog_write()中我们可以知道调用 _write的变量名(我们不必重复XML文件名!) * 如果我们在按钮单击控制后删除延迟然后尝试连续关闭两个对话框可能会失败,因为第一个对话框尚未关闭,第二个可能具有相似的标题和相同的关闭按钮,例如PageSetup.OK.Click() ,PageSetup2.OK.Click()。 一个可能的解决方案可能是在应用程序中保留一个窗口缓存,并且没有两个不同的对话框标识符(在这种情况下为PageSetup和PageSetup2)可以具有相同的句柄 - 因此当我们调用PageSetup2时返回PageSetup的句柄会失败(和 我们会做我们平常的等待,直到成功或超时)。 * 使用以下任何一项进行调查 > * BringWindowToTop: probably necessary before image capture > * GetTopWindow: maybe to re-set top window after capture? > * EnumThreadWindows > * GetGUIThreadInfo * 使用上下文(右键单击)菜单可以轻松使用 * 进一步支持.NET控件并下载/创建测试.NET应用程序 * 查看支持系统托盘(例如右键单击图标) * 提供SystemTray类(可能是单例) * 查看单击和文本输入 - 也许使用SendInput * 支持Up-Down控件和其他常用控件 * 找出control.item.action()或control.action(item)是否更好 * 创建一个Recorder以可视化创建测试 **低优先级** * 创建一个类,可以轻松处理单个窗口(例如,没有应用程序) * 允许在其他线程中启动应用程序,这样我们就不会锁定 * 这已经完成了-问题是,如果某些消息有指针,那么它们就不能跨进程发送(因此,我们需要发送一条同步消息,该消息在返回前等待另一个进程响应) * 但我想可以创建一个线程来发送这些消息吗? * 从HwndWrapper中解放代码 - 除了handleprops中提供的内容之外,这些添加内容很少。 这是必需的主要原因是FriendlyClassName。 所以我需要看看是否可以将其转移到其他地方。 这样做可能会使层次结构变得相当扁平,并减少对各种包的依赖性 * 需要将菜单项设置为类,而不是Dlg.MenuSelect,我们应该这样做 ~~~ dlg.Menu("blah->blah").select() ~~~ or even ~~~ dlg.Menu.Blah.Blah.select() ~~~ > 要做到这一点,我们需要更改菜单的检索方式 - 而不是在开始时获取所有菜单项 - 然后我们只需获得所需的级别。 > > 这也可以实现这样的目标 > > ~~~ > dlg.Menu.Blah.Blah.IsChecked() IsEnabled(), etc> > ~~~ ## 关闭(以某种方式或其他方式) * 单击后允许延迟删除。 目前需要这样做的主要原因是因为如果你关闭一个对话框,然后立即尝试对父进行操作,它可能还没有激活 - 所以需要延迟才能使它变为活动状态。 要解决此问题,我们可能需要在对话框上调用操作时添加更多魔法,例如: 在ActionDialog的属性访问上执行以下操作: > * Check if it is an Action > * If it is not enabled then wait a little bit > * If it is then wait a little bit and try again > * repeat that until success or timeout The main thing that needs to be resolved is that you don’t want two of these waits happening at once (so a wait in a function at 1 level, and another wait in a function called by the other one - because this would mean there would be a VERY long delay while the timeout of the nested function was reached the number of times the calling func tried to succeed!) * Add referencing by closest static (or surrounding group box?) * Need to modularize the methods of the common\_controls because at the moment they are much too monolithic. * Finish example of saving a page from IE * Document that I have not been able to figure out how to reliably check if a menu item is enabled or not before selecting it. (Probably FIXED NOW!) For Example in Media Player if you try and click the View->Choose Columns menu item when it is not enabled it crashes Media Player. Theoretically MF\_DISABLED and MF\_GRAYED should be used - but I found that these are not updated (at least for Media Player) until they are dropped down. * Implement an opional timing/config module so that all timing can be customized