Каковы побочные эффекты обеспечения того, что каждый созданный элемент управления имеет дескриптор в .NET?

Question

В прошлом я страдал от проблемы зависания, которая была результатом использования элемента управления для маршалинга вызовов в потоке пользовательского интерфейса перед созданием дескриптора для этого элемента управления.(См. блог Ким Гринли для получения дополнительной информации.)

Используя этот метод - реализованный рекурсивно - я гарантирую, что все элементы управления, которые создаются в нашем приложении, имеют дескрипторы, когда они создаются.В частности, это делается после вызова дизайнера для инициализации графического интерфейса для элемента управления.

Мой вопрос:

Q - Помимо производительности, есть ли другие причины, по которым все элементы управления не имеютобрабатываете таким образом?

Я спрашиваю, поскольку у нас возникла проблема с элементом управления Infragistics, который находится внутри панели Infragistics.Когда пользователь изменяет размер этой панели, размер элемента управления Infragistics не изменяется должным образом, даже если его свойство Dock имеет значение Dock.Fill.Существует также проблема, из-за которой всплывающие подсказки, отображаемые в этом элементе управления, больше не отображаются рядом с мышью.Обе эти проблемы решаются, если оба контейнера и содержащие элементы управления не гарантируют, что у них есть дескрипторы, созданные для себя и всех их дочерних элементов управления.

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

Приветствия!

Answer 1

Были ли у вас эти проблемы при маршалинге в вашем собственном коде или это происходило в каком-то внешнем коде?

У меня тоже были эти проблемы пару раз, и я переключился на использование класса SynchronizationContext.Несомненным плюсом для этого класса является то, что вам не нужны никакие элементы управления для маршалинга между потоками.

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

private SynchronizationContext m_oSyncContext = SynchronizationContext.Current ?? new SynchronizationContext();

Используя этот экземпляр, вы можете использовать методы Post / Send из любого потока, чтобы (а) синхронно отправлять сообщения в поток, в котором был получен этот экземпляр.

Недостатком этого являетсяВы должны убедиться, что извлекаете экземпляр в правильном потоке, и я бы рекомендовал сделать это так же, как в примере выше.Если вы создаете экземпляр, когда уже есть текущий, вы можете получить некоторые неприятные побочные эффекты.

Answer 2

Хорошо, я решил конкретную проблему, с которой столкнулся. Это не было проблемой с компонентами инфраструктуры. Я просто заставлял создание ручек в неправильное время ...

Я принудительно создавал дескриптор в конструкции каждого пользовательского элемента управления / формы - после вызова InitializeComponent (). Это хорошо для форм, но на этом этапе элемент управления, скорее всего, не будет помещен в родительский элемент управления / форму. Очевидно, что принудительно создавать дескриптор, когда у элемента управления нет родительского элемента для «удержания», очевидно, плохо.

Итак, я изменил свое эмпирическое правило для реализации этого:

• Для форм принудительное создание дескрипторов после добавления ВСЕХ дочерних элементов управления для самой формы и любых дочерних элементов управления. Обычно я продолжаю делать это в Construct формы после вызова InitializeComponent ().
• Для элементов управления принудительное создание дескрипторов после того, как элемент управления был создан и добавлен в его родительскую Contol / форму, для нового элемента управления и всех его дочерних элементов управления (если есть).

Так что я полагаю, если вы убедитесь, что вы используете эту функцию правильно, единственным недостатком является потенциальная проблема с производительностью (которую я не заметил, если честно).

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

Roo