Вопросы Теги

Передающие данные между C++ (MFC) приложение и C#

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

string q = "SELECT DISTINCT c1, c2, c3 FROM mytable......";

И вместо того, чтобы перебирать каждую строку в datatable, вы можете просто использовать свойство DataSource из DataTable, например, 

SqlDataAdapter s = new SqlDataAdapter(q, c);
DataTable d = new DataTable();
s.Fill(d);
dgw.DataSource = dt;

Edit1: [1114 ]

Вы можете проверить строку перед добавлением ее в представление сетки данных, например, 

foreach (DataRow r in d.Rows)
{
    bool existingRow = dgw.Rows
                          .Cast<DataGridViewRow>().AsEnumerable()
                          .Any(x =>
                                Convert.ToString(x.Cells["Column1"].Value).Split(' ')[0] == r["c1"].ToString() &&
                                Convert.ToString(x.Cells["Column1"].Value).Split(' ')[1] == r["c2"].ToString() &&
                                Convert.ToInt32(x.Cells["Column2"].Value) == Convert.ToInt32(r["c3"])
                           );

     if (!existingRow)
         dgw.Rows.Add(r["c1"].ToString() + " " + r["c2"].ToString(), r["c3"]);
}

Где:

  • Column1 и Column2 столбцы в виде сетки данных.
  • c1, c2 и c3 являются столбцами в таблице данных
8
задан Brian R. Bondy 8 October 2008 в 21:23
поделиться

9 ответов

Лично я думал бы об использовании чего-то как именованные каналы, поскольку они просты в использовании со стороны C++ и Системы. IO.Pipes на стороне.NET также.

Это также был бы путь, вероятно, наименьшего сопротивления, если Вы планируете заменить другой не биты.NET приложения со временем.

6
ответ дан 5 December 2019 в 09:26
поделиться

Выберите:

  • файлы
  • именованные каналы <-Моя рекомендация
  • общая память
  • сокеты
  • COM
  • Сообщения Windows

Почему именованные каналы?

  • Дает Вам FIFO способ работать бесплатно (как сокеты, но не как общая память)
  • Может легко передать оба пути
  • Хорошо поддерживаемый на всех платформах
  • Простой в использовании
  • Надежная передача данных и доставка
  • Может блокироваться и не блокироваться
  • Может считать данные, не удаляя (в отличие от сокетов)
  • Может быть расширен для включения третьего приложения легко.

В .NET просто используют Систему. IO.Pipes.

В C++ используют CreateNamedPipe и CreateFile.

5
ответ дан 5 December 2019 в 09:26
поделиться

Можно также использовать P/Invoke с управляемой стороны - это было бы полезно, если приложение MFC имеет API C. Также можно использовать COM с любой стороны.

2
ответ дан 5 December 2019 в 09:26
поделиться

Опции, которые Вы перечисляете, конечно, допустимы, но Вы могли также рассмотреть COM.

2
ответ дан 5 December 2019 в 09:26
поделиться

Я использовал бы сокеты (TCP) - и MFC и.NET имеют прямую поддержку их.

2
ответ дан 5 December 2019 в 09:26
поделиться

Мои выборы были бы любой стандартными сообщениями окна (например, WM_FOO) или DCOM:

  • Сообщения работали бы, пока коммуникация очень проста, и издержки в установке, это минимально. Если бы можно свести коммуникацию к одному или двум целым числам на сообщение, это, вероятно, было бы хорошим местом для запуска. Если оба приложения уже являются оконными приложениями, у них обоих уже есть циклы сообщения, таким образом, Вы уже - большая часть пути там.

  • DCOM требует намного большего количества программиста наверху, но это хорошо в этом, можно определить более богатый интерфейс и избежать необходимости преобразовывать сложные сообщения в двоичную форму. Если Вы идете этим путем, CoRegisterClassObject является начальной точкой для публикации объекта через DCOM. Я никогда не пытался делать это из приложения C#, но в принципе это должно быть совершенно возможно

0
ответ дан 5 December 2019 в 09:26
поделиться

Вам действительно нужны два процесса?

Неуправляемый C++ и управляемый код C# совершенно способны к работе в том же процессе, и с небольшим слоем управляемого С++ / CLI, Вы могли заменить сложность межпроцессного взаимодействия с простыми вызовами функции.

1
ответ дан 5 December 2019 в 09:26
поделиться

Принятие Вас имеет источник к приложению прежней версии, видит, не можете ли Вы скомпилировать весь код "рабочей лошади" как DLL, затем вызовите отдельные функции/окна оттуда. После того как у Вас есть та работа, можно просто записать обертки Управляемого С++ вокруг функций, в которых Вы нуждаетесь и вызываете тех, которые из Вашего кода C#. Целый процесс может занять меньше чем день, если Вы удачливы.

0
ответ дан 5 December 2019 в 09:26
поделиться

Я сказал бы, что C++ / CLI, если Вы не должны волновать по поводу платформы.NET, существующей во всех системах приложение, будет работать, и COM иначе. Это действительно зависело бы от того, что Вы являетесь самыми удобными и знакомыми с, все же. Мне нравится существующая структура 'вызова функции' C++ / CLI и COM (в противоположность созданию его с другими протоколами), но это - просто я.

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

0
ответ дан 5 December 2019 в 09:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: