For some years I have used the Intel Fortran module wizard to generate the COM code necessary for communicating with Excel. Recently I upgraded to VS2013, with the Intel Fortran compiler 15.0.0.108. This upgrade appears to have introduced a conflict with my existing COM code. I have tried generating new code using the Fortran module wizard, but now receive a range of error messages when I try to compile. I am doing the following:
1) Selecting the Microsoft Excel 15.0 Object library from the COM components
2) I leave the "Generate code that uses Automation interfaces" unchecked (for efficiency)
3) Select the _Application, _Workbook, and _Worksheet members
4) I leave the "Generate DLLEXPORT statements" unchecked (I use this module internally)
5) press the finish button.
Code is then generated. When I try to compile, I receive the following error messages:
Error 1 error #6401: The attributes of this name conflict with those made accessible by a USE statement. [WORD] C:\MyFiles\MODEL_LAB\FORTRAN\EXCEL\EXCEL.f90 534
Error 2 error #6445: A dummy argument is required in this context. [WORD] C:\MyFiles\MODEL_LAB\FORTRAN\EXCEL\EXCEL.f90 534
Error 3 error #6445: A dummy argument is required in this context. [WORD] C:\MyFiles\MODEL_LAB\FORTRAN\EXCEL\EXCEL.f90 535
Error 4 error #6717: This name has not been given an explicit type. [WORD] C:\MyFiles\MODEL_LAB\FORTRAN\EXCEL\EXCEL.f90 530
Error 5 error #6075: The data type of the actual argument does not match the definition. [$BSTR_WORD] C:\MyFiles\MODEL_LAB\FORTRAN\EXCEL\EXCEL.f90 11255
Error 6 Compilation Aborted (code 1) C:\MyFiles\MODEL_LAB\FORTRAN\EXCEL\EXCEL.f90 1
I attach the F90 file that is generated by the wizard for information. Any help resolving this issue is greatly appreciated.
Justin
链接已复制
I know nothing about the requirements of making your application work with Excel, but the type WORD is pre-defined in IFWINTY (in DOS 2.x, WORD was a 16-bit integer), so change line-531 by adding a rename clause to
USE IFWINTY, except=>Word
so as to avoid the name clash. If you want to use the predefined type in your code, you would need to change the argument variable name from Word to Wrd or something different from WORD, instead of using a rename clause.
This suggestion sorts out the compile error I was getting, but it turns out that it doesn't solve my principal problem. There seems to be some sort of problem with the range_select subroutine generated by the module wizard when used with Excel 2013 and Windows 8.1. I have no problems using the code with Office 2010 and Windows 7. I am receiving an "Automated method exception" error, which states that the "Select method of Range class failed". Is there some sort of work-around for this?
Justin
This is odd, as I am not doing very much:
- I copy the Autodice example that is shipped with Intel(R) Visual Fortran Compiler XE 15.0.0.108: C:\Program Files (x86)\Intel\Composer XE 2015\Samples\en_US\Fortran\COM.zip\COM\AutoDice
- I open the example solution in Visual Studio 2013
- I select the x64 platform
- I build the solution
- I run the debugger
- I select "no" when asked if I want a read only version of the Excel file that Autodice opens
- I get the error that is attached in the screenshot
I am using Office 2013 on a Windows 8.1 OS. I do not find any problem when I run this on a computer running Windows 7 and Office 2010.
Many thanks for your help,
Justin.
.png){kind=link}
I am fairly sure that this has something to do with the Windows 8.1 OS - I have run a test with Office 2013 on Windows 7, and this works perfectly as well. Any help would be greatly appreciated, as I expect that this may become a problem with users of my application some time soon,
Justin.
Ok - I can reproduce this on Windows 8 (I don't have 8.1 yet), not on Windows 7 (with Office 2013). It works with a Win32 build. Any particular reason you need a 64-bit build? Looking at the error message I think there is a 64-bit address being truncated somewhere.
Thanks for persisting with this issue Steve.
Unfortunately the routine that I produce is fairly memory intensive (I'm an economist, and produce a model for government based on dynamic programming methods), so that stack-overflows are easily encountered with 32bit. I guess that this is a problem that Microsoft needs to fix. If so, is there some way that we can bring this issue to their attention?
Justin.
I don't know yet if it is Microsoft's problem or ours. I will let you know what we find.
However, stack overflows would be the same for 32-bit or 64-bit, since Windows doesn't change the amount of stack available. Consider enabling the Fortran Optimization > Heap Arrays > 0 option to use dynamic memory for things that would otherwise use the stack.
Thanks again for persisting. Three years ago I played around with using the heap arrays option, but dropped it for reasons that I cannot quite recall. If this problem is noted by any of the users of my application, then I will try to sort out a patch using the 32bit approach that you suggested. In the mean time, I will keep my fingers crossed that this issue can be resolved before it becomes an issue on my end.
Justin
An update on this issue - I have found that the Autosetproperty command, which is the source of the problem here, will work if it is used to pass one element at a time, rather than an entire vector. A similar issue applied prior to Windows 8.1, but only to multiple columns as far as I can recall.
Passing one element at a time, rather than entire vectors, takes longer and so it would still be great to get this issue sorted out.
Justin.
I re-tested this issue with Windows 10 and the 16.0 compiler, and the problem persists. I have implemented a work-around in my code to write output in CSV format, and read it into Excel via a VB macro (my users like looking at results through Excel). Would be nice to sort this problem out as I am slightly nervous about it - I do a great deal of reading from Excel into Fortran, and similar issues seem to be associated with the AUTOGETPROPERTY, which crashes (as I recall) when used to read from multiple columns in a single call.
