极少数情况下，客户端反应慢，会出现消息发送失败

[xieyumc]

我做了以下修改：

1. 给粘贴和搜索联系人增加更多延迟 我发现，极少数情况下，在粘贴剪贴板时，会出现延迟。此时如果马上发送消息，会出现发送空消息的情况，因此我给发送消息的粘贴部分增加了更多延迟避免这个情况

2.给send_msg函数增加判断消息是否发送成功的逻辑 修改了send_msg函数，发送消息后马上通过get_dialogs获取最后一条聊天记录，以此来判断是否发送成功。

此时get_dialogs不需要再次搜索联系人，所以我仿照send_msg，给get_dialogs增加了一个search_user参数来判断是否需要再次搜索联系人

[LTEnjoy]

你好，感谢你提交的改动！关于这些修改我有一些问题：

1. 等待时间从0.1s加到0.3s是否能够彻底解决空消息的问题？

2. 关于判断是否发送成功，是否有必要增加这个功能？同时一个潜在的bug就是，如果对某用户先发了一条一样的消息，那么再发送该消息不管有没有发送成功返回都是True。

[xieyumc]

感谢你的反馈和详细说明！关于你提到的两个问题，我有以下几点建议和思考：

一.延迟设置的讨论

我增加了两处的延迟：

1. 搜索用户名：从 0.1s 增加到 0.3s
2. 粘贴消息内容：从 没有等待 增加到 0.3s

空消息的问题主要出现在第2点粘贴消息内容时，并没有设置等待时间，所以有极小概率还未把内容粘贴进去，就点了发送按钮。

我使用过程中，搜索用户名时并没有出现问题，0.1s的等待时间似乎已经足够，可以推测0.1s已经足够完成粘贴任务。

不过为了健壮性考虑，索性增加更多等待时间，都改为0.3s来保证不会再出现此问题

二.判断是否发送成功的功能

我增加这个功能的本意是“快速简单”而非“完全可靠”判断是否成功发送消息了，这样做可以提高send_msg函数的debug能力。

例如，本次空消息这个问题，发生次数极其少，我也是偶然才发现这个问题的，若是send_msg函数有返回发送错误的功能，空消息这个问题很早就会被发现了，通过简单的检测，覆盖大部分场景，可以更快发现bug

若要做到绝对可靠，可能需要根据用户提供的txt文本来做复杂的分析？或者还有其他更好的方法吗？

以后也可以再新开一个功能，根据用户的txt文本一一对比聊天记录实现绝对可靠的检测功能。与目前这个相对可靠的检测功能并不冲突

考虑到要实现绝对可靠所需的代码改动量较大，目前在确保相对可靠性的基础上，应该可以接受现有的方案

[LTEnjoy]

感谢你的解答。我稍后会测试一下增加的功能，如果没有什么问题的话，我会合并进去并且重新发布一个重新编译的exe文件。非常感谢你做出的贡献！