2008年（909）
分类：
2008-05-06 22:25:24
下载源代码：CATWork0503.exe (184KB)
原文出处：Making
Static Links Keyboard-Capable, Launching URLs from Your App
这几年我一直在公司的商业程序中使用你的 CStaticLink
类，在 1998 年 MSJ 三月刊里，你示范了如何给超链接添加手型光标，但现在我想以另一种方式使用这个类。在微软的 IE
浏览器中，可以用Tab键遍历Web页面中的任何超链接，然后按回车键以单击该链接。我能否让 CStaticLink
做同样的事情？我是不是有点得寸进尺？
如果你要我借给你一千美元，那才是得寸进尺呢——但用键盘操作 CStaticLink
则是合理要求。我可以想象得到，对于一个习惯用键盘的人来说尤其如此。我讨厌伸手去用无聊的鼠标（这就是为什么我用 Emacs
的原因），并且我讨厌部提供足够键盘支持的应用程序。所以你的要求一点都不过分；相反，你应该获得用户界面最优奖。
void CStaticLink::OnSetFocus(CWnd* /*pOldWnd*/)
{
DrawFocusRect();
}
void CStaticLink::OnKillFocus(CWnd* /*pNewWnd*/)
{
DrawFocusRect();
}
是不是很简单？即便是用户因为切换到其它程序而失去焦点（与用Tab移到其它控件相对），它们都能照样工作。/////////////////////////////////////////////////////////////////////////
// 获得或丢失焦点: 绘制焦点矩形。对于位图，用窗口矩形；文本则用实际文本矩形。
/////////////////////////////////////////////////////////////////////////
void CStaticLink::DrawFocusRect()
{
CWnd* pParent = GetParent();
ASSERT(pParent);
// 计算在哪里绘制焦点矩形，用屏幕坐标
CRect rc;
DWORD dwStyle = GetStyle();
if (dwStyle & (SS_BITMAP|SS_ICON|SS_ENHMETAFILE|SS_OWNERDRAW)) {
GetWindowRect(&rc); // 图像使用全窗口矩形
} else {
// 文本使用文本矩形. 不要忘了选字体!
CClientDC dc(this);
CString s;
GetWindowText(s);
CFont* pOldFont = dc.SelectObject(GetFont());
rc.SetRectEmpty(); // 重要—DT_CALCRECT 展开, 以便起始是空
dc.DrawText(s, &rc, DT_CALCRECT);// 计算文本方块区
dc.SelectObject(pOldFont);
ClientToScreen(&rc); // 转换屏幕坐标
}
rc.InflateRect(1,1); // 周围添加一个像素
pParent->ScreenToClient(&rc); // 转成父窗口坐标
CClientDC dcParent(pParent); // 父窗口的 DC
dcParent.DrawFocusRect(&rc); // 绘制!
}
大多是常规的 GDI
处理——选择字体，转换坐标等等——我只列出关键代码。
void CStaticLink::OnChar(UINT nChar,...)
{
if (nChar==VK_SPACE) {
Navigate();
}
}
但是在你的静态链接能够得到 WM_CHAR 消息之前，你必须告诉对话框你对这个消息感兴趣。通常静态控件得不到 WM_CHAR
消息（记住：因为它们是静态的）。有一个特殊的消息可以告诉对话框你想得到什么——这个消息就是 WM_GETDLGCODE：UINT CStaticLink::OnGetDlgCode()
{
// 告诉对话框我想要 chars
return DLGC_WANTCHARS;
}
完成上述工作便万事俱备。现在当用户用 Tab 键到达超链接上时，按下空格键便可以导航了。酷。
最后是一个警告：小心选择正确的静态链接Tab顺序。你的超链接通常应该在Tab顺序的最后，即使它们出现在对话框的最前面。你可能不想让你的对话框一启动输入焦点就落在公司（
ACME ）标徽链接上。并且如果你在具有其它控件的窗体/对话框中使用 CStaticLink，你可能不想Tab键从某个编辑框跳过超链接到另外一个编辑框或按钮。所以我的忠告是保持所有超链接在Tab顺序的最后，除非你有充足的理由不这样做。
我写了一个例子程序 LinkTest，它使用新的具备键盘操作能力的 CStaticLink。请下载代码参考细节。
我有一个 MFC 程序，调用 ShellExecute 来打开一个
Web 页面。如：
ShellExecute "
在我使用托管扩展前，运行正常，但是一使用托管扩展它就不行了。返回的错误代码是5，在 WinError.h 中是 ERROR_ACCESS_DENIED。我不懂为什么会存取失败。ShellExecute
不能与托管扩展一起用吗？
你是众多遇上这等不幸怪事的人之一。没错，只要你设置 /clr
开关来使用托管扩展，那么当你尝试用 ShellExecute 打开 Web 页面时会失败。我也曾经一度被它绊倒。托管扩展和 /clr 对 ShellExecute
做了些什么手脚呢？为什么会产生存取违例？
Windows 中常发生这种事情，错误代码提供的信息很难确定到底发生了什么。但通过搜索 MSDN 库，有一篇名为“Calling Shell
Functions and Interfaces from a Multithreaded Apartment”的文章揭示问题的答案。很多年前，ShellExecute
就谦卑地开始了其一生；其功能无非是让你运行一个程序，也就是一个 EXE 文件。随着 Windows 变得越来越复杂，ShellExecute
也成长为几乎可以“执行”任何程序——例如一个磁盘文件（用关联程序打开文件），FTP 协议或者 Web
页面——只要将文件名或URL传递给它即可。它是通过外壳扩展和 IShellExecuteHook 实现的，IShellExecuteHook 是一个
COM 接口，这个接口通过告诉它如何“执行”传递到 ShellExecute(Ex) 的串来扩展外壳。例如，有一个 HTTP
协议扩展钩，它处理以“http://”开始的串。扩展处理例程启动默认的浏览器打开给定的 URL。
问题是用 /clr 和托管扩展强制你的应用程序进入多线程模式，因为垃圾收集器拟在单独的线程中异步运行。但是按照 INFO 文章的解释，许多 IShellExecuteHook
扩展之所以在多线程环境不工作，是因为它们没有所需的用于 COM
封送参数的代理/存根（proxy/stub）以及进行同步存取的代码。如果你对此感到困惑，那么很多人和你一样。但我只想说，ShellExecute
在所有多线程环境下都无法正常工作。
所以，如果你已经使用托管扩展，为什么不用.NET框架的Process类和 Process::Start 来代替 ShellExecute
呢？有一个静态重载正好是你想要的：
Process::Start(");
哦，回来一试，还是不行。此调用丢出 Win32Exception 异常，它甚至在 NativeErrorCode
属性中产生更莫名其妙的错误代码：ERROR_SXS_KEY_NOT_FOUND。此错误的描述是：“请求的查找键在所有的活动上下文中未找到。”怎么回事呢？
如果你认真看一看 Process 的文档，你会发现 Process 使用一个叫 StartInfo 的东西来告诉它如何启动该进程。StartInfo
的属性之一便是 UseShellExecute。默认情况下，UseShellExecute 为 True，由此告诉框架用外壳启动进程，也就是说用 ShellExecuteEx。好了，试一下将它置成
False。结果正像文档所说的，你只能启动 EXEs，而非文件名或URLs。两种方法都行不通，你在兜圈子。
再仔细看看 Process::Start 的文档，它告诉你如果你想用 UseShellExecute，你必须保证指 定 [STAThread]（单线程公寓模型）作为应用程序
main 函数的特征：
// in C#
public class MyForm : Form {
[STAThread]
public static void Main(string[] args) {
...
}
}
那么，对 C# 或者是“纯”（非 MFC）C 程序能行得通，它们有自己的 main 函数，但 MFC
程序怎么办？如果是那样的话，main，_tmain，_tWinMain 或任何平台入口点都深藏在 MFC 内部，无法编辑源代码添加 [STAThread]。你可以使用
/ENTRY:MyMain 并编写自己的调用 CRT 启动例程的 [STAThread] MyMain，碰到这种情况太糟了。肯定有比这个简单的方法。
实际上，在 MFC 应用程序中有一种强制线程为单线程（STA）模型的方法，而不使用 [STAThread]。你只要在框架试图调用 CoInitializeEx(COINIT_MULTITHREADED)
之前调用 CoInitialize(NULL) 即可。用一个小类来做这件事情。代码如下：
//////////////////////////////////////////////////////////////////////////
// 用此类在混合模式应用程序中强制 STA (单线程公寓模型) 线程。使用方法如下：
// 在你的 main 应用模块中建一个静态实例，例如，MyApp.cpp 或在进入 CLR 之前要
// 运行构造函数的任何地方。
//////////////////////////////////////////////////////////////////////////
class CSTAThread {
public:
CSTAThread() {
CoInitialize(NULL);
}
~CSTAThread() {
CoUninitialize();
}
};
构造函数调用 CoInitialize(NULL)（STA 线程）和析构函数调用 CoUninitialize。所以只要象下面这样在 MFC
程序的 main 中插入一个实例即可：
// 这样做效果与 [STAThread] 一样 CSTAThread forceSTAThread;
真是聪明。（感谢微软的 Martyn Lovell 给我提出这个建议）。在 Visual C 2005
中，你可以告诉链接器你的入口点使用 STAThread，但目前你得用 CSTAThread。
还有一个方法可以在应用程序中启动 URLs，它甚至可以用于多线程模式，这个方法就是 rundll32.exe，这个程序很方便，用它可以调用任何
DLL 中的函数。你只要给它提供 DLL、函数名以及要传递的参数即可。Rundll32.exe 绝对多才多艺，你可以用它来关闭和重启
Windows，创建快捷方式以及启动控制面板程序。我见过一个专门研究 rundll32.exe
使用技巧的网站；只要知道要调用的DLLs，一切都搞掂。你可以象下面这样用 rundll32.exe 从命令行打开一个 URL：
rundll32.exe url.dll,FileProtocolHandler
url.dll 中的函数 FileProtocolHandler 负责这个工作。如果使用 ShellExecute，可以象下面这样写：
LPCTSTR url = _T("");
CString args;
args.Format(_T("url.dll,FileProtocolHandler %s"), url);
ShellExecute(NULL, _T("open"), _T("rundll32.exe"), args);
即便是在多线程应用中这都是可以行得通的，因为你赋予 ShellExecute 的是一个真正的 EXE，而不是一个外壳扩展和 IShellExecuteHook
运行必须的文件名。唯一的缺点是一旦打不开 URL，你得不到任何错误返回码。因此，我推荐使用 CSTAThread，并直接用 ShellExecute
来调用 URL，尤其是在 MFC 程序中，不管怎样，它与公寓模型线程配合得很好。
作为实践的例子，我更新了第一个问题中的 CStaticLink 类，使用 CSTAThread 和 ShellExecute，并编写了一个托管测试程序，LinkTest，为了证明它能在托管模式下正常运行。我在 StatLink.h
中包含了 CSTAThread 类。所以现在 CStaticLink 又多了一个特性：不管是本机应用还是用 /clr
编译以及托管扩展，它都能正常运行。具体细节请下载源代码。
祝编程愉快！