$s 是第一个参数，在委托声明中的名字是 sender，指事件的发送者，TabControl 自己触发的话，一般是这个 TabControl instance。

这个 context 实在是太少了，你提供了 MS 的 C#/VB 的例子的话可以翻译成中文 PowerShell 的。

@imhx233 你的 mindset 就不对，安全的必要条件是时时刻刻有人怀疑不安全。

此外，我从没说过作者发出来的可能是病毒，这个话题是楼主提出的。如果你在说我在他上一个帖子里的回复，那里面我说的是“来路不明的软件”，非人类易读代码提供或非有信誉实体提供的软件都是来路不明的，这些软件造成的安全隐患并不足以达到病毒的级别，然而也是一个很值得考量的因素。

@lzz2394677796 就我上次了解 360 杀毒，它可能会把用户自己编译的普通代码识别为病毒。此外病毒的识别是一个很复杂的工作（它是 Turing 不可计算的），大多数杀毒软件既不能保证查出所有病毒也不能保证不误杀任何文件，根据杀毒软件的检测原理可能可以找到绕过的方法。

如果您是想回应我之前说的“来路不明的软件”的问题，您可以建立信誉（这通常需要很长时间），或者提供人类可读代码（但这会导致开源）。我自然是理解不想开源的事情（我的很多代码也是不开源的）。我意在表明这样的分发软件方式的受众很小，我知道楼主表达了对受众大小的不关心。其实就是拿出来给大家看，就会开心，这种心态和分发软件的方式我从小学到初中的时候都有，也没什么不好的。这一大串话只是我的 opinion，毕竟 V2EX 是允许我如此发表我的想法的。实际上我都觉得自己有点儿老态龙钟，心态上的年轻是挺好的。

enum 成员的名字必须是标识符，因此不可以是数字开头，自然也不能是数字。

Java 允许汉字作为标识符，因为汉字属于 Lo Unicode 一般类（这类字符都允许作为标识符的一部分）。

“不规范”应该是说你们的团队规范，看待方式是 be compliant.

你不应该假设连续制造的两个对象的地址也是“接近”的。

后面 Only ... to 这句话是想告诉你如下事实：考虑 A 对象具有 B 字段，B 字段的值是（指向） C 对象（的引用），A 对象的 size 不非要大于 C 对象的 size —— C 对象的 size 不会算入 A 对象的 size。类比到 C 的话

typedef struct { void *member1, *member2, *member3, *member4; } c_t;
typedef struct { c_t *b; } a_t;

则 sizeof(a_t) 是 sizeof(void *) 而不是 sizeof(void *) + sizeof(c_t)。

好像说自己提供的文件没有病毒是没有意义的一句话。

病毒并不会说自己是病毒。会说自己是病毒的，是病毒样本文件。

欢迎来到 Windows 2000，你想说的是讲述人么？

把共享文件夹加入索引就可以搜索了吧

你要找的是不是：数组

COM 怎么会很麻烦？ VBA 和 VBS 都没用过吗？

我看了一下您的代码，就是用 Qt 帮你做的 IDispatch 包装接口去调用，使用 VBS、JScript 和 VBA 明显更简单。而且怎么也算不上 portable，毕竟你需要 host 有 Word 才行，如果你有 Word，不如直接 VBA、VBS、JScript 或者 PowerShell。

通常来说企业内的 solution 会直接从数据源（ Excel ）使用 VBA 生成可打印结果，可以参考何明科先生的知乎回答。

这个并不是 Windows 弹出来的，检查一下你的启动项

那就从你能考 85 分的年级开始学起呗

硬盘卡在海关

App 更新不都是免费的啊……所以没有一个 universal 的自动更新 app 的功能。

App 可以自己实现更新的功能，或者使用 Microsoft Store 分发。

@dorentus #5 这个说法的根据是啥？从逻辑思考这个想法不是很站得住脚，即使 Google 自己的 JavaScript 引擎解决了 Gmail 的性能问题，如果 Gmail 自己不改善代码，它在其他的浏览器上的性能也没有保障——但是 Gmail 网页版本来就是要让所有的人都能轻松访问 Gmail，如果限制在 Google 的浏览器上，何不推出 Google 自己的客户端来访问（反正，都是 Google 的软件，不差这一个）？

我没有理解您在 C++ 里的操作和 cmd/powershell 有什么关系。

如果你想让你的 C++ 代码使用 UTF-8 编码，用 cl /utf-8 编译。

如果你希望控制台接受一个特定编码的字节流，使用 chcp <code-page>。对于 cmd，当你不用重定向、管道的时候，程序向标准输出、标准错误输出的字节流会原样进入控制台。

对于 PowerShell 情况会比较复杂，因为是面向对象的 shell。分为以下两种情况：

- 如果是 <exe-name> <arg1> <arg2> ... 的形式且没有任何重定向、管道，则程序向标准输出、标准错误输出的字节流原样进入控制台；
- 如果命令是表达式的一部分，则 PowerShell 会猜测标准输出的编码，尝试把它变成一个字符串。

在后一种情况下，如果再把字符串 Write-Host 输出（或者 Write-Object 但是没有用管道、重定向），则 PowerShell 会输出那个字符串—— PowerShell 使用的是 Unicode，所以输出和编码没有关系。

下面的图展示了几种情况。

代码：UTF-8 编码的。

http://wx1.sinaimg.cn/large/8e7092e9ly1fs1v19nh6qj20ij0aw3yx.jpg

