Delphi, TPopupMenuItems behaving strangely after the application is idle for a long time

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 TPopup开发者_高级运维MenuItem 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).

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?