Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы

Здравствуйте, Аноним, Вы писали:

А>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы

Если говорить о передаче данных, то для начала должно быть разделение на уровни...
Для примера
На низком уровне передаются пакеты с управляющим символом который сигнализирует о том последний это пакет или ещё будет продолжение ( это в самом простом случае — сложнее учитывается потеря данных , обратная связь... Смотрите информацию по сетям и передаче данных.)
На более высоком есть просто потоки.
Передатчик пишет в поток Приёмник из него читает . Поток формируется низким уровнем.
Сдесь всё построено по принципу последовательного доступа к данным (если поток уже сформирован — тоесть ждём прихода всей иформации — то последовательный доступ не обязателен).
Т.е. прочитав первый байт (блок) информации мы должны узнать сколько ещё нам нужно прочитать и чего.
это означает что должен передаваться ID типа данных и их размер (количество) а за ними эти данные.


А теперь отпрыгнем от собсно передачи данных и "вернёмся к нашим баранам" Тоесть к вашему случаю.
Я не вижу надобности устраивать такой "сложной" системы передачи данных — почему не Создать класс аля MyCoolControl — и от него уже наследовать ваши списки, кнопочки, эдиты , и суперконтролы с трёхмерной графикой.
Создавать эти контролы в вашей динамической библиотеке и давать вашей принимающей программе Которая умеет работать с контролами типа MyCoolControl .

Или мы делаем что то хитрое?

DV>Если говорить о передаче данных, то для начала должно быть разделение на уровни...
DV>Для примера
DV>На низком уровне передаются пакеты с управляющим символом который сигнализирует о том последний это пакет или ещё будет продолжение ( это в самом простом случае — сложнее учитывается потеря данных , обратная связь... Смотрите информацию по сетям и передаче данных.)
DV>На более высоком есть просто потоки.
DV>Передатчик пишет в поток Приёмник из него читает . Поток формируется низким уровнем.
DV>Сдесь всё построено по принципу последовательного доступа к данным (если поток уже сформирован — тоесть ждём прихода всей иформации — то последовательный доступ не обязателен).
DV>Т.е. прочитав первый байт (блок) информации мы должны узнать сколько ещё нам нужно прочитать и чего.
DV>это означает что должен передаваться ID типа данных и их размер (количество) а за ними эти данные.


DV>А теперь отпрыгнем от собсно передачи данных и "вернёмся к нашим баранам" Тоесть к вашему случаю.
DV>Я не вижу надобности устраивать такой "сложной" системы передачи данных — почему не Создать класс аля MyCoolControl — и от него уже наследовать ваши списки, кнопочки, эдиты , и суперконтролы с трёхмерной графикой.
DV>Создавать эти контролы в вашей динамической библиотеке и давать вашей принимающей программе Которая умеет работать с контролами типа MyCoolControl .

DV>Или мы делаем что то хитрое?

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

А>Дело тут не в элементах управления, а в самодокументирующихся Dll. Т.е. Dll, как бы просит ввести приложение, вызвавшее Dll, данные для начальной инициализации

Ого... Странно звучит что то...
Ну для начала — это не мешает этой .dll и контролы для этого свои держать.
А в "самодокументирующихся Dll"... Чего то я не понимаю для чего сдесь проток общения

DV>Ого... Странно звучит что то...
DV>Ну для начала — это не мешает этой .dll и контролы для этого свои держать.
DV>А в "самодокументирующихся Dll"... Чего то я не понимаю для чего сдесь проток общения

На самом деле все гораздо сложней. Проект — это универсальный шлюз приема-передачи данных, источников данных может быть туева хуча. Dll-ки имеют некий интерфейс, который обеспечивает их подключение к этому шлюзу. На верхнем уровне ничего не известно заранее об источниказ и получателях данных, этим владеют Dll, вот они и дают некоторую инфу для своей инициализации

Здравствуйте, Аноним, Вы писали:

DV>>Ого... Странно звучит что то...
DV>>Ну для начала — это не мешает этой .dll и контролы для этого свои держать.
DV>>А в "самодокументирующихся Dll"... Чего то я не понимаю для чего сдесь проток общения

А>На самом деле все гораздо сложней. Проект — это универсальный шлюз приема-передачи данных, источников данных может быть туева хуча. Dll-ки имеют некий интерфейс, который обеспечивает их подключение к этому шлюзу. На верхнем уровне ничего не известно заранее об источниказ и получателях данных, этим владеют Dll, вот они и дают некоторую инфу для своей инициализации
Забыл добавить, что система может быть гетерогенной, т.е. где-то винда, где-то линукс, что-то написано ная сях, что-то на C#, так что передача контрола не есть рулез

Здравствуйте, Аноним, Вы писали:

А>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы

VARIANT?

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

SK>Здравствуйте, Аноним, Вы писали:

А>>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы

SK>VARIANT?
Данные придут в виде потока байтов, вариант не катит

Здравствуйте, Аноним, Вы писали:

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

SK>>Здравствуйте, Аноним, Вы писали:

А>>>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы

SK>>VARIANT?
А>Данные придут в виде потока байтов, вариант не катит
Почему не катит? Договорись, что первые, допустим, 4 байта — размер данных. Получай и делай, что хочешь. Только, ессесно value типы надо использовать.
Накрайняк, есть VARIANT не подходит, пусть будет что-нить очень похожее, но твое.

SK>Почему не катит? Договорись, что первые, допустим, 4 байта — размер данных. Получай и делай, что хочешь. Только, ессесно value типы надо использовать.
SK>Накрайняк, есть VARIANT не подходит, пусть будет что-нить очень похожее, но твое.
Помимо размера, в поток байтов нужно сунуть еще ID типа, а это уже возврат к моему варианту. Только у меня в классе все эти описатели данных, зашиты в поля класса обертки, а сами данные в массив байт, тоже поле этого класса. Принимающая сторона анализирует описывающие поля и уже знает что делать с данными, другого варианта видимо нет