Jayender,
ActiveX controls work "differently" on web pages than they do in Windows
applications.
There are several things you need to be concerned about:
- how will the control be installed on the user's PC?
- how will upgrades to the control be handled (bug fixes)?
- how will non-IE browsers be handled (eg. firefox)?
- how will the control get its data?
- Will we code sign the control (you really really should)?
The raw mechanics of including a control:
<OBJECT ID=MyControl classid="clsid:99999999-9999-9999-9999-999999999999">
<PARAM NAME="x" VALUE="5">
</OBJECT>
or
<object
ID=MyControl
classid="clsid:99999999-9999-9999-9999-999999999999"
CODEBASE="
http://www.mysite.com/MyControl.cab#version=-1,-1,-1,-1">
<PARAM NAME="x" VALUE="5">
</object>
The classid parameter is the GUID for the specific control you need to
create. The CODEBASE parameter indicates where the control can be installed
from.
Also note that IE has change the rules on how controls are activated. You
may have seen "click here or press space bar to activate this control"
messages. This is fall out from the Eolas lawsuit. These can be worked
around, but generally requires the control to be created via JavaScript.
And... I don't know for sure so this is a guess... but I don't think VS.NET
HTML editor supports automatically inserting <OBJECT> tags for ActiveX
controls. In the past I just fired up FrontPage to do the initial insert
(more or less identify the CLSID guid for me)... but I bet you could do this
with the OLEView tool as well (or just by poking around in the registery).
A nice example site for handling the initial installation, tracking, and
updating of an ActiveX control is the MSN Money site. They have a very nice
portfolio manager/stock graphing tool that is deployed as an ActiveX
control.
Also note that end users must be members of at least the Power Users local
group to be allowed to install ActiveX controls. And debugging what has gone
wrong with an ActiveX install can be very very challenging.
Regards,
Rob MacFadyen
