지난 금요일 오전 이틀간의 삽질이 끝났다.
아니... 그동안 개발과 중단의 반복된 시간들로 보면
Plugin 전체로는 한두달 정도 끌어온 작업인듯...
어쨌거나 이만큼 질질 끌며 나를 괴롭혀 오던 작업은
정말 허무한 삽질로 결말이 나고 말았다.
삽질의 원인은 대소문자... -_-a
정말 초보적 실수의 극치라 부를 수 있는 문제로 삽질을 했다는 것이 심히 괴롭다.
COM을 이용한 ActiveX에서는 인터페이스 정의를 마법사가 거의 알아서 해준다.
이 때, 노출되는 인터페이스는 '*.idl'파일에 기술되며 MIDL 도구로 컴파일되고,
이것은 ActiveX 구현 파일과 연결된다.
그러나 Mozilla Plugin에서는 조금 다르다.
물론 인터페이스는 역시 '*.idl'파일에 기술되지만,
gecko-SDK와 함께 배포되는 'xpidl'이라는 도구로 컴파일 된다.
컴파일 된 후에는 헤더파일과 '*.xpt' 두가지 파일이 생성되는데
인터페이스 구현을 위해 위에 생성된 헤더를 상속받는 인터페이스 클래스를 따로 구현해야만 한다.
요약하면, ActiveX는 인터페이스가 구현 자체와 완전하게 결합되어 있지만,
Mozilla Plugin은 인터페이스와 구현이 완벽하게 분리되어 있다.
두 특징은 나름의 장단이 있지만,
개인적으로는 Mozilla Plugin 쪽이 좀 더 나은 방법이 아닌가 생각한다.
Mozilla Plugin에 대한 자세한 얘기는 그만 제끼기로 하고, 문제의 핵심은 이렇다.
아래는 Plugin에 쓰이는 '*.idl' 파일이다.
#include "nsISupports.idl"
[ scriptable, uuid(420E6934-B57F-4283-8F99-0F37F609F55E) ]
interface nsIPluginTest : nsISupports {
void button1();
void button2();
};
interface nsIPluginTest : nsISupports {
void button1();
void button2();
};
분명히 두 인터페이스는 소문자로 b로 시작한다.
그러나...
class NS_NO_VTABLE nsIPluginTest : public nsISupports {
public:
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IPLUGINTEST_IID)
/* void button1 (); */
NS_IMETHOD Button1(void) = 0;
NS_IMETHOD Button1(void) = 0;
/* void button2 (); */
NS_IMETHOD Button2(void) = 0;
NS_IMETHOD Button2(void) = 0;
};
xpidl 컴파일 도구에 의해 생성된 헤더에는 대문자 B로 변경되어 있다.
이것이 삽질의 원인이다. -_-a
Plugin에서 인터페이스는 기본적으로 '*.idl'에 기술되어 있는 대소문자를 따른다.
그런데 나는 헤더를 상속받아 사용했기 때문에
첫문자가 b가 아닌 B라고 철썩같이 믿고 스크립트에 대문자 B로 기술했기 때문에
Method가 전혀 동작하지 않은 것이다.
그런줄도 모르고 하단의 QueryInterface까지 내려가 이잡듯이 샅샅이 뒤집어 엎던 황당함이란...
뭐, 금요일의 어이없는 삽질도 이렇게 막을 내렸다.
하~
::: 사람과 사람의 교감! 人터넷의 첫 시작! 댓글을 달아주세요! :::