此源码的主要目的是对COM+接口和实现过程的演示，并非真正的远程控制。但确实可以不经过防火墙访问网络！供对COM+感兴趣的朋友参考一下，如果大家有更好的COM+方面的源码，希望能共同讨论，共同提高！ E-Mail: hzyong888@163.com

收钱吧聚合支付接口演示(Delphi源码)

关于A*寻路算法的代码在网上有很多，但用DELPHI的比较少，本人花了一天时间找到这个，代码和界面都比较精炼，于是在关键处作了中文注释，但愿对朋友们有用。 A*寻路算法简介 A*与最好优先算法的原理类似，只是最好优先算法在路经上给出了节点的代价，而A*算法需要F(NODE) = G(NODE)+H(NODE)的估价函数来估计当前点的代价

DLL窗口中回调函数的演示（Delphi）。知识点：1、DLL中窗口的引用 2、DLL中的回调函数的应用。

收钱吧聚合支付 支持微信、支付宝、花呗、云闪付、信用卡等收款 收钱吧统一手续费率为0.38%，而微信和支付宝官方商用接口为手续费率为0.6% 收钱吧APP有实时交易记录及语音提示，次日0点后会自动申请打款到绑定银行卡 本程序主要演示微信和支付宝的收款和查询接口 也可支持网站下单，服务器异步回调通知等支付场景

股票，证券等，用这个来发布行情数据，刷刷的。 UDP通信的优势 速度比TCP快。 UDP通信的缺点 一旦UDP包过大的话，也能正常工作。只是优势就丢失了。 idUdpClient 主要用于发送udp请求，在接收udp响应的时候是同步的,所以一定要设置超时,否则的话程序容易死。 idUpdServer 即能用于发送udp数据包，也能用于接收udp数据包。但是设计的主要目的还是用于收到udp数据包之后给于反馈。 UDP包的大小问题 资料1:以太网的MTU是1500字节，IP包头占20个字节，UDP首部占8个字节，也就是说实际数据应该小于1472字节. 资料2:鉴于Internet上的标准MTU值为576字节,所以我建议在进行Internet的UDP编程时.最好将UDP的数据长度控件在548字节(576-8-20)以内. 测试结果: 0-548字节:会完美的展现UDP协议的优势(速度刷刷的)。 大于1472字节以后的话,也可以正常执行。你会见识到什么叫做不可靠的信道(经过测试90%以上还是成功的,只是速度慢了很多)。 数据包大于2K速度明显变慢了；数据包大于3K，成功率60%到80%；数据包大于4k，成功率20%以下。 结论: 1.UDP协议还是比较可靠的。使用它能充分挖掘速度的潜力。通常大部分请求和相应都在548以下，小部分请求超过548。 2.548字节，可以存储274个汉字呢。比手机短信都长。你传什么那么大？ 3.尤其是双方都在修改数据，需要实施数据实时同步的时候。修改量都比较小，用udp再合适不过了。 客户端的阻塞式响应不太理想 可以采用的办法是双方都开UDP服务器来接受。