是否有可能找出 GDI 对象泄漏的原因

发布于 2024-11-11 02:37:46 字数 1039 浏览 2 评论 0原文

我在 Embarcadera RAD Studio 2010 (C++) 中有一个应用程序。是否可以查看它以查看泄漏的 GDI 对象?当文本设置为粗体时,树形结构菜单会泄漏 GDI 对象。我的猜测是,“原始”文本首先被创建,然后是一个以粗体显示的实例,第一个文本被“遗忘”并泄露。

编辑:由于使用 AQTime 没有报告泄漏,尽管通过查看任务管理器很明显,我跟踪了创建而不是释放 GDI 对象的代码片段。

...

Msg.WParam=(int)PhysicalListView->Canvas->Handle;
PhysicalListView->Dispatch(&Msg);

... 

PhysicalListView是一个指向TListView的指针。据我了解,以 T 开头的类是标准 Embarcadero 类的一部分(正确吗?)。

当我在列表视图中选择一个带有未修饰文本的子节点时,一切正常。但是,当一个或多个子级具有粗体下划线文本时,例如,GDI 计数在 Dispatch 调用后不会减少。

所以我的猜测是这是 TListView 类中的错误。我不知道这是否适用于 WinForms 或者它是否使用它自己的解决方案?

此外,这种情况发生在调试模式下。我会在编译发布版本时检查问题是否消失。如果是这样,则表明 TListView 的调试版本中存在泄漏。

EDIT2:我想我已经发现了这个问题。发送的初始消息包括 WM_PAINT ,在阅读该消息后,该消息不应由客户端应用程序发送,而是由系统使用。所以我将其更改为 WM_PRINT 并且泄漏消失了。我不知道为什么使用 WM_PAINT,也许我缺少它的一些功能...知道为什么他们会使用 WM_PAINT 吗?

I have an application in Embarcadera RAD Studio 2010 (C++). Is it possible to peek into it to see what would be leaking GDI Objects? A tree structured menu is leaking GDI Objects when text is set to Bold. My guess is that the "original" text is first created and then an instance where it is in bold and the first one is "forgotten about" and leaked.

EDIT: Since no leak is reported usin AQTime, even though is obvoius by looking at Taskmanager, I traced the snippet of code that is creating and not releasing GDI Objects.

...

Msg.WParam=(int)PhysicalListView->Canvas->Handle;
PhysicalListView->Dispatch(&Msg);

... 

PhysicalListView is a pointer to a TListView. As I understand it the classes that start with T is part of the standard Embarcadero classes (correct?).

When I have selected a node in the listview with children that have undecorated text everything works fine. But when one, or more, of the children have bold or underlined text for example the GDI count does not decrease after the Dispatch call.

So my guess is that this is an error in the TListView class. I don't know if this works against WinForms or if it uses it's own solution?

Also, this occurs in Debug mode. I will check if the problem goes away when compiling a release build. If so it indicates a leak in the debug versions of TListView.

EDIT2: I think I have uncovered the problem. The initial message sent included a WM_PAINT and after reading about it this message should not be sent by a client application but is instead used by the system. So I changed this to a WM_PRINT and the leak went away. I don't know why a WM_PAINT was used, prehaps I'm missing some functionality of it... Any ideas why they would have used WM_PAINT?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

地狱即天堂 2024-11-18 02:37:46

Memory Validator是我们在工作中使用的一个工具,它可以处理所有类型的内存泄漏,包括 gdi 对象。

Memory Validator is a tool we use at work, which handles all types of memory leaks, including gdi objects.

木落 2024-11-18 02:37:46

AQTime 是我选择的工具。它是一个分析器,除了 GDI 泄漏检测之外还提供了更多功能。 RAD Studio XE 附带 AQTime 的标准版本。对于专业版,您需要支付更多费用。

AQTime is my tool of choice. It's a profiler and brings many more features than just GDI leak detection. RAD Studio XE comes with the Standard version of AQTime. For the Pro version you need to pay more.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文