Datagridview сохраняет ожидание при обновлении из потока - PullRequest
4 голосов
/ 09 июня 2010

В моем приложении Windows Forms есть элемент управления DataGridView.Я добавляю строки в сетку, используя фоновый поток.Я изменяю курсор формы на Waitcursor, когда процесс начинается, и возвращаюсь к Default, когда он заканчивается.Это хорошо работает для формы, но не для сетки.Когда курсор формы возвращается к значению по умолчанию, курсор сетки не изменяется, хотя курсор над остальной частью формы меняется.

Имеет ли это какое-либо отношение к тому факту, что я обновляю сетку изфоновый поток?(Курсор изменяется непосредственно из потока пользовательского интерфейса).

Редактировать: фоновый процесс вызывает событие, обработчик проверяет свойство сетки InvokeRequired и решает, нужно ли ему снова «вызывать» метод изосновная нить.Таким образом, фактическое обновление пользовательского интерфейса происходит из соответствующего потока.Я не уверен, означает ли это, что я "использую фоновую ветку" или нет.: |

Ответы [ 3 ]

7 голосов
/ 03 января 2011

У меня были некоторые проблемы при выполнении однопотокового обновления моих сеток данных, когда сетка данных не сбрасывалась до обычного курсора после того, как у меня был waitcursor в true.То, что я сделал, было сразу после того, как я пошел

this.UseWaitCursor = false;

Я добавил

DatagridviewFoo.Cursor = this.Cursor;

Может быть, это просто та же проблема для вас

2 голосов
/ 20 сентября 2012

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

Эта проблема когда-либо возникала только тогда, когда у меня было диалоговое окно над элементом управления DGV, и мышь щелкала по кнопке, чтобы закрыть окно, чтобы, когдаполе закрыто, мышь находится над (изменяемым размером) границей столбца.Если курсор оказался над ячейкой, проблема не возникла.Если бы мне пришлось угадывать, я бы сказал, что сетка видела событие изменения размера столбца, как только закрылось диалоговое окно, которое не было должным образом обработано.

Использование Cursor.Current = Cursors.Default устранило мою проблему (без необходимостиявно сбросить курсор элемента управления).Но, возможно, следует помнить, что Application.UseWaitCursor = False не работал даже при явном сбросе курсора управления.

1 голос
/ 11 декабря 2012

У меня была похожая проблема, но ни одно из опубликованных решений не помогло мне. Мой не был вызван нажатием кнопки над разделителем подвижных столбцов. Это просто случайно произошло после открытия и закрытия диалогового окна. Я почти уверен, что дело дошло до времени, потому что у .Net / Windows есть проблемы, когда речь идет о настройке курсоров и их действии. Чтобы попытаться преодолеть это, библиотека, которую мы используем для отображения и скрытия вызовов курсора ожидания - ack! - Приложение. DoEvents. Я установил точку останова в OnCursorChanged и увидел, что курсор на самом деле иногда устанавливался при последнем вызове Application.DoEvents (используется для поддержки отзывчивости пользовательского интерфейса во время ожидания, пока файловая система освободит блокировку записи для файла). Поэтому я думаю, что иногда курсор по умолчанию снова включался до того, как вызов для установки курсора ожидания полностью вступил в силу. Во всяком случае, мой грубый метод заключается в том, чтобы позвонить

Cursor = Cursors.Default;

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...