Re: Using VB6 dll in Delphi app.



I'm the VB programmer on this project, and another guy is doing the
Delphi part.

System info:
Windows XP SP2
MSVBVM60.dll version 6.0.97.82, dated 2/23/04

I am using this hack:
http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html
to make a *windows standard* .dll with VB6. When I use it in another VB
app, using standard dll function calls, everything works great, the app
returns the values I expect, the logs are created, etc.

The trouble occurs when we try to use it in a Delphi app. After several
days of working with it, we can tell that it is getting into the
functions, but it appears that nothing which requires any kind of IO
from the dll is working, and throws Access violations in module
MSVBVM60.dll. A low level debugger shows that statements are executing
until we hit ones which require IO. This occurs whenever we try to
write to do debugging outputs such as writing to disk file, or pop up a
msgbox, and when we try to do real work such as make an OpenDatabase
call. If we only do internal processing (such as number crunching or
parsing the passed parameters), it works ok and returns what we expect.

We checked the obvious things:
we are using stdcall for the calling convention
the parameters are all aligned on 4-byte boundaries
variable types are compatible (VB long = Delphi Integer, etc)
DEP is set for "Essential windows programs and services only"

We use many of the structure (user-defined Types) definitions in other
working code, including a delphi dll used in VB, so we know they are
compatible.

One thing I'm not sure of is what I need in DllMain. Right now I've got
it always returning 1, but not doing any processing.

Any suggestions or pointers will be greatly appreciated. If it would
help, I can post source code as well...

Read the comments at the end of the article for a slew of potential problems using this technique, some of which you're
likely running into. One potential problem is that you have to add an /ENTRY parameter to the linker, which may be why
your DllMain() is not being called. Another is that to call a number of standard VB functions, the VB virtual machine
must be loaded first which may also be causing you problems.
One solution is to use the VBAdvance plugin for VB6, which handles these kinds of things for you and IIRC there was also
another mentioned in the comments section of the article.
And alternative solution still is to simply use an ActiveX DLL which VB can already create out of the box, and is easy
to use within a Delphi application (including COM niceties like events and objects.)
Hope this helps,

Mike


- Microsoft Visual Basic MVP -
E-Mail: EDais@xxxxxxxx
WWW: Http://EDais.mvps.org/


.



Relevant Pages

  • Re: difference between a .dll and .ocx????
    ... Windows), then it must be a COM library since, that's the architecture ... it's a function that is called when the DLL ... class definitions or just function libraries is actually besides the ... about the .dll or .exe adhering to the COM standard. ...
    (microsoft.public.dotnet.framework)
  • Re: Using VB6 dll in Delphi app.
    ... to make a *windows standard* .dll with VB6. ... The trouble occurs when we try to use it in a Delphi app. ... Read the comments at the end of the article for a slew of potential problems using this technique, ...
    (microsoft.public.vb.general.discussion)
  • Re: Danny Thorpe on Unicode and VCL
    ... > Why in 2007 should Delphi default to ANSI vs UNICODE, ... > the current standard since Windows 2000. ... Windows NT has been built on Unicode since its inception, ...
    (borland.public.delphi.non-technical)
  • Using VB6 dll in Delphi app.
    ... I'm the VB programmer on this project, and another guy is doing the ... app, using standard dll function calls, everything works great, the app ... The trouble occurs when we try to use it in a Delphi app. ... DEP is set for "Essential windows programs and services only" ...
    (microsoft.public.vb.general.discussion)
  • Re: Discovering variable types...
    ... >>Actually her beef is not about Windows ... > Is it worth the time to tweak a program or DLL, ... That is Ok if the runtime does not change, however Delphi BPLs and the ... >libraries, like OWL, CLX, or selfmade ones, are quite fruitless as long as they ...
    (comp.lang.pascal.delphi.misc)