# Visual Basic > Visual Basic 6 and Earlier >  Problem Getting Picture from DLL

## couttsj

I have developed several VB6 programs that I have turned into DLL files using MakeDLL from Dansoft Australia. But I have run into a problem with one because it is using an object that I have not used before. Specifically, I am attempting to return a "stdPicture". When both programs are run in the IDE, it works fine. But when I compile the DLL and define a function to return the stdPicture, the program crashes in the IDE.


```
Private Declare Function GetPicture Lib "PicGen.dll" (bArray() As Byte) As StdPicture

Set Image1 = GetPicture(bArray)
```

I know there are a number of issues when making System API calls using strings, but I have never worked with pictures from a DLL, and I am having difficulty finding info on how VB6 handles API calls. I assume that StdPicture is returned as a handle. Any help would be appreciated.

J.A. Coutts

----------


## Elroy

This isn't an answer but just a curiosity.  Why not use an ActiveX DLL?  I didn't test, but I'm quite confident they'd return a reference to a StdPicture without any problem.

If you don't want to register it, FireHacker has some code where you can instantiate classes from ActiveX DLLs by using the DLLs path and class name.

----------


## couttsj

> This isn't an answer but just a curiosity.  Why not use an ActiveX DLL?  I didn't test, but I'm quite confident they'd return a reference to a StdPicture without any problem.
> 
> If you don't want to register it, FireHacker has some code where you can instantiate classes from ActiveX DLLs by using the DLLs path and class name.


ActiveX uses COM, and as such requires registration. Registering and deregistering is a pain in the butt when you have to make a change. After a while, the registry gets full of garbage because deregistration does not remove the registry ID. Standard DLLs do not require registration. For development, I simply leave it in the development directory and make sure the application uses that directory as the default.


```
Private Sub Form_Load()
    ChDir App.Path
End Sub
```

When perfected, I transfer it to "\Windows\SysWOW64", so that all 32bit applications can have access to it.

J.A. Coutts

----------


## dilettante

The jokes write themselves!

----------


## Elroy

> ActiveX uses COM, and as such requires registration.


I use 19 ActiveX DLLs in my primary application, and don't register any of them.  In fact, I don't register anything.  The entire application is entirely portable (since Windows XP).  I stuff the ActiveX DLLs into the EXE's resources, and pull them out when I need them.

As stated in post #2, Firehacker has developed code to use ActiveX DLLs without any need for doing anything with the registry.

Here's a post where I've worked out how to use it.

And here's the post on VBStreets in Russia where FireHacker originally posted it.  Thanks go out to The Trick for originally supplying this information.  It's my understanding that The Trick and FireHacker are friends.

Just as an FYI, FireHacker prefers that it be used as a "brick" with no alterations made to it, so it might be best to go directly to his code.

----------


## The trick

See this https://github.com/thetrik/VbTrickTh...jectContextDll - you don't need any add-ins to create a native dll.

CContextHolder.cls - initializes the runtime for an AX-Dll and you can call exported functions. The better way is to use Reg-Free to load Ax-Dlls without a registration or even load an Ax-Dll directly and create an object instance using this module.

----------


## VanGoghGaming

> ActiveX uses COM, and as such requires registration. Registering and deregistering is a pain in the butt when you have to make a change. After a while, the registry gets full of garbage because deregistration does not remove the registry ID. Standard DLLs do not require registration. For development, I simply leave it in the development directory and make sure the application uses that directory as the default.


You should keep your functions as "source code" which you can add to any new project instead of packing them into DLLs made by Dansoft Australia (whoever that is)! Furthermore the registry isn't what it used to be in Windows 98. Nowadays you could register thousands of ActiveXs and you wouldn't make a dent in performance. If you want to cut down on registration IDs, set your components to "binary compatibility" and then they will use the same GUID unless you break compatibility by changing the parameters of your functions.

----------

