Delphi，TPopupMenuItems 在应用程序长时间空闲后表现异常
我有一个无法解决的问题。当然在这里我只是希望有一个建议可以帮助我找到解决方案。
基本上我的应用程序充满了运行时生成的 TPopupMenuItem（而所有 TPopupMenu 都是硬编码的）。在某些情况下，我所做的只是隐藏/显示或启用/禁用项目，在其他情况下，我在运行时创建项目。
仅在某些计算机上，应用程序运行几天（2 天或更长时间）后，弹出菜单将不再正常工作。
行为是：
所有 TPopupmenu 项看起来都相同，并且执行相同的操作。
该操作是由应用程序的第一个 TPopupMenuItem 执行的操作（应用程序启动时在运行时生成的第一个操作，这是我拥有的唯一提示）。
想象一下，在正确的场景中，我有（在 3-items-TPopupMenu 中）：
Item23
Item24
Item25
在我看到的问题之后：
Item1
Item1
Item1
（其中 Item1 是属于的 TPopupMenuItem另一个TPopupMenu）。
这告诉你一些事情吗？
谢谢。
更新：
我尝试查看弹出菜单的代码，发现可能是常见原因，这也解释了为什么 FastMM4 没有找到此内容：
while mnuItem.Count > 0 do
mnuItem.Delete(0);
删除（我刚刚在文档中阅读）不释放该项目，我应该调用 free 来代替。无论如何，当关闭应用程序时，主弹出菜单会正确释放，并且 FastMM4 不会抱怨。所以这可能是解决方案，现在我不知道为什么使用删除，我没有编写该代码。
进一步更新：
我尝试制作一个示例应用程序，但无法重现问题，但我肯定注意到使用它的性能要高得多（我尝试了 10000 次递归的循环）：
while mnuItem.Count > 0 do
mnuItem.Items[0].Free;
我会在我的应用程序中尝试一下（但我需要花几天时间才能真正知道我是否遇到问题，无论如何，无论如何，这肯定是一个重大改进）。
I have a problem I cannot solve. Of course here I just expect to have a suggestion that can help me to find a solution.
Basically my application is full of runtime generated TPopupMenuItems (while all the TPopupMenus are hardcoded). In some cases what I do is simply hide/show or enable/disable items, in other cases I create items at runtime.
In some machines only, after leaving the application running for days (2 or more) the popupmenus don't work anymore correctly.
The behaviour is:
all the TPopupmenu items look are the same, and execute the same action.
The action is the one performed by the first TPopupMenuItem of the application (the first generated at runtime when the application starts, this is the only hint I have).
Imagine in correct scenario I have (in a 3-items-TPopupMenu):
Item23
Item24
Item25
after the problem I see:
Item1
Item1
Item1
(where Item1 is the TPopupMenuItem belonging to another TPopupMenu).
Does this tell you something?
Thanks.
Update:
I tried to look at the code of my popupmenus and I found what could be a common cause, and this explains also why FastMM4 didn't find this:
while mnuItem.Count > 0 do
mnuItem.Delete(0);
Delete (I just read in the documentation) doesn't free the item, I should call free instead. Anyway when closing the application the main popupmenus are freed correctly, and FastMM4 doesn't complain. So this is probably the solution, now I don't know why Delete was used, I didn't write that code.
Further update:
I tried to make a sample application, I couldn't reproduce the problem, but for sure I noticed that using this is much more performant (I tried a loop with 10000 recursions):
while mnuItem.Count > 0 do
mnuItem.Items[0].Free;
I will try for this in my app (but I need to let some days pass to really know if I got the problem, ayway for sure this is a major improvement anyway).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我确认问题与“删除”而不是“免费”有关。 Popupmenu wsa 在出现问题的计算机上每分钟刷新一次（因此它不是特定于操作系统或硬件，只是特定于配置）。然后，根据用户设置，菜单可能有 10 到 100 个项目，因此闲置数天可能会达到手柄限制。
顺便说一句，以这种方式刷新弹出菜单也是没有意义的，所以我发现优化也删除了一个错误。
I confirm that the problem was linked to Delete instead of Free. Popupmenu wsa refreshed every minute on the machines that had the problem (so it was not OS or HW specific, just config specific). Then according to user settings the menu could have 10 to 100 items, so leaving it idle for days made it possible to hit the handle limit.
By the way it also makes no sense to refresh the popupmenu in that way, so I found also an optimizaion removed a bug.
您是否检查了内存泄漏和未释放的句柄？
Did you check for memory leakage and handles that aren't freed?