Linking to 3rd party DLL files

136 views
Skip to first unread message

bill.l...@csquaredsystems.com

unread,
Nov 22, 2016, 5:08:57 AM11/22/16
to MapInfo-L
Our company creates an MBX file.  That does a load of our dll (Fusion.dll) into MapInfo.

Declare Function ConnectToMI Lib  "Fusion.dll" (ByVal pIDispatch As Integer) As Integer


 There are a couple of ways we can start MapInfo and our application that runs with MI.
                     * Note, during the use of MI and our app, we save a workspace, (.WOR) file.
1) We simply double-click on the MBX file and then through our program open a MS Access file. (Which will open the workspace (.WOR) file)
2) Open MapInfo then use Tools->Tool Manager->Open our .MBX file, then open the Access file.
3) Open MapInfo, open the workspace (.WOR), then Tools->Tool Manager->Open our .MBX file, then open the Access file.

Now, on to the problem: 
             Option 1 opens fine and have no problems.

             Options 2 and 3 error out. I get several (too many to count) "The specified module could not be found."  The files in question are .dll files, located in the directory with our .dll, but they are a third party's (MatLab).  For optons 2 and 3, I never get the chance to open our project file. I get the countless "The specified module could not be found." when I click our .MBX in the Tool Manager. We write in C++ and we have the .dlls from MatLab and link to them.  My problem is that when we use optons 2 or 3 these .dll files are not seen. Is there a way in an MB (MBX) file to link to a library or .dll file (or a directory with them?)

Eric Blasenheim

unread,
Nov 22, 2016, 8:26:13 PM11/22/16
to MapInfo-L
The errors have to do with what folders are on the Windows search path (not just the system path) when a DLL is loaded. The reason the double-click works and probably the Run MBX dialog (Ctrl-u) is that the windows "current directory" is the location of the other dlls and that is one of the places Windows will search for a sub-referenced DLL. I assume these MatLab DLLs are not referenced by MapBasic but rather by your Fusion DLL.
When you run your app via the tool manager, this might not be the case! However, I believe that this was fixed a while back by MI Pro always adding the MBX folder to the search path. What version of MI Pro are you running?

Regards,
Eric Blasenheim
Pitney Bowes Software

Bo Victor Thomsen

unread,
Nov 23, 2016, 3:59:53 AM11/23/16
to mapi...@googlegroups.com

As Eric explained, it's probably a problem with the search path. A simple fix would be to place all the called dll's in the same directory as the mbx. This directory is always searched for dll's before all other directories.

Another fix would be to explicitly include the necessary directories in the search path before starting MapInfo - or placing the dll's in a directory already in the search path.


Regards
Bo Victor Thomsen

Den 17/11/16 kl. 16:31 skrev bill.l...@csquaredsystems.com:
--
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

bill.l...@csquaredsystems.com

unread,
Nov 23, 2016, 2:33:20 PM11/23/16
to MapInfo-L
Eric,

I am on 12.5.  

Victor,

All files are in the same directory as the .mbx file.


On Tuesday, November 22, 2016 at 5:08:57 AM UTC-5, bill.l...@csquaredsystems.com wrote:

Uffe Kousgaard

unread,
Nov 23, 2016, 2:56:57 PM11/23/16
to mapi...@googlegroups.com
Hi Bill,

We call this winapi function to make sure our dll can find the next dll in the chain:
Declare Function SetDllDirectoryA Lib "kernel32" (lpPathName As String) As Integer

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx

We basically have the same setup as you: mbx calling one dll calling another dll.
I don't remember if the issue started with MapInfo 64-bit, win 10 or so. But it got solved.

Regards
Uffe Kousgaard
--

Bo Victor Thomsen

unread,
Nov 24, 2016, 10:15:11 AM11/24/16
to mapi...@googlegroups.com

Thanks Uffe, that's a great help ;-)

And to Bill: If your mbx directory is located on a network drive, then try to move all the files to a directory on a local harddisk and retry.

I have sometimes had trouble with loading dll's from a network drive.  

regards

Bo Victor Thomsen

Reply all
Reply to author
Forward
0 new messages