DoEvents в DLL
Ответы 4
Не надо. Это достаточно схематично, когда вы - приложение, контролирующее цикл событий; перекачка сообщений из DLL только увеличивает риск того, что вы в конечном итоге столкнетесь с кодом, который наивный программист не сделал безопасным для повторного входа.
@Anthony, именно поэтому вы не должны использовать его в DLL, особенно не в DLL, которую вы без исходного кода будете передавать кому-то другому. К сожалению, если вы не можете полностью отказаться от библиотеки, вы, вероятно, застряли, пытаясь понять, как написать свое приложение на основе эгоистичного поведения этой сторонней DLL ... я вам сочувствую!
Можете ли вы дать альтернативу: while(true) { if (something) break; Application.DoEvents(); //or your solution }
Да, chouaib: while(true) { if (something) break; } //don't call this from a UI thread
Вы имеете в виду System.Windows.Forms.Application.DoEvents()?
Я согласен. Как и любой другой инструмент, бывают случаи, когда это хорошая идея, а иногда - плохая. Однако это решать разработчику, не так ли?
@configurator: если разработчику принадлежит код обработки сообщений для потока, то да. Если разработчик пишет DLL, загруженную и вызываемую потоком, которым он не владеет, то нет.
Напишите интерфейс для EXE и пусть ваша основная форма или основной класс реализует его. Затем зарегистрируйте этот объект, реализующий интерфейс, с помощью DLL. Назначьте его переменной этого типа интерфейса Сделайте подпрограмму, которая будет видна во всей DLL. В подпрограмме проверьте, является ли переменная ничем, если это не так, тогда подпрограмма, которая запускает созданный вами метод для запуска DoEvents. Каждый раз, когда вам нужно выполнить DoEvents, затем вызовите подпрограмму.
Если вы используете трехуровневую организацию для своего приложения, поместите подпрограмму или переменную в объект, представляющий все ваше приложение. Регистрируйте форму в объекте Application.
Если у вас есть проблемы с повторным входом, вы можете добавить переменную состояния и другие вспомогательные функции, чтобы безопасно проверить, что делает приложение. Обратите внимание, что гораздо проще реализовать это, если вы используете какой-либо тип многоуровневого дизайна.
Для других, которые смотрят на это повторное вхождение, проблема, однако, не реагирует пользовательский интерфейс. В сложном приложении есть обстоятельства, при которых вы должны позволить сработать циклу событий.
Я бы повторил «не надо» (либо из библиотеки DLL, либо из проекта пользовательского интерфейса). Есть несколько вещей, которые вы можете сделать, чтобы код библиотеки хорошо работал с пользовательским интерфейсом, в том числе те же приемы потоковой передачи (с событиями и / или обратными вызовами), которые вы можете использовать из пользовательского интерфейса. Самый простой подход заключается в том, чтобы код библиотеки просто выполнялся «как есть», и если пользовательский интерфейс порождает его в рабочем потоке, то задача пользовательского интерфейса - обрабатывать любые события и маршалировать их (Control.Invoke/BeginInvoke) в поток пользовательского интерфейса для Обновления пользовательского интерфейса.
Для более сложных сценариев вы можете использовать контекст синхронизации (SynchronizationContext.Current) для публикации сообщений в потоке пользовательского интерфейса (на самом деле именно так работает Control.Invoke и т. д., Но это не зависит от реализации - поэтому контекст синхронизации WPF может проходить через диспетчер WPF) .
Не могли бы вы добавить больше контекста, что это за сценарий? Есть много вещей, которые можно сделать ...
Я согласен с тем, что DoEvents нельзя использовать. Но что, если DoEvents, вызывающие проблемы, происходят из сторонней DLL, для которой у вас нет источника? У меня был кошмар с проблемой перерисовки в моем приложении, и я подозреваю, что это потому, что элемент управления вызывает DoEvents, и мои основные циклы приложения в конечном итоге становятся суррогатом этого элемента управления, поэтому всякий раз, когда элемент управления не отображается, все мое приложение перестает правильно перерисовывать.