Thanks, Pete.

I didn't mean that converting from VB 6 to VBA would be hard, but rather
that converting from VB 6 to VB 2010 would be hard.

Steve

"Peter T" <peter_t@discussions wrote in message
...
Sorry for the accidental post

I can't add to the reply given by Charles but just this bit

The DLL is coded in VB 6.0, so we cannot compile it into a 64-bit DLL.
We've looked into porting it to VB 2010, but that would be an
impractically-large project because the DLL has about 25,000 lines of
code, much of which would require manual conversion.

Are you sure so much would need conversion. Apart from Form code, which
would indeed need to be re-made, I imagine there'd be much less in the way
of conversion required from VB6 to VBA than the other way round.

Regards,
Peter T


"Steve Flaum" wrote in message
...
We have an app which creates large Excel workbooks. For example, one
workbook has 1,000 worksheets. In other cases there are fewer worksheets
but the Excel file can be 80 MB or larger. Since this sometimes crashes
Excel 2007 and 2003, I'm considering using 64 bit Excel 2010. Would
64-bit Excel be more reliable with workbooks this size than 32-bit Excel?
Is 32-bit Excel 2010 any more (or less) reliable with large workbooks
than Excel 2007?

The problem with using 64-bit Excel is that the workbook uses a 32-bit
native code DLL. Specifically, the workbook executes a VBA macro with the
following statements:

Dim mCCalc As Object
Set mCCalc = CreateObject(strName, "")
mCCalc.Init Application

The 32-bit DLL executes many Excel methods, using the reference to Excel
passed in the 3rd line above.

The DLL is coded in VB 6.0, so we cannot compile it into a 64-bit DLL.
We've looked into porting it to VB 2010, but that would be an
impractically-large project because the DLL has about 25,000 lines of
code, much of which would require manual conversion.

I've read that a 32-bit activeX control cannot be used with 64-bit Excel
2010, but this isn't an ActiveX control. Is there a way to use it with
64-bit Excel? For example, could Tlbimp.exe create a wrapper which would
make the 32 bit DLL look like a 64-bit managed-code DLL? If so, could I
call the latter from VBA? What would this do to execution speed? (The
current design runs the DLL in process with Excel, but can nevertheless
run for a couple of hours.)

Thanks.

Steve