2008年（909）
分类：
2008-05-06 22:10:29
原文出处：January
2001 issue of MSDN Magazine
原代码下载：CQA0101.exe（47KB）
如何在注册表中查找默认浏览器位置的定义？我需要知道EXE文件的路径和名称以便启动一个应用程序会话。我的目的很简单，就是打开默认的浏览器，这样用户能够象普通程序一样使用它，而不是在我设计的程序窗口内浏览因特网。
据我所知，在Window中没有专门指定默认浏览器的注册表键值或设定值。即使专家也很难弄清楚整个注册表，更何况常人。我知道可能存在这样一个键值，
HKCU\System\Mumble\Bletch\Blah\Gak\DefaultBrowser
如果你知道这样的键值，请写信告诉我。不过，我知道一个简单的解决办法，那就是查找哪个程序和HTML文件相关联。在Window操作系统中HTML文件的后缀通常为.htm和.html，所以你要做的就是查找HKCR/.htm的键值。如果你查找了会找到下面的键值：
HKEY_CLASSES_ROOT\.htm="htmlfile"
再根据这个键值查找HKCR/htmlfilm的条目，你会找到下面的键值：
[HKEY_CLASSES_ROOT\htmlfile\shell\open\command] @="\"C:\\PROGRA~1\\INTERN~1\\iexplore.exe\" -nohome"
这个键值表明Microsoft Internet Explorer (iexplore.exe)是用来打开.htm文件的程序。（－nohome开关标志告诉IE浏览器不要打开主页）如果默认的浏览器是Netscape，这个条目会是这样：
[HKEY_CLASSES_ROOT\htmlfile\shell\open\command] @="\"C:\\PROGRA~1\\NETSCAPE\\netscape.exe\".
我的回答满意吗？
我想为对话框的一个按钮设置不同的光标，应该如何进行设置？
有两种方式可以改变窗口中的光标：你可以在注册窗口类时声明一个全局光标（HCURSOR)作为WNDCLASS结构的一部分，或者通过处理WM_SETCURSOR消息来手工设置光标。标准的MFC程序采用第一种方式设置光标，它自动为主窗口注册一个箭头光标。你可以在主窗口或子窗口中通过处理WM_SETCURSOR消息来改写这个行为。
// 在按钮类中处理WM_SETCURSOR消息
BOOL CMyButton::OnSetCursor(CWnd* pWnd, UINT nHitTest, UINT msg)
{
::SetCursor(m_hMyCursor);
return TRUE;
}
不管什么时候，当用户将鼠标移动到按钮上并且鼠标没有被捕获时，Windows 会发送一条WM_SETCURSOR消息给按钮。它传递一个窗口句柄——即鼠标指针指向的窗口，
此时就是按钮本身；击中测试码——即在WM_NCHITTEST消息中使用的HTXXX码（见
Figure 1）；和一个触发事件的消息ID，比如说它触发了WM_MOUSEMOVE事件。设置鼠标
光标的最佳机会就是在处理WM_SETCURSOR消息的时候。如果要这么做，你必须返回TRUE以阻止窗口默认的处理过程。
此时处理会如何进行呢？首先窗口默认的处理过程向父窗口（如果有的话）发送WM_SETCURSOR消息到父窗口。如果父窗口处理了WM_SETCURSOR消息（就是说它返回了TURE），Windows就不做什么了，
该消息就算处理完了。如果父窗口没有处理WM_SETCURSOR消息（返回FALSE)，Windows就给子窗口一个处理这条消息的机会。假如子窗口也没有处理该消息（返回FALSE)，Windows就使用全局光标，要是连全局光标也没有，则使用箭头光标。
这些意味着什么？这意味着在需要动态设置光标时，你要决定是在子窗口还是在父窗口处理WM_SETCURSOR消息。两个选择都可行，这取决于实际情况。一般来说，最好让对象决定自己的属性，这就是说最好在子窗口处理消息。本例中子窗口是指按钮。但这需要从CButton类继承一个新的按钮类，让它有自己的消息映射和其
它一些必要的属性，如果你是乐于使用 Class
Wizard 的人（有没有人用它啊？），这意味着需要多敲几下键盘或多点几次鼠标。如果你已经具备了自己的按钮类，那我明确的告诉你在这个子类中处理WM_SETCURSOR消息。要是你没有自己的按钮类而且你
又是个懒人，那就在对话框里处理WM_SETCURSOR消息也行。不过千万不要告诉别的面向对象专家，是我要你这么干的！
Figure 2 按钮上设置的光标
我写了一个简单的基于对话框的应用程序，NoCursor，来举例说明这两种方法。如果你把鼠标移动到一个按钮上（OK或Cancel），光标变成蓝色的指示手指（见
Figure 2）；该功能通过处理对话框类的OnSetCursor函数实现（见
Figure 3）。另外，当你把鼠标移动到带下划线的超级链接上时，光标变成另一种不同的指示手指。该功能是在子类CStaticLink里实现的（见
Figure 4）。CStaticLink是在我的专栏里经常出现的一个多用途超链接类（见
Figure 5）。CStaticLink::OnSetCursor函数中的大部分代码是处理如何从winhlp32.exe获得适合的手形光标资源，就光标设置而言这些代码无关
紧要，故省略。如果你对这些细节很感兴趣，可以象往常一样从本文顶部的链接下载全部代码。
Figure 4 超级链接上设置的光标
我获得一个含有对话框的库（当然也就包括一些资源ID）。当我在主程序中使用这个库时，库中的资源ID和主程序的资源ID发生了冲突。结果是，要显示库中的对话框时却弹出了主程序中的对话框。要怎样做才能避免冲突？难道要手工对库中的资源ID进行设置吗？
唉，这个问题没有特别令人满意的答案，只有一些曲线救国的办法。该问题的实质在于Windows中的每个资源必须从属于某个模块（EXE或DLL），而在每一个模块中，特定资源不能有相同的名称或ID。就DLL（动态链接库）而言不存在这样的问题，因为DLL本身就有和主程序不同的HINSTANCE句柄。但对静态链接库来说，所有资源在同一个EXE文件内共存，就像一个大家庭的成员共同生活在一起一样。当然，像家庭成员可能发生冲突一样，资源
也存在发生冲突的可能性。// 在主应用程序rc文件 #include "libres.h" // ID 标识符 #include "libres.rc" // 资源这里libres.rc是包含库中所有对话框、光标和其他资源的资源文件。头文件libres.h以基本值偏移量的方式规定了libres.res中使用的资源ID。
// 在libres.h文件中 #ifndef LIBBASEID #define LIBBASEID 2000 // 或其他值 #endif #define IDR_FOO (LIBBASEID 1) #define IDR_BAR (LIBBASEID 2) // 等等只要改变LIBBASEID的值，使用这个库的程序员可以方便地重新映射所有资源ID，例如：
// 在主程序rc文件 #define LIBBASEID 3000 #include "libres.h" #include "libres.rc"现在所有的ID从3000开始而不是2000，在实际当中这个办法很有效，但它有一个麻烦的问题，那就是它需要用户重新编译库以改变ID。如果重新编译库是不可行的（也许你不想提供源代码），还有一些其 它的办法。要是程序员改变了LIBBASEID，只有当他直接使用IDR_FOO或其他资源ID时，才需要重新编译库。也就是说，在库中直接引用了这些资源ID：
BOOL SomeLibFn(...)
{
DialogBox(..., IDR_FOO, ...);
}
可以不直接引用这些资源ID,方式之一就是把它们作为调用函数的参数传递。
BOOL SomeLibFn(..., UINT nDlgID)
{
DialogBox(..., nDlgID, ...);
}
现在你不用担心库中的资源ID会发生冲突，因为主程序一定支持它们。改变LIBBASEID值的用户不用也不能重新编译库，因为所有ID是作为函数值传入的。当然这个方法要求编写主程序的程序员必须编辑库中的rc文件以设置ID，还是有点麻烦。更好的办法是以全局静态变量而不是固定的ID值作为偏移量的基本值。
// 在头文件中 extern UINT LibBaseId; #define IDR_FOO (LibBaseId 1); #define IDR_BAR (LibBaseId 2); // 等等
// 在库中主模块 UINT LibBaseId = 2000;假如现在发生冲突，应用程序可以在启动时改变LibBaseId值（也许是通过一个函数），然后重新编译主程序即可。唉，但这对RC文件不起作用。我曾经说过RC文件的语法并不是纯C/C 语法，而只是其一个子集，所以RC文件不知道extern和UINT是什么。要使资源编译器理解这些符号，你需要使用另外的头文件，或者采用更简便的方法，使用宏RC_INVOKED,这样这些符号就可以放在同一个头文件当中。
// 在libres.h头文件中 #ifdef RC_INVOKED #ifndef LibBaseId #define LibBaseId 2000 #endif #else extern UINT LibBaseId; #endif #define IDR_FOO (LibBaseId 1); #define IDR_BAR (LibBaseId 2); // 等等一般来说，包含在RC文件中的头文件不能包含除＃define以外的C代码。 采用这种方法，使用你的库的程序员必须做两件事来重新映射库中的资源ID。第一步，在把libres.h包含到主RC文件之前，他们必须重新＃define LibBaseId一个新值。第二步，他们必须在主应用程序的启动代码中（比如在CWinApp::InitInstance函数中）将LibBaseId初始化为同样的值。 最后，有另外一种更简单的解决资源ID冲突的办法：使用字符串而不是数值来映射资源ID。
// 在libres.h头文件中 #define IDR_FOO "MyApp_IDR_FOO" #define IDR_BAR "MyApp_IDR_BAR" //等等使用字符串映射资源ID的效率并不高，因为不仅它们占用空间多，而且查找字符串映射的资源比查找整数映射的资源慢。如果你库中有几百个用于字符串或其他使用频率高的资源ID，我建议你使用整数映射ID并且采用前面提出的一种解决方法。但假如你库中的资源就是几个对话框，那使用字符串映射资源ID是再好不过了。没有人会注意多用了5毫秒显示对话框，并且资源ID冲突的可能性几乎为零。