问题标签 [handle]

Windows 窗体有一个属性 win1.Handle，如果我记得，它返回主窗口句柄的句柄？

是否有等效的方法来获取 WPF 窗口的句柄？

我在网上找到了以下代码，

但我认为这对我没有帮助，因为我的应用程序有多个窗口。

谢谢！！

我有一个 Win32 事件句柄数组，我正在等待使用 WaitForMultipleObjects()。这将返回触发的事件数组中的索引，但我需要知道的是事件的名称。我一直在浏览 MSDN，但看不到任何可以做到这一点的东西。

基本上我有一个类，它使用 RegNotifyChangeKeyValue() 在定义的时间段内通过事件监视注册表，但在它启动其他类之前注册对键和值感兴趣。然后我在一个单独的线程上等待并报告已修改的键的名称。事件名称是事件的关键，直到运行时我才知道其中有多少或它们将被调用。我不想为每个键创建一个线程，因为它的性能不是很好。

有谁知道如何获取事件名称或更好的方法？

LogonUser 函数http://msdn.microsoft.com/en-us/library/aa378184(VS.85).aspx返回一个句柄，您可以使用它来模拟用户，当您完成使用它时，您调用 CloseHandle 关闭它。我的问题是，如果登录尝试失败（即错误的用户名或密码），您是否需要关闭句柄？

我们有一个用 Java 编写的相当大而复杂的应用程序，它运行在 Gridgain 包之上。我遇到的问题是，在每个请求开始之前，此应用程序将在那里处理请求大约一天，从而导致 java.nio.channels.ClosedByInterruptException 类型的异常。

我的假设是应用程序没有释放文件句柄，并且在连续使用一天后它耗尽并且不能再继续处理请求（每个请求都需要从每个网格节点读取多个文件）。我们已经将大部分文件 IO 操作包装在诸如此类的类中

我认为问题在于这种设计没有明确释放文件句柄，我提出的解决方案是添加这样的 finalize 方法

这将明确地做到这一点。问题（最后）是这是否可能产生任何影响。诸如 java.io.BufferedReader 之类的类是否已经具有处理此类问题的某种机制？

编辑：这里也非常感谢检查这是否真的是问题的方法......即有没有办法查询正在运行的JVM并询问它的文件句柄分配？

有没有办法从 CDialog 派生类（如 CWnd::m_hWnd 成员）中检索窗口句柄？

谢谢

假设我有一个创建文件并向其写入数据的 Windows 应用程序。应用程序已以独占方式打开文件，因此其他进程无法读取文件中的数据。

如果进程被杀死，则文件被删除。

如果进程被挂起并且文件的句柄被关闭（使用进程资源管理器），则文件被删除。

这一定是 Windows 的一个特性导致的，因为进程中没有更多的代码运行，因为它被杀死或挂起。

怎么会这样？什么类型的文件表现出这种行为？

我正在尝试处理特定表单上的 mouseclick 事件，如果鼠标光标落在一组坐标之间应该触发 - 比如说一个正方形。

我知道如果我有一个空表单，我可以简单地绑定到 mousemove 事件然后我就走了。但实际上可能有多达 10 个不同的重叠控件，并且在我的测试应用程序中，mousemove 事件仅在光标位于实际表单本身而不是在子控件上方时才会触发。

当设计时有未知数量的子控件时，有谁知道如何处理此事件？

我可以使用简单的单线吗？

我们如何获得没有标题的窗口的句柄？有没有办法枚举桌面上的所有窗口并过滤没有标题的窗口（在我的情况下，只有一个）并获取它的句柄..或通过指定其他属性，如具有特定的按钮或列表框等...

我正在调试这个数据库项目。它为更高级别的应用程序包装了对 SQLite 的访问。它被设计为异步运行，也就是说，它具有 ExecuteRequestAsync() 和 IsRequestReady() 等方法。当调用 ExecuteRequestAsync 时，它会产生一个 boost::thread 来完成这项工作并立即返回该函数。当更高级别的应用程序决定它不再想要运行请求的结果时，它可以调用 DumpRequest() 来取消它。由于很难优雅地取消数据库请求，因此 DumpRequest 的实现只是维护一个“清理监视器线程”，等待“完成的请求”并删除它们。所有 boost::threads 都通过 boost::shared_ptr 进行管理，例如：

当不再需要（被取消）时：

我创建了这个单元测试项目来测试执行和转储请求的机制。它运行请求并随机取消正在运行的请求，并重复数千遍。结果证明机制没问题。一切都按预期工作。

但是通过sysinternal的Process Explorer观察单元测试项目，发现有句柄泄漏问题。每 500 次通过，句柄计数增加 1，并且永远不会返回。增加的是“事件”类型的句柄。文件和线程句柄没有增加（当然，随着线程的产生，句柄的数量也在增加，但是每一百次调用 Sleep(10000) 以等待它们被清理，以便可以观察到句柄计数）。

我自己没有管理事件句柄。它们是由 boost::thread 在创建线程时创建的。我只保证优雅地关闭线程，我不知道事件的用途。

我想知道是否有人遇到过类似的问题？这种泄漏的原因可能是什么？Process Explorer 中的这个数字是否足够可靠，可以称之为句柄泄漏？有没有办法追踪和修复它？

我在 Windows Vista 上使用静态链接的 boost 1.40 和 Visual C++。

我有一个大型旧程序，它有一些相当复杂的图形显示（全部通过标准 API 调用）。该程序似乎运行良好，但我最近在该程序运行时查看了 Windows 任务管理器的“句柄”字段，并注意到句柄的数量逐渐且无情地向上攀升。

是否有一些软件或策略可以用来追踪这个流氓句柄的创建？

我希望该程序会创建大量句柄，但我也希望这会达到一个限制。所以我真正想看到的是代码的哪一部分创建了最新的句柄。

编辑：在对“进程资源管理器”进行一些调查后，我发现正在蔓延的是“句柄”而不是“GDI 句柄”。所以我想这意味着它与复杂的图形无关。