Newbie question (Run time error '48')

[Phed Leung]

I use NT 4.0, VB 4 and PB/DLL 5.

When I try to call a sub in VB 4, I got the '48' run time error.
I cannot figure out what causing this.

I have declared the sub like other API.
I have QuickViewed the DLL that I created, it looks fine to me.
Is there anyone can tell me what is wrong?

Thanks!


------------------

[Peter Lameijn]

Error 48 in VB can mean various things:

1. The DLL cannot be found. be sure it's in a place where it will be found.
2. Function declarations in VB and the DLL don't match. (Typo error or case not right).
PB/DLL exports functions capitalized by default.
3. Functions are not exported. Include EXPORT to them.
4. Your DLL uses functions in a third DLL that cannot be found. VB then gives error on your DLL.

That are some of the common pitfalls with VB...


------------------
Peter.
mailto[email protected][email protected]</A>

[Phed Leung]

1. The DLL cannot be found. be sure it's in a place where it will be found.

I put it in the same directory as VB.

2. Function declarations in VB and the DLL don't match. (Typo error or case not right).
PB/DLL exports functions capitalized by default.

They match. I use Alias to export the name.

3. Functions are not exported. Include EXPORT to them.

Already there.

4. Your DLL uses functions in a third DLL that cannot be found. VB then gives error on your DLL.

So far no, only the WinAPI.


------------------

[Lance Edmonds]

Try placing the DLL in the WINDOWS\SYSTEM or WINNT\SYSTEM folder, or give VB the explicit path to the DLL.

In the design environment, VB apparently does not look for DLL's in the current folder unless explicitly told to do so.




------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Don Dickinson]

One quick addition to what lance said, If you're using NT you might want to put it in the winnt\system32 directory instead of winnt\system as I have seen NT systems where winnt\system isn't in the path and doesn't automatically check there for DLLs. system32 has worked on every NT machine I've seen.

If you run your compiled program (instead of from the VB IDE) it should find the DLL in the application's directory.

Best Regards,
Don

------------------

[Fred Oxenby]

Originally posted by Lance Edmonds:
Try placing the DLL in the WINDOWS\SYSTEM or WINNT\SYSTEM folder, or give VB the explicit path to the DLL.

In the design environment, VB apparently does not look for DLL's in the current folder unless explicitly told to do so.

What is the current folder in design-environment?
In normal case.. C:\Program\Microsoft Visual Studio\VB98
That is, path to VB6.EXE (VB5.EXE etc)
So VB IS looking in the current folder...

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited November 09, 2000).]

[Phed Leung]

Try placing the DLL in the WINDOWS\SYSTEM or WINNT\SYSTEM folder,
or give VB the explicit path to the DLL.

Tried all three ways with no luck.


------------------

[Fred Oxenby]

Originally posted by Phed Leung:
I use NT 4.0, VB 4 and PB/DLL 5.

First VB4 is both 16-bit and 32 bit.
PBDLL 5.0 WILL ONLY WORK WITH VB4-32BIT

One quick thought...
Do you use full name of dll, that is

Declare Function MyFunc Lib "MYDLL.DLL" Alias ...()
and not
Declare Function MyFunc Lib "mydll" alias ...()

NT4 will not give you the default extension ".DLL" but WIN95/98 will....
You have to make sure that this apply to both your EXE
AND your DLL if your DLL reference some other DLL-s.
And as you use Win32Api.inc at least, check your includes as well.
MAKE SURE YOU HAVE THE LATEST INC-FILES

This is what MSDN says about error 48

Error in loading DLL (Error 48)
A dynamic link library (DLL) is a library specified in the Lib clause of a Declare statement.
This error has the following causes and solutions:
The file isn't DLL-executable.
If the file is a source-text file, it must be compiled and linked to DLL executable form.
The file isn't a Microsoft Windows DLL.
Obtain the Microsoft Windows DLL equivalent of the file.
The file is an early Microsoft Windows DLL that is incompatible with Microsoft Windows protect mode.
Obtain an updated version of the DLL.
The DLL references another DLL that isn't present.
Obtain the referenced DLL and make it available to the other DLL.
The DLL or one of the referenced DLLs isn't in a directory specified by your path.
Move the DLL to a referenced directory or place its current directory on the path.

For additional information, select the item in question and press F1.

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited November 10, 2000).]

[Phed Leung]

>First VB4 is both 16-bit and 32 bit.
>PBDLL 5.0 WILL ONLY WORK WITH VB4-32BIT

I use the 32-bit one.

