Another attempt at bettering my TestComplete COM experience, another failure...
So we supposedly can, through "connected applications", use TestComplete runtime objects like Sys, Log, Project, etc...
The only issue is that no autocomplete is available, no documentation is available, only late binding is supported, etc etc etc... Can no one see how this is a problem? It basically makes connected applications a big pile of useless stinking static code. It removes any advantage I would have potentially got from using a managed language to write my tests.
So I played around. Simplest way I figured I could try to fix the problem is by looking at the internal interfaces exported through Interop.TestComplete.dll. The closest match I could find for the Sys object is the ItcSysNode interface, but it is incomplete (meaning the Sys object evidently also implements other interfaces, I just have no idea which ones...). In addition, in the multitudes of not-so-useful interfaces referenced in Interop.TestComplete.dll, not one of them seems to correspond to the Log object (or any other runtime scripting object). So obviously these interfaces are either inexistant or not exported. No worries, I have other tools...
Next, let's try reflection! TypeName function in VBScript reports Sys object is of type IDispatch. "Great!", I think to myself, "I can use reflection to reconstruct the COM type and instanciate it in .NET!". Standard reflection, however would not work through a late-bound COM object. So I reuse this little gem that has always worked for me in the past:
http://www.codeproject.com/Articles/523417/Reflection-with-IDispatch-based-COM-objects
The only problem is that the GetTypeInfo method of the IDispatch interface is not implemented in the TestComplete object!
So TestComplete objects advertise IDispatch implementation, but it is an incomplete implementation... That's just great...
Can a senior dev working on TestComplete possibly take heed of these comments and do something about it? Would it really be so hard to add a couple of interfaces to your already humongous pile to cover the runtime scripting objects? Or maybe implement IDispatch properly? Or even give me a list or ProgIDs or CLSIDs for the runtime scripting objects?
The documentation around "connected" applications stinks. I don't understand how you expect people to develop competitive, modern "connected" applications without you supplying comprehensive documentation on the interfaces, types and programming model for your API.
I apologize if this sounds harsh, but man everytime I try something with this clumsy API I lose massive amounts of time just trying to guess things that should be clearly documented.
The only issue is that no autocomplete is available, no documentation is available, only late binding is supported, etc etc etc... Can no one see how this is a problem? It basically makes connected applications a big pile of useless stinking static code. It removes any advantage I would have potentially got from using a managed language to write my tests.
So I played around. Simplest way I figured I could try to fix the problem is by looking at the internal interfaces exported through Interop.TestComplete.dll. The closest match I could find for the Sys object is the ItcSysNode interface, but it is incomplete (meaning the Sys object evidently also implements other interfaces, I just have no idea which ones...). In addition, in the multitudes of not-so-useful interfaces referenced in Interop.TestComplete.dll, not one of them seems to correspond to the Log object (or any other runtime scripting object). So obviously these interfaces are either inexistant or not exported. No worries, I have other tools...
Next, let's try reflection! TypeName function in VBScript reports Sys object is of type IDispatch. "Great!", I think to myself, "I can use reflection to reconstruct the COM type and instanciate it in .NET!". Standard reflection, however would not work through a late-bound COM object. So I reuse this little gem that has always worked for me in the past:
http://www.codeproject.com/Articles/523417/Reflection-with-IDispatch-based-COM-objects
The only problem is that the GetTypeInfo method of the IDispatch interface is not implemented in the TestComplete object!
So TestComplete objects advertise IDispatch implementation, but it is an incomplete implementation... That's just great...
Can a senior dev working on TestComplete possibly take heed of these comments and do something about it? Would it really be so hard to add a couple of interfaces to your already humongous pile to cover the runtime scripting objects? Or maybe implement IDispatch properly? Or even give me a list or ProgIDs or CLSIDs for the runtime scripting objects?
The documentation around "connected" applications stinks. I don't understand how you expect people to develop competitive, modern "connected" applications without you supplying comprehensive documentation on the interfaces, types and programming model for your API.
I apologize if this sounds harsh, but man everytime I try something with this clumsy API I lose massive amounts of time just trying to guess things that should be clearly documented.
