Предлагаю вашему вниманию тему для обсуждения. Кто брался писать ActiveX при помощи предлагаемых custom-интерфейсов??? А при помощи "Новых интерфейсов для ActiveX'ов, работающих в среде РПД и др. гр. консолей"??? Ну приступим...
Немного в разнобой, уж извиняйте...
А надо то всего свой Alarm Viewer, с кое какими расширениями. Вот через что пришлось пройти...
Первое, что мне бросилось в глаза так это строка в описании дуальных интерфейсов: "3. Разработанные на основе описываемых здесь интерфейсов компоненты менее эффективны, чем компоненты, написанные на С++ с использованием ранее опубликованных custom-интерфейсов как по быстродействию так и по памяти". Отлично, верю, да и это очевидно! Естественно, я сразу рванул в направлении перекопа документации на предмет описания библиотеки типов для custom-интерфейсов. Что нащёл: idl есть, пример типа тоже есть... А описание, т.е. idl выложили и пример и всё? То что по 3 строчки на метод в IDL написанно? Это называется "опубликованно"? Ладно, не впервой. Можно и поковыряться. Далее всё как в сказке, чем дальше тем страшней... Cтандартный компонент Trace Mode Alarm Viewer реализует 2 интерфейса из библиотеки в tm5proxy.dll(!), а именно: IChInfo и ItmEventClient. Однако в предлагаемом примере (Spin.dsp) нет и речи про tm5proxy.dll - все необходимые интерфейсы определенны в tmaux.idl и tmxlib.idl. Таким образом обнаруженно 3 dll, где в библиотеке типов встречается описание IChInfo: tm5proxy.dll, Tmxlib.dll и наконец tmxauxdsp.dll (видимо какая-то диспетчерская оплётка на интерфейсы?). Определение ItmEventClient удалось импортировать из DrawServ.exe. Там поболее определений интерфейсов, однако опять странности. Есть, например, определение интерфейса ItmChBrowser и ItmChBrowserEx, которые встречались нам в tmxaux.idl, но нет определения IChInfo. Проанализировав вышесказанное, я пришёл к выводу, что говорить, как в пресс релизе на TM5: "Программа имеет открытый коммуникационный интерфейс..." пока рановато. Кроме того, создалось впечатление, что Adastra, может и не преднамеренно, но всё же предпочитает умалчивать некоторую информацию, которая могла бы позволить сторонним разработчикам разрабатывать новые компоненты и расширять в полной мере возможности Trace Mode. [Мысли вслух] Консоль тревог за деньги продаётся, а теперь каждый студент сядет и свою, ни чем ни хуже сделает... [конец Мыслей вслух] Переварив всё это, было решёно писать компонент на Дельфях, чтоб всю ту кухню не разгребать. К слову говоря: Делфи уже давно, в отличии от Бейсика, позваляет реализовавать COM компоненты, на основе custom интерфейсов. Однако настойчиво рекомендуется использовать интерфейсы из rtmd.idl. Ладно начали пробовать. В нашем распоряжении целых 2 интерфейса IDtmRtmData и IDtmRtmClient. Согласно инструкции нам нафиг не нужен IDtmRtmData, т.к. значения каналов нас не интересуют, нужны только события. И так необходимо просто реализовать IDtmRtmClient и мы счастливы. Но сами знаете - не так всё просто получается на самом деле. Зачем мне нужна привязка к какому-то каналу, если мне всё равно нужна только строка события приходящая в OnAlarm? Для того чтобы на каждом цыкле пересчёта БК получать callback на onTagsValsChanged? Есть ещё один мистический метод OnRun, вызывается только у тех компонентов, которые находятся на стартовом экране. Если их нет на нём, то и ни одного вызова OnRun не происходит. Метод OnAlarm вызывается ТОЛЬКО при использовании графической консоли Net Link Lite. В РПД OnAlarm не вызывается вообще, в том числе и в "родных примерах (TmDelCtl, TmVBCtl)". Кроме того как мне узнать текущего оператора? Или быть хотя бы уведомлённым об его смене? Изучив подробнее интерфейс IDtmRtmData, я заметил следующую штуку - метод listObject действительно перечислит мне только идентификаторы объектов, каналов, атрибутов. Однако в файле rtmdata.h гораздо больше констант чем для обзора объектов каналов или атрибутов. Например: // Group definitions for object browsing #define RTM_GROUP_OBJECTS 0x01 // enum objects IDs #define RTM_GROUP_CHANNELS 0x02 // enum channels IDs by object #define RTM_GROUP_CHAN_ATTRS 0x03 // enum attributes by channel ID #define RTM_GROUP_CHAN_ARCH_ATTRS 0x04 // the same as previous, but only archived #define RTM_GROUP_CAT_ATTRS 0x05 // enum attributes by category flags Сравните константы: какие в примере и какие в rtmdata.h. Судя по всему заложен доступ и к инфе о текущем проекте, и к инфе о текущем пользователе, и так далее. Но вся дельфийская кухня работает только для объектов, каналов, атрибутов. У меня достучаться до других штук, например до ////////////// // attribute class: SESSION
#define RTM_ATTR_SESSION_SCREEN_RIGHTS 0x060001L // screen rights mask #define RTM_ATTR_SESSION_T_LAST_ALARM 0x060002L // time of the last alarm не вышло. Опять мысль, что либо специально зарубили, либо по лени не сделали... Теперь самый цымус! Посоветуйте мне, что покрутить и куда посмотреть, а то TraceMode выдаёт мне штук 30 (по разному) алярмов, а потом начинает расти очередь на отображение и TraceMode, перестаёт уведомлять даже "родной" Event Viewer. Ну и DrawServ приходится сносить диспечтером задач. Ещё не упомянул я про поведение гр. консоли. при её закрытии. Было на эту тему минимум 2 топика. Ответ так и не получен. А именно, исследования показали, что гр. консоль как то криво дёргает addRef и release компонента, вследствии чего не вызывается деструктор... Уффф. Наверняка что то забыл. Пока разгребать всем хватит.
Так, что скажет Adastra Technical Support? И вы уважаемые посетители форума?
Что делать со все этой бедой?
С наилучшими пожеланиями, Антон.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Нужно использовать только документированные интерфейсы и структуры данных. 2. Написанию custom-интерфейсов на Дельфи МЫ не препятствуем. 3. Тревоги в РПД недоступны - это норма. Нужно проверять либо в Профайлере, либо в МРВ (а также в консолях). 4. OnAlarm в 5.15 вызывается, даже если компонент не привязан к каналу. 5. Деструктор действительно не вызывается - это ошибка, к 5.15 поправить не успели. 6. Если медленно обрабатывать тревоги при быстром темпе их поступления, то описанная ситуация возможна. Вероятно надо увеличить размер очереди... 7. OnRun вызывается, если запущен пересчет и создается окно компонента (или наоборот). Считайте фичей. Posted by ilya (Участник № / Member № 469) on :
Отвлечемся пока от ItmRtmClient и ItmRtmData. Берем ActiveForm в Delphi, компилируем, и регистрируем его в системе. Вставляем его в РПД.
Далее, нам надо будет отлаживать наш ActiveX, и поэтому пробуем запустить picrt.exe c ActiveX-ом под Delphi. Появляется “access violation”(именно при запуске из под Delphi). Начинаем искать виновных. Может виноват я как программист? Но я пока еще не написал ни строчки. Может виноват Delphi? Вставляем наш ActiveX в другие среды Internet Explorer (html-страницу), приложение на VB и С++, и запускаем их под Delphi – все нормально запускается и отлаживается. Виновный найден – Trace Mode. Это потом я случайно вычитал в форуме (топик ТЕХНИЧЕСКАЯ ПОДДЕРЖКА/Мониторы Реального Времени/Проблемы с графикой http://forum.adastra.ru/ubb/ultimatebb.php?ubb=get_topic;f=5;t=000065#000003), про default.pal. Скопировал куда надо – заработало, но время потеряно.
Далее: запустили, отлаживаем, но постоянно выскакивает ошибка EOleSysError “член группы не найден”(именно при запуске из под Delphi). Вроде бы на работу ActiveX-а не влияет, но мешает сильно. Начинаем искать виновных. Может виноват я как программист? Но я пока еще не написал ни строчки. Может виноват Delphi? Вставляем наш ActiveX в другие среды Internet Explorer (html-страницу), приложение на VB и С++, и запускаем их под Delphi – все нормально запускается и ни каких ошибок. Виновный найден – Trace Mode. Писал в техподдержку но внятного ответа не получил. Сам найти причину возникновения этой ошибки не смог.
Запустим picrt.exe c нашим ActiveX-ом просто в OC и нажмем кнопку “обновить графику”. Увидим “access violation”.
Спрашивается: неужели при создании примера ActiveX компонента на Delphi, который поставляется c Trace Mode, разработчики не сталкивались с этими проблемами? Как же тогда отлаживался этот пример?
А вот топик от 20.09.2001: ТЕХНИЧЕСКАЯ ПОДДЕРЖКА/ Редактор Представления Данных / Ошибка в доп. интерфейсе для ActiveX ( http://forum.adastra.ru/ubb/ultimatebb.php?ubb=get_topic;f=3;t=000023 ) . Сегодня 11.06.2004. Если не ошибаюсь метод onTagsValsChanged вызывается сервером на КАЖДОМ ЦИКЛ ПЕРЕСЧЕТА СИСТЕМЫ ДЛЯ КАЖДОЙ ПРИВЯЗКИ до сих пор.
Мое впечатление: для Trace Mode можно писать ActiveX компоненты на Delphi (про С++ и VB ничего сказать не могу), но пока нерешенных проблем море и решать их не спешат! А поначалу все казалось таким заманчивым: берем: любимый Delphi и ваяем на нем для Trace Mode свои модули. На практике оказалось все не так радужно…
Тестировалось все это на Delphi5-7 Trace Mode 5.12.
На 10-й конференции уважаемый Роман Бузинов сказал с трибуны, что в TM6 дальнейшего развития интерфейсов для ActiveX компонентов не будет. Жаль…
Posted by TheBug(R) (Участник № / Member № 275) on :
Я бы добавил, что к сожалению, до сих пор нет нормального решения проблемы со звуковой сигнализацией на НетЛинк Лайтах. Написание ActiveX спасает отчасти. Его приходится копировать на все экраны, что мягко говоря идеологически не правильно.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. В 5.15 при вызове on anAlarm память более не растет. 2. Значения при вызове onTagsValsChanged действительно передаются по одному. Это так и будет. 3. По поводу запуска PicRT ил среды Delphi - по этому поводу были похожие сообщения и от других программистов, которые работают под Delphi. Однако - с чего Вы решили, что дело в ТМ? Ведь под средой MVS, например, все это отлично работает - может всетаки дело в Delphi?
Posted by ilya (Участник № / Member № 469) on :
quote: Однако - с чего Вы решили, что дело в ТМ? Ведь под средой MVS, например, все это отлично работает - может всетаки дело в Delphi?
Почему я так решил - см. внимательно мое предыдущее сообщение: потому что компонент тестировался в д.р. средах (эти приложения c компонентом запускались из под Delphi) и нигде проблем не возникало.
А что скажете по поводу возникновения "access violation", при нажатии на кнопку "обновить графику"?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) От того, что Вы тестировали в других средах компонент еще ничего не значит, что в ТМ ошибка. Среда MS Visual Studio запускает PicRT без проблем, а Delphi почему-то не может, поэтому напрашивается вывод - может Delphi как-то не так его грузит и в нем что-то не так?
2) По поводу "access violation" - нужен проект чтобы воспроизвести ситуацию.
Posted by ilya (Участник № / Member № 469) on :
1). Так мы с Вами не договоримся. Фразы: “может Delphi как-то не так его грузит и в нем что-то не так?” проблему не решают. Может и в Delphi проблема, а может и нет. Поскольку Вы разработчики контейнера и Вы поставляете с TM примера ActiveX на Delphi, может Вы и разберетесь, и расставите все точки над “i”. Мне это не удалось. У Вас в руках код контейнера и код ActiveX-а, у меня - только ActiveX-а. А пока на лицо такой факт: берем Delphi и д.р. среды ( много других сред! ) – проблем нет, берем Delphi и TM – проблемы есть.
2). Высылаю два проекта. Похоже закономерность такая: в проекте с нагруженной графикой (архив Error.zip, узел “Disp”, экран “Звук”) ошибка есть, с простой (архив “WithoutError.zip”) - нет. Отправил на forum@adastra.ru
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Какой Delphi используете?
Posted by ilya (Участник № / Member № 469) on :
Delphi6 Trace Mode 5.12
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
ActiveX, который прислали - окуда брали? Это он "валит" систему при обновлении графики, без него все работает нормально. Posted by ilya (Участник № / Member № 469) on :
1)С помощью Delphi сделал. На ActiveX-e это написано. 2)В том то и дело, что с любым ActiveX компонентом созданным в Delphi возникает такая проблема. Причем не вовсех проектах Trace Mode, а в проектах с навороченной графикой. Для илюстрации этого Вам отправлено два примера.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Извините за задержку, но большее время ушло на то, чтобы найти нужную Delphi...
Итак - глюк однозначно в самой Delphi и только 6-й версии. Пробовали на Delphi6 - стабильно падает, даже если вообще не ActiveX писать. А вот в Delphi7 - все отлично работает и ничего не валится. Используйте 7-й версию.
![[А-а! / Eek!]](eek.gif)
![[crazy / сумасшедший]](graemlins/crazy.gif)
![[Улыбка / Smile]](smile.gif)
![[Неодобрение / Frown]](frown.gif)
Так мы с Вами не договоримся. Фразы: “может Delphi как-то не так его грузит и в нем что-то не так?” проблему не решают. Может и в Delphi проблема, а может и нет. Поскольку Вы разработчики контейнера и Вы поставляете с TM примера ActiveX на Delphi, может Вы и разберетесь, и расставите все точки над “i”. Мне это не удалось. У Вас в руках код контейнера и код ActiveX-а, у меня - только ActiveX-а. А пока на лицо такой факт: берем Delphi и д.р. среды ( много других сред! ) – проблем нет, берем Delphi и TM – проблемы есть.![[Вращающиеся глаза / Roll Eyes]](rolleyes.gif)
![[clever / умный]](graemlins/clev.gif)