>--
>--
>> Hi,
>> I'm confused and in need of some enlightenment, or perhaps,
>whiskey!
>> Anyways, I currently believe that when I'm working on a project Group
>(.vbp)
>> with one project being a dll and the other being an exe that once the dll
>is
>> compiled that the reference for that .dll in the .exe should be changed to
>> the location of the compiled .dll (say Windows\System) BEFORE the .exe is
>> compiled.
>> Question #1 is this right or wrong?
>If you're making a DLL in VB it's an ActiveX DLL called through
>CreateObject.
>You don't need the path, just the ProgID, which is probably
>DLLName.DLLClassName
>> I currently believe the .dll HAS to be registered before the .exe can
>access
>> it.
>> Question #2 Doesn't the .exe *ask* the registry where the dll is? If this
>is
>> true then I should be able to put the dll in any file or directory
>> regardless of where it is referenced in the exe(vbp) but experimentation
>has
>> proven otherwise.
> VB registers it without asking and uses the project folder as path. You
>can confirm that by looking it up under HKCR\CLSID key. Since the object
>is identified through that key it won't be found unless it's at the path
>listed there.
> HKCR\DLLName.ClassName will list the DLL's GUID.
> HKCR\CLSID\[GUID] will show the path.
>> Question #3 If I make changes to said .dll and make it Binary Compatible
>to
>> the previous version can I simply "switch out" the dll's or do I have to
>> unregister the old and register the new and (hopefully) NOT recompile the
>> .exe?
>I think that's true but if you set binary compatibility you should make sure
>that the interface is backward compatible. (i.e. don't change arguments
>in existing functions).
>> Question #4 Why oh why are the runtime files (oleaut32, etc) that are in
>> Windows/System on 98/ME machines placed in Windows/System32 on NT/XP
>> machines?
>It's still %System%
>> Thanks for any assistance,
>> Scott