DevExpress GridControl и асинхронная работа с данными
От: baranovskiyne  
Дата: 20.07.09 21:16
Оценка:
День добрый.
Столкнулся с извечной проблемой синхронизации потоков.
Проблема в следующем: есть грид, отображающий данные из DataTable, есть отдельные потоки, которые сами по себе крутятся, и периодически обновляют данные в том же DataTable. Соответственно грид периодически падает совсем некрасиво (красным крестом становится).
Мне вообщем понятно, что именно ему не нравится, но менять архитектуру как-то не хочется, у меня в программе тьма различных потоков ( без них там ни как нельзя) между собой они нормально синхронизированы, и знать не знают ни про пользовательский интерфейс и про гриды в частности ( да вообщем-то и не должны знать), так что переносить обновление данных в таблице через Invokeв поток формы крайне не желательно. Есть ли какие либо варианты синхронизировать работу гридов с такими источниками данных.


22.07.09 00:52: Перенесено модератором из '.NET' — AndrewVK
Re: DevExpress GridControl и асинхронная работа с данными
От: Diboss  
Дата: 21.07.09 07:08
Оценка:
Здравствуйте, baranovskiyne, Вы писали:

B>День добрый.

B>Столкнулся с извечной проблемой синхронизации потоков.
B>Проблема в следующем: есть грид, отображающий данные из DataTable, есть отдельные потоки, которые сами по себе крутятся, и периодически обновляют данные в том же DataTable. Соответственно грид периодически падает совсем некрасиво (красным крестом становится).
B>Мне вообщем понятно, что именно ему не нравится, но менять архитектуру как-то не хочется, у меня в программе тьма различных потоков ( без них там ни как нельзя) между собой они нормально синхронизированы, и знать не знают ни про пользовательский интерфейс и про гриды в частности ( да вообщем-то и не должны знать), так что переносить обновление данных в таблице через Invokeв поток формы крайне не желательно. Есть ли какие либо варианты синхронизировать работу гридов с такими источниками данных.


В DevExpress обновление грида надо заключать в конструкцию:
gridView1.BeginUpdate();

........
articleTableAdapter.Fill(dataSet1.Article)
.......
gridView1.EndUpdate();
должно помочь.
Re[2]: DevExpress GridControl и асинхронная работа с данными
От: baranovskiyne  
Дата: 21.07.09 14:00
Оценка:
D>В DevExpress обновление грида надо заключать в конструкцию:
D>gridView1.BeginUpdate();

D>........

D>articleTableAdapter.Fill(dataSet1.Article)
D>.......
D>gridView1.EndUpdate();
D>должно помочь.

Спасибо за ответ, но это не мой вариант... классы логики не должны быть связаны с пользовательским интерфейсом... можно правда попробовать через какие-нибудь события таблицы.
Re: DevExpress GridControl и асинхронная работа с данными
От: Skynin Украина skynin.blogspot.com
Дата: 23.07.09 08:08
Оценка:
Здравствуйте, baranovskiyne, Вы писали:

B>переносить обновление данных в таблице через Invoke в поток формы крайне не желательно. Есть ли какие либо варианты синхронизировать работу гридов с такими источниками данных.

По моему кроме Invoke — и низя. Но, не настаиваю, самому интересно, а вдруг — можно? В Java вот тоже низя. Threads and Swing.
Re[2]: DevExpress GridControl и асинхронная работа с данными
От: baranovskiyne  
Дата: 23.07.09 10:05
Оценка:
Здравствуйте, Skynin, Вы писали:

S>Здравствуйте, baranovskiyne, Вы писали:


B>>переносить обновление данных в таблице через Invoke в поток формы крайне не желательно. Есть ли какие либо варианты синхронизировать работу гридов с такими источниками данных.

S>По моему кроме Invoke — и низя. Но, не настаиваю, самому интересно, а вдруг — можно? В Java вот тоже низя. Threads and Swing.

По идее ошибка происходит, когда грид решает перерисовать себя, а перерисовывает он себя когда приходит сообщение WM_PAINT, так что если перекрыть метод формы ЦтвЗкщс и добавить там блокировку DataSource'а грида, и аналогично выставлять блокировку на нем же в рабочем пеотоке — то должно быть все хокей. Я попробовал так сделать, но доконца не понял, помогло это или нет.

