The error while not terribly helpful is correct. TypeLibs need to point at the server that implements them. Harvesting a TypeLib alone does not have enough information to fill that field in so you need to provide it yourself.
Heat is not currently developed enough to simply harvest the output and insert into your code. It often needs a little extra love.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The error while not terribly helpful is correct. TypeLibs need to point at the server that implements them. Harvesting a TypeLib alone does not have enough information to fill that field in so you need to provide it yourself.
Heat is not currently developed enough to simply harvest the output and insert into your code. It often needs a little extra love.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
The specific problem here is that TypeLib harvesting doesn't correctly deal with:
Fabio was trying to harvest Flash11e.ocx.
The Win64 issue will show up when you try and harvest the 64bit Flash ActiveX control (Flash64_11_1_102.ocx) or its current equivalent.
Last edit: Anonymous 2013-11-26