I guess many of you have written your own components to be used in your ASP pages. However finding the problem with a component it's a hard thing to do. What are the guide lines to follow in order to determine the problem of a component?
Encapsulate as much of your solution as possible hopefully ALL OF IT, into classes that have nothing to do with COM. Then these classes can be used to build a 'normal' application in whatever language you are working with. This provides simple IDE debugging capabilities for 99% of your controls functionality.
Then you start your COM project and insert the classes into it and wrap them in the COM code. The COM code then serves as a thin layer to pass parameters to/from the classes you already built.
This technique does not solve all of the problems associated with COM development but it at least reduces them to the essence of COM and not 'your code'.
"But, that's just my opinion... I could be wrong".
-pete
I use a test harness built in visula Basic to call the COM component. I also use a LOT of error handling. When testing your comp0onet use a routine which writes as much error information as possible to a text file for future reference.
The use of a test harness in Visual Basic means that if your COM component has been written in VB then you can use VBs complete suite of debugging tools which makes your life a lot easier. Test in the IDE before deploying to ASP is the way to go.
James James Culshaw
jculshaw@active-data-solutions.co.uk
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.