ActiveX контроли

Document Sample
ActiveX контроли Powered By Docstoc
					       ActiveX контроли
       Това е новото име на OLE custom controls.
       Това е функционално завършено парче код, пакетиран за многократно използване и
предоставящ гарантирано определен интерф. за взаимодействие с клиентите си. ActiceX
контролът е COM обект, но задължен да имплементира определени интефейси, които
го карат да се държи като контрол.
       Като минимум ActivX контролите поддържат поне IUnknown. За разлика от OLE
контролите , които задължително трябваше да поддържат 14 стандартни интерф., тези
задължит. имплементират само IUnknown. Другите само по необходимост. Това ги прави по-
малки като код. повечето контроли имплементират напр. IDispatch, което ги прави
Automation сървъри (експонират методи и свойства). Предоставят и свойства, които следва
перманентно да се съхранят в запомняща среда – следоват. имплементират интерфейси за
сериализация – IPersistStreamInit,… и т.н.
       Те могат да се използват както от разработчици на приложения (напр. на VC++, VBasic
..) в свията приложна среда, така и от web разработчици за интерактивност в разработвана web
страница. За разлика от ASP, CGI технологиите, ActiveX контролите се изпълняват в
клиентската част на HTTP връзката.
       Има множество инструменти за създаването им. Нищо не може да се сравни за
момента с мощта на Visual C++ и MFC поддръжката. Вместо хиляди реда код, се налага
писане сао на няколко дестки реда, описващи спецификата във функционирането, а не се
занимаващи с интефейси, комуникации, стриктуриране на достъп, експониране, вграждане в
контейнер и т.н. задължителни всъщност дейности.
       Могат да са както видими (поддържат свой прозорец), така и невидими.
       Има богати библ. от подобни контроли.


       Най-често контролите се реализират като in-process servers( т.е са в DLL). Това е
поради следните причини:
       -   някой от интерф., които контролите имплементират нямат реализиран
           marshalling механизъм за настройка при междупроцесен обмен. А да се реализира
           такъв е доста обемна задача.
       -   по-бърза реакция отколкото при реализация в EXE сървър.
       -   в миналото OLE контролите бяха само in-process. Това са исторически наслоявания.
       Интерфейси на ActivеX контролите
       ActiveX контролът е COM обект и следователно се описва чрез набор поддържани
       интерфейси. На фиг. 21.2 е показан примерен контрол ( често срещан набор
       интерфейси)).


       ActiveX като Connectable обекти
       Те комуникират със своите контейнери чрез специф. интерфейси. Така те notify
       контейнера за случили се events. Така че подобни обекти следва да реализират 2
       интерфейса:
       -IConnectionPoint – реализиран е в контрола и позволява клиента да заяви желанието си
       за event notifications.
       -   IConnectionPointContainer използва се за запитване на обект дали поддържа първия
           интерф. Притежава ф-ии връщащи указател към IConnectionPoint или повече
           указатели към няколко такива интерф. (ако има такива реализирани в обекта).
       -   Повечето ActiveX контроли са свързващи се. Ето схемата на процеса на свързване:
                                 SINK                   IConnectionPoint


                       клиент                           IConnectionPointContainer
                                                               сървър (контрол)


       Клиентът желаещ ползване на определен IConnectionPoint вика QueryInterface() за
