- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
I've inherited a DVF DLL from a colleague. This DLL uses another DVF DLL, so there's a DLLIMPORT attribute. The code looks like this:
!DEC$ATTRIBUTES DLLIMPORT :: Q:AllChenxPcratingL10
I can't get this to compile! The compiler comes back with a bunch of "unrecognized token" exceptions for the backslashes. Then it gives me a syntax error because it reads the next line as the attribute! My colleague says he's never had a problem compiling that line. Is there a switch in the project settings that I'm missing?
Thanks in advance,
Robin Olson
I've inherited a DVF DLL from a colleague. This DLL uses another DVF DLL, so there's a DLLIMPORT attribute. The code looks like this:
!DEC$ATTRIBUTES DLLIMPORT :: Q:AllChenxPcratingL10
I can't get this to compile! The compiler comes back with a bunch of "unrecognized token" exceptions for the backslashes. Then it gives me a syntax error because it reads the next line as the attribute! My colleague says he's never had a problem compiling that line. Is there a switch in the project settings that I'm missing?
Thanks in advance,
Robin Olson
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The code is wrong - the DLLIMPORT directive should name the routine (as called by Fortran), not the DLL file (which is found using the normal Windows path rules.)
For example, you might have:
!DEC$ ATTRIBUTES DLLIMPORT :: MY_SUB
...
CALL MY_SUB
This DLL should then link against the export library (.lib) of the DLL being called.
Steve
For example, you might have:
!DEC$ ATTRIBUTES DLLIMPORT :: MY_SUB
...
CALL MY_SUB
This DLL should then link against the export library (.lib) of the DLL being called.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
I've had the same suspicions about the code - in the past, I've always given the DLL reference in DLLIMPORT, not a file and path name. He says he's doing it because the application which uses these DLLs is written in Excel VBA and the user's Excel settings control the default path.
Does that matter with DLLIMPORT? I thought the calling DLL would look for the called DLL according to the Windows path settings. However, we're getting "Error 53: File not found" when we try to call our DLL from Excel. All of the dependents for both DLLs are in place and the VBA DECLARE statements include the DLL paths.
Also, if the code is wrong, do you have any idea why his copy compiled and mine won't?
Thanks for the help!
Robin
I've had the same suspicions about the code - in the past, I've always given the DLL reference in DLLIMPORT, not a file and path name. He says he's doing it because the application which uses these DLLs is written in Excel VBA and the user's Excel settings control the default path.
Does that matter with DLLIMPORT? I thought the calling DLL would look for the called DLL according to the Windows path settings. However, we're getting "Error 53: File not found" when we try to call our DLL from Excel. All of the dependents for both DLLs are in place and the VBA DECLARE statements include the DLL paths.
Also, if the code is wrong, do you have any idea why his copy compiled and mine won't?
Thanks for the help!
Robin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can get the file-not-found error if DFORRT.DLL is not installed or isn't on the path.
I seriously doubt his code compiled as-is, unless it was by a very old compiler that didn't accept !DEC$ATTRIBUTES (instead of !DEC$ ATTRIBUTES) and just ignored the directive.
Steve
I seriously doubt his code compiled as-is, unless it was by a very old compiler that didn't accept !DEC$ATTRIBUTES (instead of !DEC$ ATTRIBUTES) and just ignored the directive.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
DFORRT is installed in the system directory, so that's not the problem. And he's running the same copy of DVF that I am. I guess I'll have to stand over his shoulder and watch his compile! (I work remotely, so I haven't had the opportunity to do that.)
Thanks for all the help!
Robin Olson
DFORRT is installed in the system directory, so that's not the problem. And he's running the same copy of DVF that I am. I guess I'll have to stand over his shoulder and watch his compile! (I work remotely, so I haven't had the opportunity to do that.)
Thanks for all the help!
Robin Olson
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Remember also that L10.DLL needs to be located by Windows default rules. Either in the PATH or in the same folder as EXCEL.EXE. The folder your DLL that calls L10 is in doesn't matter.
Steve
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
I'll look into the L10 location. Thanks!
Robin Olson
I'll look into the L10 location. Thanks!
Robin Olson
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