Requires Free Membership to View
Yes, it is completely possible to build an OCX-like component. I hope I am not mis-interpreting your question but what you've described is one of the advantages of the Web services architectural approach.
Specifically, you get to separate your data-generating code, servers,
networks, etc. from your data-consuming stuff. In your case, it sounds like your raster viewer service serves up raster images. How your architecture separates tasks is up to you but one reasonable approach would be to farm out image processing tasks (including simple pan, zoom, stretch, etc.) to the data Web Service and only have the dumbest of dumb clients (e.g., HTML browser). On the other hand, you might decide that you will have an intelligent client and that you will serve up raw data to the client based on image requests. Your client is free then to do what it wants with the data. Most likely, you'll take a hybrid approach where the server can serve processed or raw data to the client.In the case where you are serving up html data, you would probably create a custom web forms control that you could embed in pages. This control would manage pan, zoom and possibly some rudimentary image processing. The control would run on a Web server (middle, rendering tier) and interact with your back-end data services tier.
In the case where you are serving up raw data to the end client, you would create a custom windows forms control that you could embed in a browser or another application. This control would have full access to the windows platform and its support for image manipulation. In this case, your control could pull raw data from your data services Web Service and manipulate it at the client. You can implement this latter example in two ways, natively and through COM interop.
In the native case, you reference your custom forms control much like you would an activex control within your Web page. The syntax looks like the following.
<OBJECT id="Obj1" classid="Assembly.dll#Full.Namespace.ControlName">
The "id" parameter is just the in-page identifier for the object. The "classid" refers to your control. Thus, let's assume you created an assembly with the name "MyCoolControls.dll" and that assembly contained a control named "ImagePane" within the namespace "MyDotNetControls". The object reference that you would put in your page would look like:
<OBJECT id="MyControl" classid="MyCoolControls.dll#MyDotNetControls.ImagePane">
There are a couple of things to note here. First, you can only load this control from the Web server where the including page is located. You cannot load it from disk or from the local GAC. Secondly, security restrictions at the browser side will limit how much local system access your control has. If you need to load the control from your local machine (e.g., your control was distributed on CDROM) then your out of luck with the native method. In this case, you can use COM interop to wrap the control as a COM component and include it in your page as an activex control. This Microsoft knowledge base article is helpful, http://support.microsoft.com/default.aspx?scid=kb;en-us;q317346
This was first published in June 2003
Join the conversationComment
Share
Comments
Results
Contribute to the conversation