Fortran - Basic

Fortran - Basic

I would like to make a nice user-friendly program using my old code in Visual Fortran. To build the interface, I would like to use Visual Basic. Since I have no experience with this, I would like to ask if anyone could give me an advice on where to start.
Should I convert my code to dynamic link library? Should I use component object model?
I'll very appreciate any help,
Thank you,
Milan

publicaciones de 10 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Milan,

my suggestion is to build DLL and call it from GUI (in VB) (to avoid some frustration before that check carefully calling conventions in both, I mean CVF and VB). COM leave for the next step. However, all it depends on what you, eventually, gonna do with your software

Artur

Artur,
Thank you very much for your reply. The user of the final software should just insert initial settings for simulations. Then the program will run simulations for a number of hours (for example during the night). Then user should get results in the following morning. In fact, the code is pretty long, declaration of variables is done within modules and there are subroutines that call other subroutines and functions (in total 30 subroutines and functions). I tried to build DLL using just one subroutine and call it from VB, which works. But calling another subroutine within the subroutine seems to be more difficult. I'm also concerned about the data declaration. So I have another idea. Maybe I could just save initial settings to a file (from VB interface), then run the VF executable program, save results to another file and use VB to read and evaluate the data. But here the main concern comes: Once the initial file is generated (in VB), can I call the Fortran executable program (.exe) from VB environment to start running? That would save me a lot of time and energy.
Please, be so kind and send me your opinion. Thank you again,
Milan

I use VB and Fortran quite a bit in my application. I do not use COM, but I have turned a very large .exe into a .dll. Using a Call from VB into a subroutine gives you more control for passing messages back and forth rather than shelling out to an executable from VB. The VB will Shell out, but then keep running.

Calling more than one subroutine in a .dll should be just as easy as calling one. You should have matching declares in your VB code and export statements in your Fortran for each subroutine you may call from VB.

Passing data in both directions is then easier. You just need to learn how to pass each data type. Make sure your integers, logicals and reals are the same size. To keep passing string data simple, I pass only non-array strings into Fortran and keep the strings a width that Fortran expects. You can have Fortran receive this parameter into an array and it will automatically be divided up into its elements in Fortran.

For example, if I have a character array in Fortran that has a LEN of 10 and 10 elements, I would pass a string of length 100 in VB.

You can pass string arrays from VB, I have never done this, but seems more difficult from examples I've seen.

I have been trying to convert some of my Fortran exe's to dll and calling them from VB5.0. I've tried a small exe by converting it to a subroutine and compiling a dll using developer's studio. The subroutine currently has no arguments. The I/O are all files. One subroutine is called within the dll. I get the following error:
run-time error '453'
Can't find Dll entry point WOPFRM in
d:lm2wopfrmdDebugwopfrmd.dll

I get the same error for the bigger program. Could you shed some light on fixing the problem.

Online help says you might check:

1) Make sure the Fortran code has specified the ATTRIBUTES DLLEXPORT for the routine name (see the cDEC$ ATTRIBUTES compiler directive).
2) Make sure the Fortran code has specified an ATTRIBUTES ALIAS name that exactly matches the name declared by the Basic code (see the cDEC$ ALIAS directive, which also can be used as an ATTRIBUTES option ALIAS).
3) Make sure you are referencing the correct yy.dll.

In my student computer (where VF is not installed) I have to place dll files directly into system or system32 folder. It didn't work under e.g. Student_Files folder. I also got to same issues with the security options on my student computer. Be sure the pathway is correct. I don't specify the pathway - just give a name to a dll that should be unique.

Milan

Milan,

I've had some experience in such stuff using Delphi and CVF. DLL(s) combined with GUI is what you want (as a start). You need simply to rebuild a bit program structure and write kind of wrapper calling all your Fortran routines with data/parameters from GUI or maybe just turn main Fortran program unit into DLL with initializing data passed from VB (strongly depends on specific application structure). I think that it's not a bad idea to pass data/parameters from GUI via the derived data type variables (you won't need to rewrite calling statements if you need to add other parameters/data etc.) (guess VB supports them).

Running exe from VB? Unfortunately, have no experience in that. You can use the Windows API calls CreateProcess or ShellExecute. the former starts the application associated with a given document extension. Take a look here. The latter loads and runs any application (or process) you want. Example here . Simply VB documentation will help you.

One more thing. Results. I'm more than sure that User will be just happy to get results as worksheets, database files, presumably charts and edited Office documents. Here COM Automation will be of great benefit. You can do it from CVF but I'd suggest to start with VB as it's pure Office, Excel, PP etc. stuff and, moreover, it should be much easier. Naturally, to get the charts within your app window you can use ActiveX controls (for scientific apps ArrayVizualizer from CVF usually serves just great). If need other charts or options it is, sometimes, a good idea to buy specifically designed tools (I personally like and use TeeChart).

Artur

First, I would like to thank you for your time answering my questions. It has been a very good help.
Yes, I think I'll build DLL from my current program. I tried an example using subroutine calling another subroutine and it works good. The only concern that I have is passing the variables. I have a big number of variables holding statistics and supporting data that I need to pass into main subroutine and back to VB. Can I pass that in single declaration statement in VB module? Or is there another way to do that?
Another question: I have currently two modules (fixed_storage) and (allocatable_storage) in my VB program. Can I still use these modules after converting my code to DLL?
Thank you again very much for your answers,
Milan

Milan,

think you can. My experience is that derived data type is useful in such situations, especially when your code is enhanced, rebuild etc. Try to pass what you need checking the calling convention. And that's it. Don't get what you mean by using these VB modules. You have the GUI written in VB. It passes data to DLL (there calcualtions are performed) and, in return, gets results. Nothing more changes.

Artur

One thing to keep in mind is that there is a limit on the number of parameters you can pass in one call. I don't remember exactly, but I can probably find out if you think it will be an issue. I think it may be around 64 parameters in one call statement.

In my project, I am passing hundreds of different variables down to my Fortran program, some of these variables have quite a bit of data. I accomplished this through many separate calls from VB to different Fortran subroutines, built to receive the data. I then call the routine to do the main processing using all of this data with only a couple of parameters to return status information.

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya