- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi - I am looking for advice on how to organize a software package that is supposed to do this:
(1) The main program is written in Visual Basic 6. It will call a routine or routines written in Fortran. VB6 can do this only if the Fortran code is in the form of a DLL. I have been successful previously doing this (including wrapping the Fortran library in a thin C++ layer in order to take advantage of structural exception handling). This time, though there are additional wrinkles.
(2) The main program makes an initialization call to Fortran in order to set up a very large data structure that includes pointers to data within it;
(3) The main program then makes repeated calls to Fortran and makes use of this structure;
(4) The data structure must persist between its setup and the subsequent calls.
How is this best done, please?
Robert Rackl
r4
(1) The main program is written in Visual Basic 6. It will call a routine or routines written in Fortran. VB6 can do this only if the Fortran code is in the form of a DLL. I have been successful previously doing this (including wrapping the Fortran library in a thin C++ layer in order to take advantage of structural exception handling). This time, though there are additional wrinkles.
(2) The main program makes an initialization call to Fortran in order to set up a very large data structure that includes pointers to data within it;
(3) The main program then makes repeated calls to Fortran and makes use of this structure;
(4) The data structure must persist between its setup and the subsequent calls.
How is this best done, please?
Robert Rackl
r4
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
have you tired either of the following:
x = Shell(commandtoexe, wintype%)
or
x = Winexec(commandtoexe, 0)
to run a win32.exe (like an intel fortran exe) from VB6??
commandtoexe is simply a concatenated string with all the arguments, etc you want to pass to the exe.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have considered creating a separate executable and just starting it as you suggest. I then must find solutions for how to pass information back and forth, and synchronizing the two applications. It would be so much cleaner to be able to just call subroutines that reside in the DLL.
r4
r4
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - r4
I have considered creating a separate executable and just starting it as you suggest. I then must find solutions for how to pass information back and forth, and synchronizing the two applications. It would be so much cleaner to be able to just call subroutines that reside in the DLL.
r4
r4
Have you tried adding the SAVE attribute to the variables you want retained between calls? This seems to work for DLL's called via VBA from Excel.
It is my understanding that normally a DLL will remain loaded once called nd isn't unloaded until the executable closes. It is not loaded from scratch each time you call the DLL.
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Robert,
It sounds like we do something similar. We have a VB GUI that calls several Fortran DLLs. We generally allocate the data arrays in VB, then pass them to the DLLs to do the calculations and other operations, which fill the data arrays. I think that by allocating the arrays in VB (executable), the data array values will persist between calls. And I think that there isn't really any additional memory "cost" with this approach (would like to know if there is). We also have an array or two of parameters related to the calculations that are passed back and forth, which are used to initialize the local DLL variables on each call.
And a question: does the SAVE parameter in Fortran guarantees the DLL local variables to keep their value between calls to the DLL?
We have also had to be quite careful with error trapping in the DLLs. For example, if there is a math error (divide by zero or square root of a negative number) or a memory error when allocating a local array, we do some extra clean-up before exiting a subroutine and the DLL. This has helped us to cleanly exit the DLL, allow changes in the GUI, and then try again without having to quit the whole program. It has been helpful for us to use the many error trapping parameters like STAT, ERR, etc.
Regards,
Greg
It sounds like we do something similar. We have a VB GUI that calls several Fortran DLLs. We generally allocate the data arrays in VB, then pass them to the DLLs to do the calculations and other operations, which fill the data arrays. I think that by allocating the arrays in VB (executable), the data array values will persist between calls. And I think that there isn't really any additional memory "cost" with this approach (would like to know if there is). We also have an array or two of parameters related to the calculations that are passed back and forth, which are used to initialize the local DLL variables on each call.
And a question: does the SAVE parameter in Fortran guarantees the DLL local variables to keep their value between calls to the DLL?
We have also had to be quite careful with error trapping in the DLLs. For example, if there is a math error (divide by zero or square root of a negative number) or a memory error when allocating a local array, we do some extra clean-up before exiting a subroutine and the DLL. This has helped us to cleanly exit the DLL, allow changes in the GUI, and then try again without having to quit the whole program. It has been helpful for us to use the many error trapping parameters like STAT, ERR, etc.
Regards,
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - greg_thorwald
And a question: does the SAVE parameter in Fortran guarantees the DLL local variables to keep their value between calls to the DLL?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No surprise - as long as the DLL remains loaded, any changes made to SAVEd variables will persist. Funny, I've seen several requests over the years from users who wanted the opposite - for variables to automatically return to their initial state on subsequent calls.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Steve Lionel (Intel)
No surprise - as long as the DLL remains loaded, any changes made to SAVEd variables will persist. Funny, I've seen several requests over the years from users who wanted the opposite - for variables to automatically return to their initial state on subsequent calls.
Hi Steve, I am working with a minpack fortran 90 dll, using in Clarion and wish to do what you sad: return variables to their initial state between calls... but I don't know to do that... I will really appreciate some help...
my bests,
Conrado
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is no way to do that other than writing and calling a routine to do the "reset". If you had control over the loading of the DLL, you could unload the DLL (with a call to FreeLibrary) and then load it again, but this is not available to you when you are using the DLL from VB.NET, etc.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page