>One quick thought...
>Do you use full name of dll, that is
>
>
>Declare Function MyFunc Lib "MYDLL.DLL" Alias ...()and not
>Declare Function MyFunc Lib "mydll" alias ...()
>
>NT4 will not give you the default extension ".DLL" but WIN95/98 will....
>You have to make sure that this apply to both your EXE
>AND your DLL if your DLL reference some other DLL-s.
>And as you use Win32Api.inc at least, check your includes as well.
>MAKE SURE YOU HAVE THE LATEST INC-FILES

Tried with the same error. I did not $include anything.
I did all other API declaration with no .dll and they work fine.
E.g. Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliSeconds As Long)


------------------

[Peter Lameijn]

Maybe you can post a piece of your code (the declarations in VB and PB) too see if all is OK.
Still sounds like a declaration problem

------------------
Peter.
mailto[email protected][email protected]</A>

[Fred Oxenby]

Interesting...
I made a small DLL like this

Function Test()Export as long
 Function = 1
End function
   
From VB6 (Im lazy) I called it with this declare
Private declare function Test Lib "FIL_CLI3" Alias "TEST"()as long
---
With the DLL in VB-folder it worked great in IDE-environment
Then I compiled the project and run it, with the DLL in app-folder
   
Worked great in Win95/98SE/NT4/Win2000ME/Win2000PE
No problem at all
---
Well, I can tell you that I was stunned, because when I started out with
PB/DLL50 I had the same type of problem as you have, and I solved it
by using "FULLNAME.DLL" in capital letters. That was what I thought anyhow
---
But now I went to PBCC20.
Made a short program like this
      
Declare Function TEST Lib "FIL_CLI3"()As Long
   
Function PbMain() As Long
  Print Test
  waitkey$
End Function
    
This program run ok on Win95/98SE
But it fails on WIN2000ME, WIN2000PE and NT4
Errormessage "cannot find DLL-file FIL_CLI3 in the path provided..."
    
Now I am really stunned.
DLL-file is in the app-path
    
So, this problem is related to Powerbasic and operating system, not to VB.
      
That is, as I see it, [b]If your PB-DLL is calling other DLL-s[/b]
you have to obey the advice we have given you regarding full name of
DLL (capitalization is no issue). Otherwise you will get Error 53, file not found
in VB
   
VB have no problem with this as it seems to handle the default extension correctly.

Perhaps R&D wants to review this situation and put it on the list to fix
for the next release of PB/DLL


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited November 10, 2000).]

[Lance Edmonds]

Fred, what problem are you talking about here? Simply include the ".DLL" extension in the LIB clause and it will always work under all Win32 O/S's.

Please note that this requirement *is* described in the documentation for the DECLARE statement.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

PB Help-file

LIB
String literal specifying the name of the module in which a procedure
or function is located. This allows you to call Subs or Functions
which reside in DLLs.

What I suggest is that the compiler resolves the dll-name and add
the default ".dll" extension if it is missing, and nothing if it ends with a dot.
I always use "full name incl extension" but I can see where it become
a mess for new users, espcially if they are used to VB

Alternatively add a remark to the declare statment in help-file to inform
user about the diffrent requierments

I like my first suggestion best, as it solves the problem once and
for all..


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Lance Edmonds]

From the printed documentation (which is slightly more up-to-date than the HLP file)

LIB String literal specifying the name of the module in which a procedure or function is located. This allows you to call Subs or Functions that reside in DLLs. Unlike 16-bit Windows, you must include the .DLL extension in the name of the DLL you wish to access.

DECLARE SUB MySub LIB "USER32.DLL" ()

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

Nice, Lance
Beaten on my own home-field...
I should (of course) have checked the printed manuals as well
I rest my case


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Jeffrey R. Radue]

What about the people who buy PBDLL on-line? We only get the help file
version. Online sales is clearly the way of the future (and present). Seems to me that
both should be consistent. Just a thought.

Jeff

------------------

[Lance Edmonds]

Thank you for the comments guys! We do appreciate all feedback, be it good or bad. That is what helps PowerBASIC grow and improve our products.

Documentation, like software, is constantly being revised and updated. The current printed documentation was produced subsequent to completion of on-line help (and after PB/DLL started shipping).

While we have posted various errata issues on the on-line documentation available in the FAQ forum, this does not cover the differences between the on-line and printed documentation - IIRC, most of which are minor amounts of additional information over and above the on-line help file.

We hope that the next update to the documentation will surpass both current formats, and negate many (hopefully all!) of issues raised on the BBS.

On this basis, I can tell you that there will be a significant revision to the on-line help available in the future. Stay tuned!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Ian Cairns]

There seems to be a point here that has been missed. PBDLL.hlp is a separate file from the compiler. If PowerBasic has an updated help file, then why not make it freely available in the file download section?
Regards,

------------------
[email protected]

[Tom Hanlin]

There is no updated version of the help file to make available
for downloading at this time. We'll certainly consider the option
when a new version becomes available.

------------------
Tom Hanlin
PowerBASIC Staff