TQ框架解析(七)：框架的消息机制

我曾经在 5.0 版里实现了一次所谓的消息机制。当时是使用 WINSock (OCX)，在 UDP 协议上实现的，这种实现方式仅在简单的生成环境有存在的价值。一直没有机会尝试 HTTP 协议，终于，在 6.0 专业版予以完美实现。

虽然 WINSock(OCX) 有缺陷，但是，如果仅仅是传递消息，还是完全可以的。通常的模式是多个客户端对一个服务端。但是，在企业级应用过程中，如果可以任意两台终端，在赋予的权限范围内可以通讯，还是有一定的现实应用场景。6.0 版的消息机制就是基于此设计的。本质上，服务端即客户端，客户端即服务端。我给这种消息机制起了一个不算高大上的名字：系统服务。当启用了相应的系统参数后，此系统服务才处于可用状态。默认是关闭的。

参数开启的状态下，在服务器端可以运行一个常规的可执行文件：SoftServer.exe，当然，如果你愿意，可以把它变成“WIN服务”（如果留心，本公众号已经指明了一些线索。当然，坐等，我也不会让你失望）。下图是当有用户登录系统时的状态：

当同一系统账号在另一台PC启动同一软件时，服务端会自动发送一条消息至先前已登录未退出系统的PC，激活 SoftClientServer.exe, 显示一条信息并将其“踢掉”。这样，可以保证同一系统用户能且仅能在唯一的PC登录系统。

这是我以前遇到的一个场景需求。当时受限于条件，采用的技术有些LOW，因此，将同一需求内置在框架中予以支持。

在现实应用中，存在大量使用此技术的场景需求，例如，某个苦逼打工仔在完成某项操作后，需要尽快告知其顶头上司；又或者，某个顶头上司心血来潮，突然要向所有下属下发一条紧急通知，甚至于，某人在完成某项工作时需要同步通告平级或上级，诸如此类。

通过修改框架提供的源码，参照已实现的功能(模板)，这些消息传递的需求，很轻易的就可以完成。无疑，它会为现实应用增色不少。

无需理解它的原理，仅需知道在哪里用什么方式安全的插入自己的逻辑代码，无论是所谓的现实“服务端”还是“客户端”。当然，如果不满意框架提供的COM方式的信息提示，也可以利用OS的“通知”来在所谓的客户端显示通知。接收到消息的操作员，甚至可以通过消息直达他/她的“工作现场”！

留一个悬念，你找到实现OS“通知”的方式了吗？