Если я в своих суждениях неправ — жду Ваших замечаний.
Re[3]: DevExpress GridControl и асинхронная работа с данными
От: drol  
Дата: 23.07.09 10:52
Оценка:
Здравствуйте, baranovskiyne, Вы писали:

B>По идее ошибка происходит, когда грид решает перерисовать себя,


Неа. Сломать всё может любое действие с Вашим DataTable в потоке обработки событий UI. Процессинг WM_PAINT просто одна из самых длительных операций => ерунда всплывает чаще.

По-моему проще всего будет подправить Ваши "отдельные потоки" таким образом, чтобы они предоставляли возможность участия в синхронизации прочих внешних объектов.
Re[4]: DevExpress GridControl и асинхронная работа с данными
От: baranovskiyne  
Дата: 23.07.09 11:09
Оценка:
D>По-моему проще всего будет подправить Ваши "отдельные потоки" таким образом, чтобы они предоставляли возможность участия в синхронизации прочих внешних объектов.
Не совсем понял, что Вы имеете ввиду, выполнять изменения в DataTable через Invoke в потоке формы, или какую-то иную синхронизацию?
Re[3]: DevExpress GridControl и асинхронная работа с данными
От: AngeL B. Россия  
Дата: 24.07.09 05:40
Оценка:
Здравствуйте, baranovskiyne, Вы писали:

B>Спасибо за ответ, но это не мой вариант... классы логики не должны быть связаны с пользовательским интерфейсом... можно правда попробовать через какие-нибудь события таблицы.


У Вас либо классы логики должны знать о пользовательском интерфейсе, либо пользовательский интерфейс должен знать о классах обработки логики. В противном случае Вы ставите неразрешимую задачу: синхронизировать несколько потоков, которые друг о друге ничего не знают и не имеют общих элементов синхронизации.
Re[4]: DevExpress GridControl и асинхронная работа с данными
От: baranovskiyne  
Дата: 24.07.09 06:08
Оценка:
AB>У Вас либо классы логики должны знать о пользовательском интерфейсе, либо пользовательский интерфейс должен знать о классах обработки логики. В противном случае Вы ставите неразрешимую задачу: синхронизировать несколько потоков, которые друг о друге ничего не знают и не имеют общих элементов синхронизации.

Постойте, а данные — чем не общие объекты, почему, собственно, сам грид не может выставлять блокировку на свой DataSource и перерисовывать себя не в потоке обработки событий, а в потоке формы.
Re[5]: DevExpress GridControl и асинхронная работа с данными
От: AngeL B. Россия  
Дата: 24.07.09 07:23
Оценка:
Здравствуйте, baranovskiyne, Вы писали:

AB>>У Вас либо классы логики должны знать о пользовательском интерфейсе, либо пользовательский интерфейс должен знать о классах обработки логики. В противном случае Вы ставите неразрешимую задачу: синхронизировать несколько потоков, которые друг о друге ничего не знают и не имеют общих элементов синхронизации.


B>Постойте, а данные — чем не общие объекты, почему, собственно, сам грид не может выставлять блокировку на свой DataSource и перерисовывать себя не в потоке обработки событий, а в потоке формы.


надо иметь не просто общие объекты, а общие объекты синхронизации.
Грид может блокировать что угодно, но тогда потоки обработки должны знать об этой блокировке (каким угодно образом) и не изменять данные пока идет их обработка гридом. Т.е. между ними все равно должна быть связь.
Re: DevExpress GridControl и асинхронная работа с данными
От: Аноним  
Дата: 24.07.09 11:13
Оценка:
Здравствуйте, baranovskiyne, Вы писали:

B>Проблема в следующем: есть грид, отображающий данные из DataTable, есть отдельные потоки, которые сами по себе крутятся, и периодически обновляют данные в том же DataTable.

Со стандартным гридом когда-то я делал так: в гуёвом потоке table.BeginLoadData, потом запускал поток обновляющий данные, после загрузки по сигналу в гуёвом потоке table.EndLoadData. Но с DexExpress-овским гридом фокус почему то не работал.

Вопрос, такой способ легален в принципе? Насколько я понимаю индикация об изменении данных должна происходить только после EndLoadData, но тогда почему начинает колбасить DevExpress-овский контрол? В своё время от их саппорта никакого объяснения не добился и стал тупо загружать новые данные в отдельную таблицу, а после загрузки копировать их в основную в гуевом потоке.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.