情况 1：C++ 程序输出的是 GBK，控制台代码页是 UTF-8，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 UTF-8 解读 GBK 编码的文本，会是乱码。

http://wx1.sinaimg.cn/large/8e7092e9ly1fs1v42wwrej21kw0fn3zv.jpg

情况 2：C++ 程序输出的是 GBK，控制台的代码页是 GBK，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 GBK 解读 GBK 编码的文本，会是正确的字符。

http://wx4.sinaimg.cn/large/8e7092e9ly1fs1v4kjruvj21kw0gkta5.jpg

情况 3：C++ 程序输出的是 GBK，控制台的代码页是 UTF-8，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 GBK 解读 UTF-8 编码的文本，会是另外一种乱码。

http://wx4.sinaimg.cn/large/8e7092e9ly1fs1v4zhudfj21kw0g5mym.jpg

情况 4：C++ 程序输出的是 UTF-8，控制台的代码页是 UTF-8，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 UTF-8 解读 UTF-8 编码的文本，会是正确的字符。

http://wx2.sinaimg.cn/large/8e7092e9ly1fs1v5ag794j21kw0g50u6.jpg

情况 5、6：C++ 程序输出的是 UTF-8，控制台的代码页是 UTF-8，当前系统 locale 是 2052 （就是 zh-CN，对应默认代码页 936 = GBK ），使用 PowerShell。分别用 外部程序是表达式的一部分 和 单纯启动外部程序 的语法。前者，PowerShell 需要把程序的标准输出变成字符串，程序不是 Unicode 输出，因此 PowerShell 决定使用默认代码页，也就是 936，去解读字节流（ UTF-8 ），得到的字符串（存储为 Unicode ）是乱码 [相当于 字符串 = MultiByteToUnicode(标准输出, locale 对应的编码)] ，再输出这个字符串，自然也是乱码；后者，PowerShell 让程序的标准输出字节流原样直接进入自己的控制台，因此是 UTF-8 解读 UTF-8，看到的是正确的字符。

http://wx4.sinaimg.cn/large/8e7092e9ly1fs1v6o75ssj20w709y0to.jpg

情况 7、8：C++ 程序输出的是 UTF-8，控制台的代码页是 GBK，系统默认代码页 GBK，PowerShell，分别用 表达式 和 单纯启动 语法。无论怎样都会用 GBK 解读 UTF-8，因此是一样的乱码。

http://wx3.sinaimg.cn/large/8e7092e9ly1fs1v70z3r3j20uw0a7t9n.jpg


总结：假设系统 locale 设置的默认代码页是 CPSysLocale，则默认控制台的代码页也是 CPSysLocale，但你可以用 chcp 改变，假设你改成了 CPConsole，最后，假设你的 C++ 程序输出多字节字符串，使用的代码页是 CPProg。

如果用 cmd + 重定向 /管道，则你的输出按原字节进入重定向 /管道目标，和 console 没有关系。

如果用 cmd 输出到控制台，你的输出按原字节进入控制台，CPProg 输出将按照 CPConsole 被解读并显示。

如果用 PowerShell 表达式语法，则你的 CPProg 输出将被 PowerShell 猜测编码，如果它没有 BOM，则会按照 CPSysLocale 解读，变换为 .NET 字符串；再次输出时，输出的是变换后的字符串，因为字符串已经是 Unicode，不会涉及到 CPConsole ；结果就是：CPProg 按照 CPSysLocale 解读。

如果用 PowerShell 单纯启动语法，你的输出按原字节进入控制台，CPProg 输出将按照 CPConsole 被解读并显示。

注意：自 1803 起，你可以设置 UTF-8 (65001) 为 locale 设置的默认代码页，但在 1709 及更早，不行。此外，PowerShell 的表达式语法包括任何有重定向的情况，而且 PowerShell 会帮你分行，但再次输出的时候原来的行尾信息已经丢失，因此用 PowerShell 直接调用外部命令是一个非常非常糟糕的做法。


安利：如果你要小心地操作文件编码，请使用 cmd 重定向+自己转换编码；或者你可以用我的 Use-RawPipeline PowerShell module。见这里： https://github.com/GeeLaw/PowerShellThingies/tree/master/modules/Use-RawPipeline

@geelaw #15 我删除了代码，用 UI 模拟输入是很困难的，因为 explorer 需要时间反应。

现在提出一个新的做法：启动一个程序，该程序打开数个窗口，用户分别把它们放在不同的虚拟桌面上，然后该程序监听热键，并用 SetForegroundWindow 把那个虚拟桌面上的那个窗口激活，这样就可以切换到那个虚拟桌面了。

@hljjhb #11 这个软件的方法很不好，看了一下是用 https://github.com/Ciantic/VirtualDesktopAccessor 实现的。

后面那个东西 tamper with 虚拟桌面的内部接口，虽然 COM 接口以其稳定性著称，但是 IVirtualDesktopManagerInternal 的 IID 从来没有出现在 MSDN 的文档上，所以理论上可以随时消失掉，这样写的程序随时可能在 Windows 10 的更新里面坏掉。

然后用户就会尖叫：为什么 Windows 兼容性这么差？

总结：请使用被文档化的方法，避免你的程序在下一次更新之后突然坏掉。正确的做法是这样的：

1. 注册全局热键，接收消息；
2. 使用模拟 Ctrl+Windows+Left/Right 来切换虚拟桌面。

随手写了一段：

https://gist.github.com/GeeLaw/b7972135b556d994560c798491371146