IConnectionPointContainer и чрез него заявява определен IConnectionPoint.Ако това е успешно,
клиентът подава указател към своя notification sink на сървъра чрез IConnectionPoint. С този
указател сървъра подава нотиф. съобщения на клиента.
       Б
      Пропъртита, събития и методи на ActiveX контрола

      Взаимодействие с контролите става чрез пропърти (атрибути), методи (експонирани
ф-ии, които могат да се приложат към контрола чрез IDispatch) и събития( съобщения,
предавани към контейнера от контрола, както беше описано по-горе).


      Properties
      Те са експонирани за промяна от страна на клиента съобразно нуждите на дадено
      приложение или web страница. Напр. свойство за цвят на фона, чрез което потреб. да
      настройва фона или изибщо да внася модификации във вида на контрола. Биват:
      -   управляващи средата за съвпадане с поведението на клиента - напр. цвят на фона,
          шрифт, и др.
      -   разширени – реализират се в клиента, но се ползват и от контрола. напр. подредба
          на бутони в OLE контрола, съобразно настройки в клиента.
      -   стандартни - те се придават на контрола, но се реализират от ActiveX development
          kit.
      -   потребителски пропъртита.


      И за двата вида е необходимо да се знаят имената и dispatch identifikatorite, определени
      в спецификацията на контрола. Това всъщност е доста дълъг списък за всеки контол.
      MFC поддържа вградени имплементации за голям брой такива, така че с ClassWizard
      добавяне на методи, свойства и събития става много лесно.


      методи
      Това са ф-ии реализирани точно така, както и в OLE Automation при използване на
      IDispatch. Те могат да бъдат викани за изпълняване някаква полезна работа. Напр.
      контрол – часовник – да има метод за настройване на времето.
      Също така биват потребитески и стандартни.
      events
      използват се за изпращане на нотиф. съобщ. от контрола към контейнера, койот
      съдържа контрола. Напр. кликване на мишка.. Биват:
      -   стандартни – реализирани от развойната среда за контрола – те са подобни по
          използване на викане на ф-ии – напр. генериране съобщение при грешка:
          FireError(..).
      -   потребителски – за целта са предвидени облекчаващи средства в средата.


      Всъщност механизма е сложен – през придобити от контрола интерфейси на
контейнера ( а това става по стандартния механизъм на автоматизацията: чрез IDispatch на
контейнера се придибиват указатели към негови интерфейси), методи на които се активират
от контрола при случване дадено събитие.
      Амбиентни свойства
      Това са свойства, които контейнерът предоставя за проверка или настройка на
