Очередь сообщений Windows: Как проверить nbr «опубликованных сообщений в процессе» очереди сообщений из C # - PullRequest
0 голосов
/ 07 марта 2019

(Мы разрабатываем приложение на C #, WinForms + WPF, VS 2017, .NET Framework 4.7.1 +)

Мы столкнулись с проблемой, связанной с этой ошибкой:

Win32Exception (0x80004005): Недостаточно квоты для обработки этой команды.

Я читал об этом множество ресурсов, так как:

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

У нас есть много UserControls, WinForms, а также некоторые элементы управления WPF, которые все обновляются автоматически с удаленного сервера.Все UC способствуют отправке сообщений в очередь, поэтому речь идет не просто о проверке one UC, а о сумме всех UC, которые создают эту проблему.

Вот мои вопросы:

  1. Для каждого окна существует одна очередь сообщений, поэтому, если мы разрабатываем приложение C # WinForms для настольных компьютеров, существует одна и только одна очередь сообщений для всего приложения, верно?
  2. есть ли в коде (C #) способ просмотреть очередь сообщений и посмотреть, приближаемся ли мы к пределу, 10 000 в секунду?Нам понадобится некоторый базовый счетчик, который может продолжать подсчет / проверку независимо от того, где мы находимся в приложении, и, предпочтительно, посмотреть, какая часть кода в основном отвечает за это.
  3. Есть ли разница между пользовательским интерфейсомэлементы "отображаются асинхронным способом" против синхронизации? Во второй ссылке говорится, что «здесь слишком много элементов UIE воспроизводится асинхронно».У меня есть код, который делает this.Dispatcher.Invoke, так что это синхронизация, верно?Я не понимаю, почему это так важно, это все еще сообщение, отправленное в очередь?
  4. В одном UC мы используем Dispatcher.Invoke и устанавливаем System.Windows.Threading.DispatcherPriority в SystemIdle.Что это на самом деле делает?

Я также хотел поделиться одним методом в одном из множества UserControls.Это элемент управления WPF, и этот метод вызывается для обновления графического интерфейса.Его вызывали много раз, для каждого элемента или обновления.Однако мы сделали то, что этот метод не вернется, пока done не станет true.Означает ли это, что очередь сообщений обработала и обработала сообщение и больше не находится в очереди, поскольку мы используем this.Dispatcher.Invoke, поэтому это сообщение синхронизации?

    void RunOnGUIThread(Action callback)
    {
        bool done = false;

        if (this.Dispatcher.Thread != System.Threading.Thread.CurrentThread)
        {
            this.Dispatcher.Invoke(delegate
            {
                try
                {
                    callback.DynamicInvoke(null);
                    done = true;
                }
                catch (Exception e) { }
            }, System.Windows.Threading.DispatcherPriority.SystemIdle);
        }
        else
        {
            callback.DynamicInvoke(null);
            done = true;
        }
        while (!done)
            System.Threading.Thread.Sleep(1);
    }

Как правило, мы имееммного информации в настольном приложении, некоторые с фиксированными меню, которые всегда видны, другие элементы управления загружаются при навигации по приложению и т. д. Многие данные автоматически обновляются с удаленного сервера, если что-то происходит с данными, поэтому стоитеще раз отметим, что на очередь сообщений, вероятно, влияет множество различных UC, и они обновляются на лету, в режиме реального времени.

Любые другие советы и указатели, как отлаживать или обрабатывать это в Visual Studio 2017/ C #?

...