создание объекта
Скажите, реально ли это сделать и какие технологии лучше использовать (среда - MS Visual Studio.NET): MFC, .NET или что-то другое?
Недавно передо мной встала задача: я создаю базу данных нарушителей административной комиссии используя 1С:Предприятие - локально. Т.к. эта база данных будет размещена на одной машине, а данные по нарушителям будут включать ФИО, дату рождения (которые есть в базе данных населения на удаленном сервере), то возникла идея создания объекта, который бы подключаясь к базе данных населения, передавал бы в 1С код личности нарушителя, а при выводе на экран коннектился к SQL-серверу и по коду личности выдавал бы ФИО, дату рождения. 1С поддерживает механизм OLE (т.е. позволяет подключать внешние программы), но вот вопрос: я в технологиях OLE и COM новичок, хотя на Си++ с MFC работал.
Скажите, реально ли это сделать и какие технологии лучше использовать (среда - MS Visual Studio.NET): MFC, .NET или что-то другое?
... ATL ....
... ATL ....
Еще варианты будут?
Еще варианты будут?
Помойму ATL самая подходящая обертка для использования COM OLE ActiveX итд. Есть еще вариант для мазохистов ... программировать COM обьект на WinAPI ... вернее для личностей склонных к мазохизму ... хотя все зависит от обьекта ...
Помойму ATL самая подходящая обертка для использования COM OLE ActiveX итд. Есть еще вариант для мазохистов ... программировать COM обьект на WinAPI ... вернее для личностей склонных к мазохизму ... хотя все зависит от обьекта ...
На примере может кто-нибудь показать использование ATL. Это ведь наверное библиотека, а сама технология создания - на VS.NET где-нибудь описана. Может ее показать кто-нибудь?
На примере может кто-нибудь показать использование ATL. Это ведь наверное библиотека, а сама технология создания - на VS.NET где-нибудь описана. Может ее показать кто-нибудь?
... Поищи в гугле ... примеров много .... если не найдешь могу прислать на мыло ..
... Поищи в гугле ... примеров много .... если не найдешь могу прислать на мыло ..
Я нашел простой пример в VS.NET, но запутался в терминологии: ATL, COM, ActiveX, OLE. Что есть что? Что нужно чтобы создать компонент, который работает по технологии OLE (1c это подерживает). Можно ли это сделать на .NET ?
Я нашел простой пример в VS.NET, но запутался в терминологии: ATL, COM, ActiveX, OLE. Что есть что? Что нужно чтобы создать компонент, который работает по технологии OLE (1c это подерживает). Можно ли это сделать на .NET ?
... в принципе это одно и то же .... Скорей всего в 1С встроена серверная часть ... надо написать клиентскую ...
а ATL это библиотека шаблонов для создания COM-объектов, АctiveX элементов.
ATL сильно облегчает жизнь.
VS 2003 поддерживает ATL
OLE, COM, ActiveX это технологии,
а ATL это библиотека шаблонов для создания COM-объектов, АctiveX элементов.
ATL сильно облегчает жизнь.
VS 2003 поддерживает ATL
Чем тогда отличаются ActiveX и COM-компоненты? И что предлагается в .NET. У меня есть информация, что потихоньку отказываются от COM и ActiveX в .NET.
Чем тогда отличаются ActiveX и COM-компоненты? И что предлагается в .NET. У меня есть информация, что потихоньку отказываются от COM и ActiveX в .NET.
ActiveX это такой COM-компонент который реализует определенный набор интерфейсов и вообщем то предназначен для создания визуальных элементов легко подключаемых к разного рода приложениям.... ( продолжения следует )....
Чем тогда отличаются ActiveX и COM-компоненты?
IMHO различия в основном терминологические
И что предлагается в .NET.
Можно создать скелет компонента. Есть инструментарий для введения новых членов и функций.
Частично черновая работа выполняется автоматически
Так было в VS6
В .NET я не упражнялся, но думаю что как минимум все то же самое.
У меня есть информация, что потихоньку отказываются от COM и ActiveX в .NET.
IMHO это важная общая тенденция - отказа от связывания компонентов на этапе исполнения. Это относится как к СОМ так и обычным DLL. Главная причина этой тенденции - организационные сложности контроля версий. Память стала дешевле, ее стало больше, и значительно дешевле и проще тестировать, поставлять, устанавливать и сопровождать единственный большой ЕXE, а не маленький EXE с кучей DLL или COM(ActiveX)
Допустим для решения этой задача - подключения к 1С компонента, который возвращает из БД код личности я напишу Windows Service (.NET) или ASP.NET Web Service. Это современно и перспективно. Но тогда можно ли заставить 1с работать с ними. По-моему нет.
Может в новой 1с это возможно?
Хорошо, давайте тогда также откажемся от COM и ActiveX.
Допустим для решения этой задача - подключения к 1С компонента, который возвращает из БД код личности я напишу Windows Service (.NET) или ASP.NET Web Service. Это современно и перспективно. Но тогда можно ли заставить 1с работать с ними. По-моему нет.
Может в новой 1с это возможно?
Здесь несколько проблем:
1. Собственно разработка программы - это тендениция создания 1-го большого ЕХЕ.
2. Интерфейс к программе, позволяющий подключать внешние модули. СОМ - это один из таких и интерфейсов и для этих целей ИМХО эта технология будет жить еще долго. Так подключаются напр. другие компиляторы к VS.
3. Для расширения функциональных возможностей можно использовать только то, что поддерживается.
Я не знаю 1с. но если там написано СОМ - значит это должен быть СОМ. Если есть и другие методы, то возможны варианты.
Для подключения внешних модулей можно использовать только то, что поддерживается.
.... вобще-то если 1с поддерживает OLE ... это значит что ты можешь использовать какие-либо обьекты 1с в своей программе .... но не наоборот
ИМХО не однозначно
Что написано в док-ции на с1???
Если 1с может быть только СОМ-клиентом, то как раз наоборот.
Если 1с может выступать как сервером так и клиентом, то 1с и собственная прогр. симметричны.
Что написано в док-ции на с1???