本文介绍了是否有可能找出泄漏GDI对象的原因的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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.

编辑:由于在AQTime中没有泄漏的报道,即使通过查看Taskmanager来观察它是不愉快的,我也跟踪了正在创建而不释放GDI对象的代码片段。

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 是一个指向 TListView 的指针。据我了解,以 T 开头的类是标准Embarcadero类的一部分(正确吗?)。

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?).

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

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.

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

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?

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

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:我想我已经发现了问题。发送的初始消息包括 WM_PAINT ,阅读此消息后,客户端应用程序不应发送此消息,而应由系统使用。因此我将其更改为 WM_PRINT ,泄漏消失了。我不知道为什么使用 WM_PAINT ,也许我缺少它的某些功能...关于为什么他们会使用 WM_PAINT 的任何想法?

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?

推荐答案

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.

这篇关于是否有可能找出泄漏GDI对象的原因的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-05 14:28
查看更多