Fortran COM server

Fortran COM server

Hello All,

I am considering wrapping an existing large Fortran 90 application as a COM server to expose much of its functionality for use in a scripting environment be it Visual Basic, ActiveState Perl or Python etc. I have conducted a few small scale tests and like the results.

However, before proceeding I would be interested to hear of any "bouquets or brickbats" from Visual Fortran developers who have made substantial use of the Fortran COM server tools.

One particular aspect of such an endeavor that concerns me is how screen IO generated within the Fortran COM server will be handled?

Many thanks,
David Vowles.

14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I have been using the com server thing and has worked out very well.

The only big problem I have found is that debugging is terribly hard. But I have no good idea how to make it easier. Perhaps writing your own client is redundant but may help.

As far as screen IO is concerned: Just avoid it.

I'm considering doing something similar. Why do you say that "debugging is terribly hard"?


It is hards beacuse ...well you just can;t do it. The only way I know harks back to the days of punch cards and IBM-360! You just debug as much as you can in your head, then when that fails you have to write the diagnostic info to a text file, recompile, reregister, also that yo uhave to close masccess between all this, rerun the client, then look at the text file. The fastest turnaround for me was 5 minutes just to look at something trivial. Then your code will be littered with these outputs lines. The problem really hits when you have strange puzzles which requires LOTS of this silly repetitive exercise.

As I said, perhaps writing your own fortran client will allow you to use the real debugger, but I have not tried it. Also there is a minor difficulty with the module wizrad, it can;t handle 2d arrays, but there is a manual workaround which goes in the autoamticallt generated wrapper, this means if you have fix the wrapper every time you change the interface of your server. granted this likely won;t be too frequent.

If you find any other way to debug without rewriting the client please let me know. Actually I;d like to know if even having a CVF client will allow normal debugging. In retroscpect it is well worth finding out. I gave up the idea when the 2d array thing failed and I did not get an answer from vfsupprort on it for a long while.


Maybe DebugBreak API could help -- didn't actually try it. Try inserting it somewhere at COM server's entry point(s) and make sure "just in time debugging" is checked in VS's tools/options/debug. That should cause a breakpoint to be hit upon running and invocation of VS debugger -- I just hope that it would invoke original source files too, not just disassembly.


I posted a similar question (debugging COM Servers) with no responses. I have been debugging by having the server write to a log file, a very cumbersome technique.

The COM Server Wizard is an outstanding tool, and I hope the VF people continue to develop it. The problem is that most people don't understand how easy it is to develop automation servers using the Wizard, and the incredible number of possibilities it opens (scripting with ActivePerl, for example). There is also so little information, online or otherwise, regarding Fortran automation server development. I am writing an article for a statistics journal on developing Fortran components, featuring the COM server Wizard. It would be great if there was some discussion forum for developers using VF to develop automation servers. Does anyone know if such a forum exists? If not, can we start one?

I tried the debigbreakidea but all that happened was the whole msaxsclient shut down, this time without even giving the error screen. If anyoine get sthis to work I;dlike to hear it.

Also I think that there are different kinds of errors wich maybe treated differently, thugh they do not seem to correlate with any notions of severity from the cvf side of.

But as an aside, I;d like to see an example of using activepearl.


This might miss the mark totally, but for debugging couldn't you just set your executable (regardless of language or even if you had source for it) as the startup program? (In Visual Studio goto Project->Settings, Debug tab, "Executable for debug session:"). You may have to set the project you are trying to work with as an additional dll.


I was able to debug the "in-process" server (dll) in the ADDER sample, that comes with VF 6.6 . I did it by running the VFAdder client program, and placing a breakpoint in the IAdd_Add method. It worked! So you can debug an in-process server by calling its methods from a debuggable program. Now I want to test debugging an "out-of-process" (exe) server. I'll post my results.

OK, I tried to debug an "out-of-process" (exe) COM server. I compiled the Debug configuration of the COM server, then created a Fortran COM client w/ the help of the Module Wizard, and then set a breakpoint in my COM server. As soon as I started debugging a dialog came up saying, "One or more breakpoints cannot be set and have been disabled. Execution will stop at the beginning of the program." It refuses to debug the COM server, though it is happy to debug the client. It must be because the server is a completely separate process, whereas an in-process server like the ADDER example runs within the same space as the client. If anyone has a solution to this, please respond to my posting "Debug COM server" posted 2/26/2002.

Well, I'm glad you verified that at least by duplicating some work and writing a cvf client you can debug the in-process app. But you realize that in many cases like ours here, it is not even as easy as writing a separate client. In our app a large amount of data is culled from axs which then calls the com-server. writing a new client will not get the data I need fro axs to reproduce problem spots, unless I undertake a whole new level of trouble using f90sql and all that.

I think that the DebugBreak has potential, but how?. Would be nice to see how this is handled in the more popular compilers such as VC--, VB, delphi etc.


Good news Tim, I think. I created a VB program that uses the ADDER server. In the ADDER COM server project I went to settings, debug tab. I set the "Executable for debug session:" to the VB program. I set a breakpoint in the "Add" method. Then I hit F5 and the VB app started. When the VB app called the Add method, it stopped at the breakpoint and showed the correct variable values. So you can debug your in-process COM server methods when they are invoked from external applications (at least VB). Hope this is helpful.

David, with regards to running an out of process server, I think there are 2 things you can do. One is set the "Additional Dlls" to the current project (find this on the Settings Debug tab in the Category drop down). Browse to get the project you are trying to debug (even if it is the active project).
The second thing is start the executable you want to debug with the breakpoint set. Fire up the app that uses it. This should enable your breakpoints.
Hope this helps.

Success! The first suggestion did not work, but the second one worked great. In my exe COM server project I set a breakpoint and hit F5 to start the COM server. Then I launched my VB app independently. As soon as I called my method, it stopped at the breakpoint and I could start debugging. Many thanks!

Leave a Comment

Please sign in to add a comment. Not a member? Join today