Delphi, TPopupMenuItems странно ведут себя после длительного простоя приложения

#delphi #debugging #popupmenu

#delphi #отладка #popupmenu

Вопрос:

У меня проблема, которую я не могу решить. Конечно, здесь я просто ожидаю получить предложение, которое может помочь мне найти решение.

В основном мое приложение заполнено сгенерированными во время выполнения TPopupMenuItem файлами (хотя все TPopupMenu файлы жестко запрограммированы). В некоторых случаях я просто скрываю / показываю или включаю / отключаю элементы, в других случаях я создаю элементы во время выполнения.

Только на некоторых машинах после завершения работы приложения в течение нескольких дней (2 или более) всплывающее меню больше не работает корректно.

Поведение:

все TPopupmenu элементы выглядят одинаково и выполняют одно и то же действие.

Действие выполняется первым TPopupMenuItem приложением (первое генерируется во время выполнения при запуске приложения, это единственная подсказка, которая у меня есть).

Представьте, что в правильном сценарии у меня есть (в 3-элементах- TPopupMenu ):

Пункт 23

Item24

Item25

после проблемы я вижу:

Элемент1

Элемент1

Элемент1

(где Item1 — это элемент, TPopupMenuItem принадлежащий другому TPopupMenu ).

Это вам о чем-нибудь говорит?

Спасибо.

Обновить:

Я попытался просмотреть код моего popupmenus и обнаружил, что может быть общей причиной, и это также объясняет, почему FastMM4 не нашел этого:

    while mnuItem.Count > 0 do
      mnuItem.Delete(0);
  

Удаление (я только что прочитал в документации) не освобождает элемент, вместо этого я должен вызвать free. В любом случае, при закрытии приложения основные всплывающие меню освобождаются корректно, и FastMM4 не жалуется. Так что, вероятно, это решение, теперь я не знаю, почему использовалось удаление, я не писал этот код.

Дальнейшее обновление:

Я попытался создать образец приложения, я не смог воспроизвести проблему, но наверняка я заметил, что использование этого намного более производительно (я попробовал цикл с 10000 рекурсиями):

 while mnuItem.Count > 0 do
      mnuItem.Items[0].Free;
  

Я попробую сделать это в своем приложении (но мне нужно подождать несколько дней, чтобы действительно узнать, возникла ли у меня проблема, в любом случае, наверняка это значительное улучшение).

Комментарии:

1. Можете ли вы показать код, с помощью которого вы создаете PopupMenuItems?

2. Что общего у машин с ошибкой? Та же версия ОС, отсутствуют определенные обновления, физические части на компьютере, запущенные версии вашего приложения отличаются от тестируемой …? 1 для Марьяна нам нужно увидеть некоторый код

3. Да, я добавил, посмотрите мое обновление и, пожалуйста, прокомментируйте его.

Ответ №1:

Я подтверждаю, что проблема была связана с Delete вместо Free. Popupmenu wsa обновлялся каждую минуту на машинах, на которых возникла проблема (так что это не зависело от ОС или HW, просто зависело от конфигурации). Тогда, в соответствии с пользовательскими настройками, в меню могло быть от 10 до 100 пунктов, поэтому, если оставить его без дела на несколько дней, стало возможным достичь предела дескриптора.

Кстати, также нет смысла обновлять всплывающее меню таким образом, поэтому я обнаружил, что оптимизация также устранила ошибку.

Ответ №2:

Вы проверяли утечку памяти и дескрипторы, которые не освобождаются?

Комментарии:

1. да, с FastMM4 я сделал то же самое с FullDebugMode. В любом случае, это то, что я сделал для устранения утечек. Для дескрипторов я проверил количество дескрипторов в Process monitor, но это обычное количество (именно так мне сказали проверять утечки дескрипторов: если это число велико, это означает, что есть утечки дескрипторов… Но, возможно, я ошибаюсь).

2. Вы увидите, что количество дескрипторов со временем увеличивается, если у вас произошла утечка. PS: Я вижу, что дал вам правильный ответ и был первым, кто сделал это, пожалуйста, не забудьте проголосовать 🙂