During conversion of older sources to TD60, I re-generated all ActiveX/COM components using TD60 ActiveX explorer.
Everything is the same: the names of the generated classes and also the methods.
All other sources using the newly created COM apl classes do compile ok.
But on some cases, at runtime the COM instances do not work. Sometimes they do and sometimes the Create function fails (no runtime TD error messages).
They just return FALSE on the Create method.
When checking the source using the IDE, there seems nothing wrong. Even the ACA shows all methods on the ComProxy instances.
When comparing code which is working against the ones not working there is no visual difference between them.
The objects are all of the same class and the usage is 100% equal. But one works at runtime and the other does not.
So then I opened the faulty sourcecode using a text editor to look at the internal items at the place of the faulty and working code.
Here the working code:
Code: Select all
.head 4 + Local variables
.head 5 - ComProxyVar: LReportingComponent
.head 6 - Class: ClsReportingComponent
.head 5 - Boolean: bTemplateFound
.head 4 + Actions
.head 5 + If LReportingComponent.Create( )
.head 6 - Call LReportingComponent.IsWordTemplateFound( "c:\\test.dot", bTemplateFound )
.head 6 - Call LReportingComponent.Release( )Code: Select all
.head 4 + Local variables
.head 5 - FunctionalVar: LReportingComponent
.head 6 - Class: ClsReportingComponent
.head 5 - Boolean: bTemplateFound
.head 4 + Actions
.head 5 + If LReportingComponent.Create( )
.head 6 - Call LReportingComponent.IsWordTemplateFound( "c:\\test.dot", bTemplateFound )
.head 6 - Call LReportingComponent.Release( )Code: Select all
.head 5 - ComProxyVar: LReportingComponent
.head 5 - FunctionalVar: LReportingComponentInternally TD interprets the LReportingComponent variable as a FunctionalVar.
It should be a ComProxyVar.
So, when changing this in the text editor from FunctionalVar to ComProxyVar, the code works at runtime.
The Create succeeds and the methods work ok.
Another way to fix it in the IDE itself:
Go to the defined LReportingComponent variable, comment it and uncomment it. Then save.
By commenting and uncommenting, TD is forced to re-examine the type of the object. It sees it as a ComProxy type and sets this internally.
After saving, the variable has the correct internal type and the code works.
Issue with this is that you can not see in the IDE there is a problem. The variable IS of the correct type there.
But you can not see that TD has a wrong internal type. So you will not be tipped on the issue. Probably you will look into the COM component itself.
Recreating the COM apl does not help, as the instance of the COM Proxy class is incorrect. The COM proxy class itself is ok and works.
So when having many apl's and huge pile of sourcecode utilizing COM Proxy classes, you will not be sure if the code will work at runtime just by examining the code using the IDE.
You will have to look in the internal source using a text editor. This is for me a real issue, because there are hundreds of instances spread over hundreds of functions, class variables,
window variables etc etc. And to find them all, comment them and uncommenting them is a huge effort.
And to be frank, I think when I use the IDE and see that an object is of a specific type the object should really BE of that type.
I have extracted a testcase which can be used to reproduce the issue.
The form has a function with a local variable, an object of the COM Proxy type.
The IDE shows that. But using a text editor you will see it is not.
A fixed apt, there I just commented the variable and uncommented it and saved. The object is then the correct internal type.
I do not know what solution Unify can devise to prevent this. Code not touched will not be re-examined by the IDE.
Maybe during saving the source or at compilation, the types can be re-examined and set to the correct internal type.
Or maybe a new feature in the IDE to force TD to re-examine all code and reset the internals to the correct ones.
At least, I think many stumble upon this issue using COM in conversions. It would really help to fix internal issues when TD offers some kind of
way to reset the internals so you are sure no mismatches are present.
