With the MDI form I figured that if you can create a form in a DLL then you
could create a MDI form to be called into my MDI parent.  It doesn't really
matter too much.  Basically the reason I'm looking into DLLs is that my
application will need constant updating so it would be easier and a lot less
Kbs when downloading the updates... Update only the modules which need
updating rather than the whole exe every time.  For my application think of
it like Outlook Express, the main screen is my exe, when you click on say
the accounts section, that will be called from a DLL.

As for your project, at this line:

Set SampOb = New SampleObject

And this line:

Set Ob = CreateObject("SampleDLL.SampleObject")

I get Run-time error '429': ActiveX component can't create object

mayayana wrote:
>> What does 'Private WithEvents Frm
>> as Form1' do?
>
>   That's to use in the class of your DLL if you want to trap
> form events. The "Frm" variable was meant to be a variable
> in your DLL class, not the variable for your object within
> the main project.
>
>> What is a COM interface?
>
> Component Object Model. A COM object is registered
> in HKCR, along with its type library. A COM object also has a
> specific structure, such that the type library can be accessed and
> functions in the COM object can be discovered based on what's
> in that type library. A VB DLL is an ActiveX DLL, which is
> a COM DLL.
>
>    COM is basically ActiveX, though the definitions are murky
> because they're as much marketing as they are technical terms.
> A fun quote from "The Essence of COM", a book by a notably
> cranky author by the name of David S. Platt:
>
>    " The term ActiveX is another winner....the term
"ActiveX" has no
> technical meaning whatsoever, although it did have several
> different meanings at various times. It is today a branding prefix,
> the same as the letters "Mc" in front of all the food at the
> restaurant with the golden arches."
>
>   The Object Browser is actually a COM object browser. It reads
> COM object type libraries and displays what it finds. That's as
> opposed to non-COM DLLs like shell32.dll or kernel32.dll, for
> which there's no "self-documenting" functionality. With those you
> just have to know the function that you want. That's why there's
> "intellisense" for components added to your project but not for
> kernel32.dll, even though you may have declared a kernel32.dll
> function. You can get the function parameters popup for that
> because VB knows it from your declare, but you can't get an
> intellisense listbox menu because kernel32.dll doesn't "expose"
> a COM interface to know it's functions.
>
>> And that works OK.  Now I would like the DLL to be a MDI child form
>> to be called into my (obviously) MDI parent.  When I try to do this
>> it craps itself (it can't find a MDI parent form).  Is there any way
>> around this?
>>
>
>     Why would you put a form inside a DLL if you want it to be
> an MDI child? I don't understand what you're trying to achieve.
> The point of the DLL is that you can package functionality and
> make it easily accessible with a COM interface. The form inside
> your DLL is only accessible to the extent that you've provided public
> methods in the DLL class(es) that can act on it in some way.
> That form has no relation to an MDI form in your project.
>
>     In case it's any help, I've got sample DLL code with a form
> in it:
>    http://www.jsware.net/jsware/zips/dllsamp.zip
---
þ RIMEGate(tm)/RGXPost V1.14 at BBSWORLD * Info{at}bbsworld.com

---
 * RIMEGate(tm)V10.2áÿ* RelayNet(tm) NNTP Gateway * MoonDog BBS
 * RgateImp.MoonDog.BBS at 5/29/04 5:26:18 PM