контрола. Така контрола може да се настрои да изглежда например като използващия го в
момета контейнер (напр. цвят на фон0.
      Всъщност отново се използва неявно automation (амбиентното свойство е automation
свойство), и пострдничеството на IDispatch. Сега IDispatch е реализиран в контейнера.
      Амбиентните свойства са точно специфицирани в стандарта като имена и dispatch
идентификатори (виж. копието на стр. 206). За да се получи стойност на амбиентно совйство е
нужен указател към IDispatch и dispatch идентификатор на свойството.
      Има много интересни свойства; напр. UserMode дава информация дали сме в
развойната среда на Visual Basic, Visual C++ или в работещо приложение или в web страница.


      Контейнери на ActiveX контроли

      С


      MFC поддръжка на ActiveX контрол


      Д
      Методика на създаване на ActiveX контрол в среда Visual
C++ 4.0, Windows NT 4.0

      Нека създадем напр. ActivеX контр., наследяващ обикновен edit control. Той в
допълнение на стандартните възможности на edit контр. ще експонира функционалност за
въвеждане само на цифри, само на букви или и на двете. Проверките ще стават в отговор на
WM_CHAR.
      Експонират се следователно и 2 пропъртита: m_ftextAllowed, m_fNumberAllowed (чрез
които потребителят настройва контрола какви символи да допуска).
      Създаването върви в следната последователност:
      1. създава се project от тип MFC ActiveX ControlWizard. В ControlWizard се задава
          OLE custom control project. В редицата опции, които се попълват (няколко
          последователни диалогови прозореца) следва да се укаже, че контрола наследява
          стандартния Windows edit class (в полето: Whitch window class this control subclass).
          Задават се също така имената на класовете, които ControlWizard ще генерира,
          имената на файловете, съдържащи source кода за тези класове, както и
          идентификатори на контрола и страницата му за свойства. Попълват се и редица
          опции, определящи поведението на създавания контрол: напр. дали контролът да е
          видим в run time и в design time (напр. таймер, хвърлящ прек. може да не е нужно
          да е видим в run time), дали контейнерът може да активира и дезактивира контрола
          след като вече го е визуализирал на екран и доста др. (за съжаление недобре
          документирани опции).
      2. тъй като контрола ще има видима част, следва да се дефинира поведението на
          стандартно генерираната като прототип OnDraw() ( тя е виртуална ф-ия на
          COleControl):
      void COleEditCtrl::OnDraw( CDC* pdc, CRect& rcBounds, ……)
      {
      // определя се фон (напр. взима фона на приложението, което го стартира
      // (GetBackColor()), шрифт, рамка, попълва се правоъгълник, може да се използва и ф-
      // ията за рисуване на родителския клас –(стандартен IEditControl) DoSuperclassPaint()
      // и т.н.
      }
OnDraw() се вика в следните случаи:
1. WM_PAINT;
2. IViewObjectEx::Draw() викана за неактивен контрол;
3. IViewObjectEx::Draw() викана за рисуване на контрол, който няма собствен
    прозорец, за да се самонарисува в екрана на контейнера.
Добрият стил на писане на OnDraw() е да изработвате отначало всички елементи на DC
( напр. не предполагайте наличие на някакъв цвят за фон , а го изработете отначало).
Преди осовбождаване на GDI обекта за DC, възстановявайте старите атрибути.
Рисувайте само в определения rcBounds.
Първата ви работа в OnDra() е да изтриете rcBounds областта до цвета на фона.


3. Ако има нужда да се използват амбиетни свойства (за нашия пример няма такава
    нужда)
Е


4. Възможно е добавяне на потребителски и готови свойства към контрол.


Ж


За нашия пример е необходимо да се дефинират пропъртитата за: font , Text (готови) –
които вземат стандартни стойности и m_ftextAllowed, m_fNumberAllowed (BOOL) –
потребителски. Указват се и свързаните с тях нотификационни ф-ии
(OnFNumbersAllowedChanged()).
5. инициализират се пропъртитата, като за целта се добавя код в конструктора:
COleEditCtrl::COleEditCtrl()
{      m_fTextAllowed = TRUE;
       …
}
нека споменем и възможността да се създават перзистентни свойства:


З
      6.Работа с property page: Всички свойства, независимо дали готови или потребителски,
трябва да са достъпни за контейнера. Това става чрз страницата за свойства на контрола. Така
напр. акоо програмист включи ActiveX контрол в прил. си и кликне с десния бутон на мишка
в/ху него и избере от менюто Property, следва да се покаже лист със свойствата на контрола.
За да стане това контролът имплементира няколко интерфейса. Контейнерът пита за свойства
като подава списък идентификатори, съответстащи на отделни страници със свойства. MFC
реализира автоматично тези интерфейси, както и извличането и поместването в обекти на
страниците със свойства. Задачата на разработчика на контрол се свежда до добавяне
различните контроли към ActiveX контрол и да ги свържете с негови свойства. Това става с
редактор на диалози (добавянето на контроли) и от ClassWizard  Add Variable  име на
променливата, свързана с страница за свойства (свързването на контрол със свойство на
ActiveX). Трябва да се зададе и съответно Automation име на добавяното свойство в поле
Optional Property Name на прозорец Add Member Variable.
      За нашия пример в propery page се модифицира авт. генерирания ресурс на контрола
(празен прозорец) като се добавят бутони за въвеждане стойност на двете пропъртита
(Checkbox controls) и се указва връзката на тези контроли (IDC_…) с променливите :
m_ftextAllowed, m_fNumberAllowed.
      Class Wizard добавя код за обмен на стойности м/ду пром. и ресурса – това са т. нар.
DDP_ и DDX_ макроси (DialogDataExchange).
      ControlWizard създава само 1 страница на сойства за всеки контрол. Броят им може да
се увеличи (няма да се занимаваме как).
      7. написва се код за специфичната реакция при некоректно въведени стойности (напр.
въведена цифра, при допускани само букви). В този случай следва да се генерира към
контейнера на контрола събитие – Error.
      void COleEditCtrl::OnChar(nchar,….)
      {
      if( isdigit( nchar ))   {if(mfNumbersAllowed == False)    {
      // при грешка във въвеждането:
      FireError(……..);        }     // ще се обработа от контейнера
      else                          // ID event на събитие, текст за съобщение


      COleControl::OnChar(…); // стандартната обработка на това събитие, наследена от
                                    // базовия клас
      Нека споменем и процедуата за добавяне на потребителски събития, които контролът
ще изпраща към контейнера:
      От ClassWizard  ActiveX Events  Add Event се добавя име на събитие, име на ф-ия
      която го предизвиква ( в контрола)- тя започва с Fire…. и аргументи, които се подават
      заедно с него към контейнера.
      Има и списък с готови събития, техните dispatch идентиф. и предизвикващи ги ф-ии
      (напр. click, keyUp,…)


      Тук е мястото да споменем процедурата за добавяне на потребителски методи към
контрола:


      Ф


      8. остана да се създаде bitmap изображение, който да представлява новосъздадения
      ActiveX контрол в списъка контроли в контейнера на контролите . Това става напр. със
      средствата на Developer Studio. Напр. EDIT       за IDB_OLEDIT (ID bitmap).
      Компилира се project на контрола и работата е готова. Компилацията автоматично го е
      регистрирала. Така че приложението, което ще го тества може да го види в меню -
      опцията си: Insert OLE Control. Ако го вмъкнем (insert) , бутона ще се добави на екран,
      а иконата му в toolbar




      Притежаваме новосъздаден ActiveX контрол, реализиран в DLL, следователно като in-
      process server. Той може да се използва както в Web страници, така и в прил. на Visual
      C++, Visual Basic и др. поддържащи ActiveX.




      Тестването на неговата работоспособност може да стане с някой control container. Най-
      достъпен за целта е включения в Developer Studio (приложението TSTCON32.EXE) и в
      Win32 SDK test container. Той може да се стартира и от Tools  ActiveX Control Test
      Container. След това отидете в Edit  Insert New Control и избереете току що
      създадения контрол. Той ще се покаже. Кликнете в/ху него и изберете Property. Ще се
      покажелист със свойствата. Изберете някое от тях и го променете, слд това Apply. Би
      следвало да наблюдавате промяна (напр. цвят).
От същата среда можете да тествате и методите на контрола: Control Invoke
Methods.
Moжете да тествате и събитията на контрола: Options избирате Log To Output
Window. Предизвиквате в контрола генериране на известно ви събитие ( ако има
такова). Би следвало на долен прозорец да се появи нотификация за всяка поява на
събитието.
Ако контролът използва амбиентни свойства на контейнера и това може да се тества:
меню Container  Ambient Property  променяте свойство на контейнера.
За подобни тестове може да се използва и Access, Visual Basic 4.0, Internet Explorer 3.0
и нагоре…
Появява се контрола (подобен на edit box) като можем да имаме достъп до неговите
пропъртита за настройка. Функционалността е такава каквато сме я направили.
Достъпът до пропъртитата става от View Properties на “test container” напр. Това е
достъп чрез експонираните OLE интерфейси.
Има и втори начин:
чрез property sheet на самия контрол: от test container  Edit  Embedding Object
Functions  Properties  появява се прозореца на контрола:
                            General Font


                                   test
                                   numbers
                            OK      CANCEL
и настойка.


Регистриране на ActiveX контрол
в регистъра на с-мата следва да са записани CLSID на контрола, съдъжащия го DLL
файл и др. информация. Когато изграждате контрол на своя компютър, регистрирането
става автоматично. На друг комп., това следва да се прави явно. Ето 2 начина за това:
О


Използване на създадения контрол в MFC приложение
П

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:10
posted:4/17/2010
language:Bulgarian
pages:9
Jun Wang Jun Wang Dr
About Some of Those documents come from internet for research purpose,if you have the copyrights of one of them,tell me by mail vixychina@gmail.com.Thank you!