Ok I was able to compile my first dll, but when I try to use it I ran into problem, of course. :twisted:
I tried put it in the program dir but on first call to the dll I got an error 53 File not found: acchtdat.dll, moving it to system32 gives same result.
I then try to register it resulting RegSvr32 trow at me
LoadLibrary("C:\WINDOWS\System32\acChtDat.dll") failed - The specified procedure couldn't be found.
Which procedure? LIBMAIN? Isn't that one put in by FF?
A search at PB Forums turned up this threed (http://www.powerbasic.com/support/forums/Forum6/HTML/002912.html) which explained the register thing, but still the dll can't be found, at least not by that name! The dll with that name IS really there in system32!
I have checked all my aliases and they should be fine. However, I have only given ALIAS to the exported Functions/Sub as it shouldnt be needed for the Private ones only used inside dll.
In my VB app calling the dll I have these declares
Private Declare Function ChartsGetUDT Lib "acchtdat.dll" (LoadType As Long, udtReturn() As ChartDataUDT) As Long
Private Declare Function ChartGetUDT Lib "acchtdat.dll" (LoadType As Long, udtReturn As ChartDataUDT, Index As Long) As Long
Private Declare Function GetChartsArr Lib "acchtdat.dll" (LoadType As Long, ArrReturn() As String) As Long
Private Declare Function GroupsLoadFile Lib "acchtdat.dll" () As Integer
Private Declare Function GroupsGet Lib "acchtdat.dll" (ReturnArr() As String) As Long
Private Declare Function GroupGetIndex Lib "acchtdat.dll" () As Integer
Private Declare Sub GroupSetIndex Lib "acchtdat.dll" (Index As Long)
Private Declare Function LoadCharts Lib "acchtdat.dll" (LoadType As Long) As Long
first function call is GroupsLoadFile giving the file not found error, I am stomped as I can't see anything being wrong - or do I miss something obvious here. This is my first real dll ever (except for activeX dll's) so it might be possible.
TIA,
Joakim
Hi JoakimS,
A couple of things - possibly not the solution, but maybe useful nonetheless.
Firstly, if you're running a VB application and calling a standard DLL from it, bear in mind that if you place the DLL in the application directory it will only work if you run the compiled EXE. In other words, if you run the program from the IDE, then as far as Windows is concerned, the "application directory" is wherever VB6.EXE is running from - generally something like "C:\Program Files\Microsoft Visual Studio\VB98\" - and that's where Windows will look for the DLL first. Obviously this shouldn't make any difference if you put the DLL in System32 though.
Secondly, I vaguely remember something about DLL names in VB DECLARE statements being case-sensitive. So using LIB "acchtdat.dll" when it's actually "acChtDat.dll" (as shown in your REGSVR32 error message) might not work. I'm not certain about this though.
Thirdly, you should always include the exact, case-sensitive alias in the declaration in VB as well as in the DLL. In the words of Ellen Ripley - "It's the only way to be sure". :)
That's all I can think of for the moment. Hope it helps.
Regards,
Pete.
First, Thanks for fast reply...
Quote from: Peter JinksHi JoakimS,
A couple of things - possibly not the solution, but maybe useful nonetheless.
Firstly, if you're running a VB application and calling a standard DLL from it, bear in mind that if you place the DLL in the application directory it will only work if you run the compiled EXE. In other words, if you run the program from the IDE, then as far as Windows is concerned, the "application directory" is wherever VB6.EXE is running from - generally something like "C:\Program Files\Microsoft Visual Studio\VB98\" - and that's where Windows will look for the DLL first. Obviously this shouldn't make any difference if you put the DLL in System32 though..
Exactly, and the same thing happens when I run the compiled exe, with dll in exe dir.
I put it in system32, just to be sure it was in the path. I would like to avoid putting it there. The problem is just that several of my apps are going to use it and putting one copy in each program dir also doesn't appeal as a good solution. I have a "common" dir for all my apps, but I'm not sure how to make it work putting the dll there as there is no way before hand I can set a fixed path for it in the source. A "standard" solution, I think" would be to put it there and register the dll but it doesn't seem to be possible to register PB/WIN dll's or?
Quote from: Peter Jinks
Secondly, I vaguely remember something about DLL names in VB DECLARE statements being case-sensitive. So using LIB "acchtdat.dll" when it's actually "acChtDat.dll" (as shown in your REGSVR32 error message) might not work. I'm not certain about this though..
Well I wrote post while I was trying different things, searching etc. to solve it myself - and spare you this :-) I had it named mixed case to start with but rebuilt whole dll project, giving it lower case - to be sure it wasn't any such this. So the LoadLib error msg was just "old".
Quote from: Peter Jinks
Thirdly, you should always include the exact, case-sensitive alias in the declaration in VB as well as in the DLL. In the words of Ellen Ripley - "It's the only way to be sure". :)
When ever I do this VB removes the aliases emediately, as it's exactly the same as the delared function name.
So I still stands stomped and blocked to get any further in testing the dll to see if it actually works as well - as intended!
Thanks anyway, even if it didn't help... I will continue to banging my head in the wall. Will try to setup a small testbed in FF to test with as I think it's easier then whit VB.
/Joakim
It has been a long time since I interfaced a PB DLL with VB. One thing for sure is that you do not use RegSvr32 with PowerBASIC DLL's (they are not ActiveX DLL's).
In the following quote you say that you only give Private declarations to the internal functions, yet you have declared the GroupsLoadFile function as Private ????
Quote from: JoakimSI have checked all my aliases and they should be fine. However, I have only given ALIAS to the exported Functions/Sub as it shouldnt be needed for the Private ones only used inside dll.
In my VB app calling the dll I have these declares
.....
Private Declare Function GroupsLoadFile Lib "acchtdat.dll" () As Integer
.....
first function call is GroupsLoadFile giving the file not found error....
I just checked the VB declare file that I generate for the Cheetah Database System and I declared my Alias functions using uppercase.
e.g.
Declare Sub xdbCreate Lib "CHEETAH2.DLL" Alias "XDBCREATEVB" (dbFile As String, FieldArray() As String)
You should also search your computer for any instances of the DLL that may already exist. Remove them and start off fresh. Create a separate directory and copy your VB exe and the DLL into it to test.
Quote from: TechSupportIt has been a long time since I interfaced a PB DLL with VB. One thing for sure is that you do not use RegSvr32 with PowerBASIC DLL's (they are not ActiveX DLL's).
Oh I wasn't aware RegSrv32 was just about activeX, I though "Register" a dll was to make it "known" by the system... well you learn something every day ;-)
Quote from: TechSupport
In the following quote you say that you only give Private declarations to the internal functions, yet you have declared the GroupsLoadFile function as Private ????
Quote from: JoakimSI have checked all my aliases and they should be fine. However, I have only given ALIAS to the exported Functions/Sub as it shouldnt be needed for the Private ones only used inside dll.
In my VB app calling the dll I have these declares
.....
Private Declare Function GroupsLoadFile Lib "acchtdat.dll" () As Integer
.....
first function call is GroupsLoadFile giving the file not found error....
I might expressed me in an unclear way, the delaration above is from the VB form where the dll is used. The function(s) are privare to the form. It should not need an alias there. However, in the dll the function is declared as
Function GroupsLoadFile Alias "GroupsLoadFile" () Export As Integer I'm new to PB so I maybe have got it wrong, but I understand it as the alias is how it's exported to the calling app, the other is the internal name used by PB or? At least that's what I can read out of the PB Help file.
Quote from: TechSupport
I just checked the VB declare file that I generate for the Cheetah Database System and I declared my Alias functions using uppercase.
e.g.
Declare Sub xdbCreate Lib "CHEETAH2.DLL" Alias "XDBCREATEVB" (dbFile As String, FieldArray() As String)
You should also search your computer for any instances of the DLL that may already exist. Remove them and start off fresh. Create a separate directory and copy your VB exe and the DLL into it to test.
So you actually aliases them the "other way round" in VB then compared to how they are aliased in PB? I assue with the above you either don't have any alias at all in PB or you have it
Declare Sub XDBCREATEVB Alias "xdbCreate " (dbFile As String, FieldArray() As String) ?
Well I will try it in various ways, a lot of hand work though as FF doen't change case for the procedure names, but I can live with that.
Progress! I have a 3rd party dll I make calls to from inside my dll, and I had omitted to give ALIAS in the DECLARE statements for them, assuming their "normal" case declarations I use in VB would work in PB as well - but not. adding an ALIAS exact same as Function name got me pass the file not found error - the dll loads!
Now I just have an no entry point error for a capitalized function name so restoring my old aliases should fix that.
YES!!! I'm back in business again!
Thanks for your concerns.
/Joakim