Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы
Здравствуйте, Аноним, Вы писали:
А>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы
Если говорить о передаче данных, то для начала должно быть разделение на уровни...
Для примера
На низком уровне передаются пакеты с управляющим символом который сигнализирует о том последний это пакет или ещё будет продолжение ( это в самом простом случае — сложнее учитывается потеря данных , обратная связь... Смотрите информацию по сетям и передаче данных.)
На более высоком есть просто потоки.
Передатчик пишет в поток Приёмник из него читает . Поток формируется низким уровнем.
Сдесь всё построено по принципу последовательного доступа к данным (если поток уже сформирован — тоесть ждём прихода всей иформации — то последовательный доступ не обязателен).
Т.е. прочитав первый байт (блок) информации мы должны узнать сколько ещё нам нужно прочитать и чего.
это означает что должен передаваться ID типа данных и их размер (количество) а за ними эти данные.
А теперь отпрыгнем от собсно передачи данных и "вернёмся к нашим баранам" Тоесть к вашему случаю.
Я не вижу надобности устраивать такой "сложной" системы передачи данных — почему не Создать класс аля MyCoolControl — и от него уже наследовать ваши списки, кнопочки, эдиты , и суперконтролы с трёхмерной графикой.
Создавать эти контролы в вашей динамической библиотеке и давать вашей принимающей программе Которая умеет работать с контролами типа MyCoolControl .
Или мы делаем что то хитрое?
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Re[2]: Помогите разобраться
От:
Аноним
Дата:
09.09.04 05:16
Оценка:
DV>Если говорить о передаче данных, то для начала должно быть разделение на уровни... DV>Для примера DV>На низком уровне передаются пакеты с управляющим символом который сигнализирует о том последний это пакет или ещё будет продолжение ( это в самом простом случае — сложнее учитывается потеря данных , обратная связь... Смотрите информацию по сетям и передаче данных.) DV>На более высоком есть просто потоки. DV>Передатчик пишет в поток Приёмник из него читает . Поток формируется низким уровнем. DV>Сдесь всё построено по принципу последовательного доступа к данным (если поток уже сформирован — тоесть ждём прихода всей иформации — то последовательный доступ не обязателен). DV>Т.е. прочитав первый байт (блок) информации мы должны узнать сколько ещё нам нужно прочитать и чего. DV>это означает что должен передаваться ID типа данных и их размер (количество) а за ними эти данные.
DV>А теперь отпрыгнем от собсно передачи данных и "вернёмся к нашим баранам" Тоесть к вашему случаю. DV>Я не вижу надобности устраивать такой "сложной" системы передачи данных — почему не Создать класс аля MyCoolControl — и от него уже наследовать ваши списки, кнопочки, эдиты , и суперконтролы с трёхмерной графикой. DV>Создавать эти контролы в вашей динамической библиотеке и давать вашей принимающей программе Которая умеет работать с контролами типа MyCoolControl .
DV>Или мы делаем что то хитрое?
Дело тут не в элементах управления, а в самодокументирующихся Dll. Т.е. Dll, как бы просит ввести приложение, вызвавшее Dll, данные для начальной инициализации
А>Дело тут не в элементах управления, а в самодокументирующихся Dll. Т.е. Dll, как бы просит ввести приложение, вызвавшее Dll, данные для начальной инициализации
Ого... Странно звучит что то...
Ну для начала — это не мешает этой .dll и контролы для этого свои держать.
А в "самодокументирующихся Dll"... Чего то я не понимаю для чего сдесь проток общения
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Re[4]: Помогите разобраться
От:
Аноним
Дата:
09.09.04 08:18
Оценка:
DV>Ого... Странно звучит что то... DV>Ну для начала — это не мешает этой .dll и контролы для этого свои держать. DV>А в "самодокументирующихся Dll"... Чего то я не понимаю для чего сдесь проток общения
На самом деле все гораздо сложней. Проект — это универсальный шлюз приема-передачи данных, источников данных может быть туева хуча. Dll-ки имеют некий интерфейс, который обеспечивает их подключение к этому шлюзу. На верхнем уровне ничего не известно заранее об источниказ и получателях данных, этим владеют Dll, вот они и дают некоторую инфу для своей инициализации
Re[5]: Помогите разобраться
От:
Аноним
Дата:
09.09.04 08:55
Оценка:
Здравствуйте, Аноним, Вы писали:
DV>>Ого... Странно звучит что то... DV>>Ну для начала — это не мешает этой .dll и контролы для этого свои держать. DV>>А в "самодокументирующихся Dll"... Чего то я не понимаю для чего сдесь проток общения
А>На самом деле все гораздо сложней. Проект — это универсальный шлюз приема-передачи данных, источников данных может быть туева хуча. Dll-ки имеют некий интерфейс, который обеспечивает их подключение к этому шлюзу. На верхнем уровне ничего не известно заранее об источниказ и получателях данных, этим владеют Dll, вот они и дают некоторую инфу для своей инициализации
Забыл добавить, что система может быть гетерогенной, т.е. где-то винда, где-то линукс, что-то написано ная сях, что-то на C#, так что передача контрола не есть рулез
Здравствуйте, Аноним, Вы писали:
А>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы
VARIANT?
Re[2]: Помогите разобраться
От:
Аноним
Дата:
09.09.04 10:14
Оценка:
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, Аноним, Вы писали:
А>>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы
SK>VARIANT?
Данные придут в виде потока байтов, вариант не катит
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, StanislavK, Вы писали:
SK>>Здравствуйте, Аноним, Вы писали:
А>>>Имеются данные, которые передаются из одной dll-ки в исполняемый модуль. Данные могут быть разного типа. Принимающая сторона ничего не знает о принимаемых данных, ей нужно автоматически построить GUI, на основе этих данных (если был передан int, то рисуется textbox, если массив, то список). Проблема кончено же в правильном определении типа переданных данных. Я решил создать универсальный класс метаданных и от него наследовать класс метаданных для основных типов данных (т.е. оборачивать тип), в классе содержится ID типа еще класс метаданных содержит значения передаваемых данных. Принимающая сторона содержит switch на основе которого и выполняет необходимые действия. Но все это выглядит оооочень криво. Хотелось бы узнать можно ли как-нибудь лучше проделать этот трюк. Пишу на сях, буду благодарен за ссылки и советы
SK>>VARIANT? А>Данные придут в виде потока байтов, вариант не катит
Почему не катит? Договорись, что первые, допустим, 4 байта — размер данных. Получай и делай, что хочешь. Только, ессесно value типы надо использовать.
Накрайняк, есть VARIANT не подходит, пусть будет что-нить очень похожее, но твое.
Re[4]: Помогите разобраться
От:
Аноним
Дата:
10.09.04 07:16
Оценка:
SK>Почему не катит? Договорись, что первые, допустим, 4 байта — размер данных. Получай и делай, что хочешь. Только, ессесно value типы надо использовать. SK>Накрайняк, есть VARIANT не подходит, пусть будет что-нить очень похожее, но твое.
Помимо размера, в поток байтов нужно сунуть еще ID типа, а это уже возврат к моему варианту. Только у меня в классе все эти описатели данных, зашиты в поля класса обертки, а сами данные в массив байт, тоже поле этого класса. Принимающая сторона анализирует описывающие поля и уже знает что делать с данными, другого варианта видимо нет