их входные очереди. И хотя один элемент управления ActiveX обрабатывает ввод, ни один из других (или родительский) не может. Ввод строго сериализован.

стория: мой коллега и я поддерживаем унаследованное приложение на миллион строк. Его интерфейс написан на VB6, и, поскольку мы почти все наши ресурсы посвящаем его преобразованию в C #, мы ищем быстрые и грязные решения нашей конкретной проблемы.

Приложение ведет себя в стиле плагина. Существует до 20 отдельных элементов управления ActiveX, которые можно загрузить сразу в виде сетки. Проблема состоит в том, что элементы управления ActiveX выполняют всю свою обработку в своем собственном потоке пользовательского интерфейса, и, поскольку большая часть его блокирует ожидание при доступе к сети, пользовательский интерфейс становится очень сложным. Когда наше управляющее приложение C # загружает эти элементы управления, оно перестает отвечать из-за того, что многие элементы управления поглощают ресурсы пользовательского интерфейса и ничего не делают. В довершение всего, элементы управления хрупки и будут падать при малейшей провокации. Когда они размещаются в основном приложении C #, это создает серьезную нестабильность.

Лучшее, что я и мои коллеги придумали, - это запуск процесса для элемента управления ActiveX. Этот процесс, который мы называем прокси, является еще одним приложением winforms. Он использует именованные каналы для связи с процессом хостинга. Процесс хостинга создает окно, загружает элемент управления ActiveX по нашему выбору (через некоторые отражения и магию AxHost) и сообщает основному процессу, что его дескриптор окна использует через именованный канал. Основной процесс использует комбинацию SetParent и SetWindowPos для перемещения прокси-приложения в себя, чтобы эмулировать плагин. Обновления размера отправляются через именованный канал.

Это работает достаточно хорошо, пока приложение ActiveX не выполняет какой-то длительный процесс, и мы не нажимаем на главное окно, пока оно работает. Какое-то время главное окно реагирует, но в конечном итоге оно перестает отвечать, поскольку дочернее окно ожидает своего потока пользовательского интерфейса. Как мы можем сохранить дочерние окна в их собственном полном потоке, в то же время получая преимущества SetParent?

(пожалуйста, дайте мне знать, если что-то не понятно!)

Ответы на вопрос(1)

Ваш ответ на вопрос