CVF Module Wizard doesn't find a subroutine in an OCX file

[kvrichardson]

Hello -

I need some help working with a 3rd party OCX file in Compaq Visual Fortran Professional 6.6B.

I bought an ActiveX/OCX file WordconverterX.ocx
which converts Excel or Word files to text/CSV/DBF/etc.
It promises Visual Studio 6.0 compatibility and the module wizard reads it and created a module in WordConvertX.f90. But there is one program - OpenWCXDll - that is not found and no wrapper is
presented in WordConvertX.f90.

As it says in the Wordconverter Documentation, none of the conversion functions will work until OpenWCXDll (ikey) is called, where ikey is my security key for the
product. Since it is not found by the module wizard, I can't call it directly.

The call loading the OCX - COMCreateObjectByGUID - works fine - it returns a CLSID for Wordconvert and istatus returns 0. Other COM commands work fine, too - it is just the Conversion functions that fail. So it must be
the security issue.

The Visual Basic demo provided with WordConverter calls OpenWCXDll (ikey) in WordconverterX.ocx, using a wrapper:

Attribute VB_Name = "modDLLWrapper" Declare Function OpenWCXDll Lib "D:...WordConverterX.OCX" (ByVal key As Long)
As Boolean

Right below this in the bas file are the remainder of
the functions that the Module Wizard did find, (including the Excel conversion utility I want to get to work.

Declare Function ConvertWordDOC Lib "D:...WordConverterX.OCX" (ByVal SourceDoc As String, ByVal TargetDoc As String, ByVal
TargetType As Long) As Long
etc
etc

Is there a reason the Wizard doesn't find OpenWCXDll that can be addressed?

If not, what is a good way to get access to that routine that evidently is exposed in Basic.

WordConverterX.lib and WCX_DLL_Exports.h were also provided in the Wordconvert package, but they didn't seem to help with the missing OpenWCXDll
subroutine. I added the lib in the project link tab.

I could use the command line program WCX.EXE provided with WordconverterX, but prior to the call you must somehow set the key firstand then call
EnforceShareware. My call to EnforceShareware (which is present in the WordConvertX.f90 module generated by the Module Wizard) fails,probably because it is expecting some variable to be set to my security key prior to the call. That is how the Wordconverter Visual Basic demo does it:

frmDemo.WordConverterX1.Key = mlKey ' Must enter a valid key here
frmDemo.WordConverterX1.EnforceShareware

I think I foundthe character name of the OCX in the registry and was thinking that perhaps I should append '.Key' to it and try to set it to my security key,
but I found no AUTO or COM subroutine that would allow me to set that class member by string. And it isn't listed in the Module Wizard module file.

I tried the Module Wizard using various settings but the "Type Library containing Automation Information" selection (as promised in the documentation
for OCX files) is the only one that reads the Wordconverter conversion subroutines into the mod created.

Any help on this would be greatly appreciated!

Thx,
Keith/AMS

[kvrichardson]

I'm begining to wonder if I'm attempting the impossible. Although the CVF documentation specifically mentions using the Module Wizard on ActiveX OCX files, the OLE_Viewer does not show the function I need in the case of this particular OCX, nor does it expose the KEY member. So my prospects to use the tool I bought yesterday aren't good.

Also I went to CanaimaSoft.com and noticed they sell a tool to use OCX files in CVF - if they have a market, perhaps theres a reason for that !

In any case the point is moot....Ibought F90SQL at CanaimaSoft to read the XLS files instead. I'll need the full read/write functionality of F90SQL for the future. I particularly like the Query Wizard that generates F90 code to process XLS files. WordConverter has very limited functionality and offers the read only.

Thanks,

Keith /AMS

[g_f_thomas]

"I'm begining to wonder if I'm attempting the impossible. Although the CVF documentation specifically mentions using the Module Wizard on ActiveX OCX files, the OLE_Viewer does not show the function I need in the case of this particular OCX, nor does it expose the KEY member. So my prospects to use the tool I bought yesterday aren't good."

Sure they are! The AX works fine from VB. So create a VB AX.DLL which has the OCX on a form and with

WordConverterX1.Key = mlKey
WordConverterX1.EnforceShareware

in the load event. Presumably the OCX displays a dialog in which you identify the source (.doc,.xsl, etc) and the destination (.txt,.rtf, etc)and hey presto. So use the LoadLibrary API from CVF to load the VB AX.DLL and let VB strut its stuff. No need for COM boiler plating.

HTH,
Gerry T.

PS This is not an attempt to dissuade you from using the CanaimaSoft.com products which by all accounts are excellent (long time no hear Marco!). It's just that the WordCovertX is expensive and you might as well get some use out of it no matter how limited.

[kvrichardson]

Thanks for trying to save my investment but I'm not a VB user - working exlusively with CVF = Compaq Visual Fortran (and Winteracter and now Canaima's F90SQL, which works great!).

What you listed was the VB code I mentioned in my e-mail - I was looking for Visual Fortran conversion of same.

Thanks anyway!

Keith/AMS

[g_f_thomas]

Out of curiosity I peeked at the type library for the MFC-built WCX.OCX: the members 'Key' and 'FilesProcessedCount' each have InvokeKinds of INVOKE_UNKNOWN which is probably why the CVF Module Wizard skips over them. It picks up the remaining dozen members, including EnforceShareware. It's trivial to modify the Wizard's .F90 module to supply the two missing interfaces with which you might to be able to use the control programmatically via Fortran if you can figure out how to contain it.

Good Luck,
Gerry T.