Thanks Anand,
The problem is not so much with VB not debugging the sequence containg my in-proc server as in how it does it. It is probably a VB quirk, in that it does not expose the interfaces in the same way when compiled and run in the ADE as in the dll after registration. My dll is implementing 2 interfaces that have been compiled into separate dlls. Creating the sequence, the editor sees the Interfaces from my Implementation dll( as if they were classes in the Object Class dropdown of the Specify Module Form in Teststand) and thus allows me to use the methods I have Implemented on each Interface from the same activeX reference.( This works in practice). This behavior is different when I use VB ADE to use the Sequence to debug the Implementation dll, in that T
estStand warns that "The class 'XX' is not exposed by the server ...". for a sequence step that uses one of the Implemetations of one of the Interfaces within. I have found a work-around that means I can access my Interfaces if I create sequence steps to access the dlls that contain my Interface Classes and then pass them the activeX reference from the dll containing my Implementation Class. This results in a needing a separate sequence for debugging to the one I will use for the client program. Once again, I have no doubt this is a VB nasty, but wonder if anyone else has encountered or found a solution that means I don't have to have 2 sets of sequences ( which will be quite large when complete) to be able to debug my applications.