자신의 프로젝트에 상용 VBX를 사용하게 되면 사용한 VBX가 많은 만큼 얻는 효과도 크겠지만 더불어 라이선스 비용 문제가 얽혀 들어간다.
몇 가지 VBX 라이선스 파일에 관한 것을 살펴보았지만, OLE 컨트롤의 경우엔 VBX와 다른 라이선스 방법이 필요하다. 보통 VBX 라이선스는 보통 1카피당 1대씩의 데스크톱 PC에 인스톨하도록 규정하고 있다.
하지만 'Q+E ODBC 엔진'이라는 VBX는 약간 다르다. Q+E는 저렴한 가격으로 MS사의 윈도 3.1용 ODBC 드라이버가 지원하지 못하는 인포믹스, IBM DB/2, atcomSQL 등의 여러 데이터베이스에 접속할 수 있는 기능을 제공하는 패키지인데, 개발 업체가 Q+E를 사용했을 때, 개발 중에는 모르던 라이선스 문제가 납품 직전에 구체화되고 만다.
만일 Q+E로 개발한 응용 소프트웨어를 클라이언트/서버 환경에서 사용하려고 하는데 클라이언트 1대당 1카피씩 Q+E 런타임 버전을 설치해야 한다는 계약 조건이 있다면 어떨까?
서버에는 데이터베이스와 DBMS가 있을 것이고, 클라이언트에는 Q+E 응용 프로그램과 런타임을 설치해야 한다.
즉, 수십 개의 클라이언트용 런타임 버전을 따로 구입해야 하는 추가 부담이 생겨 배보다 배꼽이 커지는 격이 될 수도 있다.
Q+E 런타임 엔진을 구입하느니 차라리 ODBC 접속용 SW를 개발하는데 투자하는 편이 훨씬 나았을 것이다. LIC 파일이 딸려 있는 VBX 패키지가 거의 이런 식이므로 라이선스 문제를 유통사에 확실히 물어 보고 구입하여야 할 것이다.
그럼 OCX 라이선스는 어떨까? 객체 지향적인 컴포넌트웨어의 시대에 어플리케이션에 분산되어지는 OLE 컨트롤들이 다른 어플리케이션에 재사용되는 것은 지극히 당연한 일이므로 막을 방법이 없다.
서드파티 개발자들은 상용 OLE 컨트롤을 디자인 타임에서만 사용할 수 있도록 고심해야 했는데, VBX에서 사용하던 라이선스 방법에 여러 가지를 더 확장했다고 생각할 수 있다.
*****************************************************
OCX 라이선스 파일의 정보를 알아내는 구조체인 LicInfo
******************************************************
VBX에서는 윈도의 특정 디렉토리에 라이선스 파일이 있을 경우만 메모리에 VBX 컨트롤의 인스턴스를 생성해 냈는데, OLE 컨트롤의 경우도 인스턴스를 생성할 때 IFactory 인터페이스의 확장인 IFactory2::GetLicInfo()를 사용해 라이선스 파일의 유무를 묻는 방법을 쓴다.
OLE 컨트롤을 OLE 컨테이너에 로드하려고 할 때는 GetLicInfo() 메소드가 컨트롤과 관련된 라이선스 파일이 존재하는지 찾는다.
컨트롤의 인스턴스가 만들어지면 OLE 컨트롤을 포함한 OLE 컨테이너가 OLE 컨트롤에 대해서 Unique한 라이선스 키를 요구하기 위해 RequestLicKey() 메소드를 호출한다.
OLE 컨테이너는 넘어온 라이선스 키값을 저장해 둔다. 어플리케이션은 OLE 컨트롤을 포함한 채 배포되더라도 라이선스 파일이 없다면 인스탄스가 생성되지 않아 디자인 타임에서 사용은 불가능하다.
런타임에도 OLE 컨테이너에 저장된 Unique한 키값을 CreateInstanceLic()에서 파라미터로 해서 OLE 컨트롤에 넘겨준다. 만약 요구하는 라이선스 키값과 틀린다면 그 컨트롤을 사용할 수 있는 방법은 없어진다.
또다른 응용법은 평가 버전과 프로 버전이 하나의 컨트롤에 들어 있지만, 두 개의 라이선스 파일로 풀리도록 만들어져 있어 평가 버전일 경우 사용할 수 있는 메소드나 프로퍼티를 제한시킬 수 있다.
프로용 라이선스로 파일만 바꾸어 주면 OLE 컨트롤을 즉시 프로 버전으로 업그레이드한다.
OLE 컨트롤 개발방법
비주얼 C++ 4.0에서는 OLE 컨트롤의 CDK를 포함하고 있기 때문에 마우스로 클릭해주는 것만으로도 비주얼하게 OLE 컨트롤을 개발할 수도 있고, VB 프로젝트에 직접 사용할 수도 있다.
비주얼 C++ 2.0에서는 개발할 수는 있었지만 VBX 컨트롤을 이용할 수 없었던 점에 비해 큰 도약이라 하겠다.
새로운 32비트 플랫폼과 32비트 OLE 컨트롤 컨테이너의 등장은 VBX의 단점을 넘어서서 OLE 2.0을 통합하는 새로운 OLE 컨트롤로 가려는 길을 닦아주었지만, OCX는 기존의 많은 VBX를 쓸모없게 만들 수 있다는 문제점을 내포하고 있었기 때문에 기존의 서드파티사들 가운데 OCX를 거부하는 움직임이 있었던 것은 사실이다.
OCX는 서드파티 개발사들이 OLE 2.0 표준을 선택한다는 것과 같은 맥락에서 이해될 수 있으며, 선택한 OLE 표준에 대한 계속적인 지원과 보장이 필요했다.
마이크로소프트사는 이러한 문제점을 해소하기 위해 비주얼 C++의 ControlWizard에서 VBX를 OCX로 간단히 포팅할 수 있는 VBX Template을 제공한다.
VBX Template는 기존 VBX의 모델 구조체를 사용해 OCX의 기본 구조를 위한 프로토타입 소스 코드를 생성해준다. 그 다음은 VBX의 소스 코드를 OCX 코드의 적당한 위치로 옮기면 되는 것이다.
OCX는 아마도 차세대 운영체제 NT 5 카이로의 일부로 포함될 것으로 기대되고 있었다.
마이크로소프트사의 비주얼 C++ 4.0을 비롯한 비주얼 베이식 4.0등의 개발도구도 확실하게 지원해주며, 서드파티사는 기존 VBX 제품을 대신한 OCX 컨트롤이라는 새로운 시장을 가지게 되었다.
개발한 OLE 컨트롤을 컴파일한 후에는 ActiveX 컨트롤패드나 비주얼 베이식 4.0같은 OCX를 시험해 볼 OLE 컨테이너가 필요하다.
비주얼 C++의 Tools 메뉴의 'Test Container'를 이용할 수도 있다. '테스트 컨테이너'에 의해 사용되기 전에 먼저 Tools 메뉴의 'Register Control'에서 시스템 레지스트리에 OCX를 등록해야 한다. REGSVR32.EXE라는 유틸리티는 DLLRegister()함수를 호출하여 OCX를 시스템 레지스트리에 등록해준다.
테스트 컨테이너의 'Insert OLE Control' 대화상자에서 우리가 제작한 OLE 컨트롤이나 시스템 레지스트리에 이미 등록되어있는 OLE 컨트롤들을 실험해 볼 수 있다.
상속이란 개념은 리스트 컨트롤이나 버튼같은 기존의 윈도 컨트롤을 상속받아 여기에 기능을 확장하는 것이다. 버튼 객체를 상속받으면 기존의 윈도 95 버튼 클래스를 상속받는 것이므로 매우 비슷하게 작동한다. 개발자는 필요한 이벤트와 프로퍼티를 입맛대로 골라 추가해 줄 수 있다.
비주얼 C++ 4.0에서는 컴포넌트 갤러리에 OLE 컨트롤을 등록시켜 두었다가 (시스템 레지스트리에 등록되어 있는) 자신의 프로젝트에서 원하는 컨트롤을 불러서 사용하면 된다.
선택한 OLE 컨트롤 클래스에 대한 코드가 자동 생성되고, 애플리케이션 스튜디오의 다이얼로그 박스 에디터의 팔레트에 OLE 컨트롤이 자동 추가된다.
다이얼로그 에디터에서는 컨트롤의 인스탄스를 생성시켜 개발자가 Property를 지정해주면 된다.