Re: cleaning up Windows DLL (made with VB6)

Just for the archives, only of interest to anyone making a VB6 aX dll for
use as an Automation Addin for Excel, and wanting to use the "Register UDF"
method as referred to by the OP.

I tested the method (link in the OP's post) of writing help comments into
the Excel's function wizard (Shift F3) for functions in an "Automation
Addin" (which is what I had suggested earlier in this thread).

Unfortunately the method does not work quite as well as it does with VBA
functions in an xla addin. Although the help comments can be written, the
function will appear twice in two categories, one with the help comments and
in the other without. They will also appear as duplicate entries in the
"All" category, again with & without the comments.

This duplication problem is avoided in VBA by making the functions Private
(strangely even as private they are visible in cell formulas "after"
applying "the method"). Unfortunately the same trick cannot be used with an
Automation Addin, the functions must remain Public. The author has confirmed
same to me off-line.

The OP's question, I think, only relates indirectly to the above. He wanted
to make an ordinary dll with dummy API like functions as part of the process
used in the register function method.

Regards,
Peter T

"Smallweed" <Smallweed@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:851DEC8E-BBF7-4D71-9D81-2F653D541D85@xxxxxxxxxxxxxxxx
Hi - I'm new to Windows DLL programming and have been forced (kicking and
screaming) down this road because M/soft removed the functionality from
Excel
to be able to program descriptions for the arguments in user-defined
functions displayed in Excel's Function Wizard. To cut a long story as
short
as possible:

The best solution I can find involves some old Excel4 Macro coding
(documented at http://www.jkp-ads.com/Articles/RegisterUDF01.htm) which
involves aliasing the UDFs in your addin with functions in a Windows-style
DLL and then using the old REGISTER command. Suggestions include little
used
functions in user32.dll but I have too many (and am also a little
concerned
to tie-up unknown Windows functions) so embarked on creating a Windows DLL
of
my own with a thousand dummy functions (called Dummy1, Dummy2, etc) ready
for
aliasing: something I haven't any experience of either.

I program in VB6 (yes it's old-fashioned but it's all I know) and there's
a
way of creating proper Windows DLLs instead of the usual ActiveX ones
(which
don't work for the Excel problem) by introducing a DEF file and entry
point
by way of adapting the VB LINK.EXE file (see
http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html?page=1).

All works swimmingly: I can now make Windows DLLs from VB6 (the kind you
can
declare with Public Declare statements instead of having to create objects
in
your calling code) and, using this, I now have a DLL whose dummy functions
I
am able to use for aliasing my own UDFs to provide argument descriptions
for
Excel's Function Wizard. As per JKP's solution I use auto macros to use
Excel4's "REGISTER" to register all functions and then "UNREGISTER" to
unregister them again on exiting Excel.

Where things go wrong is if I unload the addin and load it again while in
the same session of Excel. I get an unhandled exception error (Excel.exe)
if
I try to type one of my UDFs from the Function Wizard and Excel crashes.
I
thought at first the UNREGISTER command wasn't doing its job but in fact
it
works fine when run by hand from the addin's code; it's only if the addin
is
unloaded then loaded that the problem arises. My guess is that I need
some
clean up code in the DLLMain. I currently have:

Public Function DllMain(hInst As Long, fdwReason As Long, lpvReserved As
Long) As Boolean
Select Case fdwReason
Case DLL_PROCESS_DETACH
' No per-process cleanup needed
Case DLL_PROCESS_ATTACH
DllMain = True
Case DLL_THREAD_ATTACH
' No per-thread initialization needed
Case DLL_THREAD_DETACH
' No per-thread cleanup neededEnd Select
End Select
End Function

Is there anything I need to put under both PROCESS cases so that the
relevant memory is released?
(thanks for your patience if you've read this far...)


.

Relevant Pages

  • Re: cleaning up Windows DLL (made with VB6)
    ... a new session of Excel. ... use as an Automation Addin for Excel, and wanting to use the "Register UDF" ... involves aliasing the UDFs in your addin with functions in a Windows-style ... I can now make Windows DLLs from VB6 (the kind you ...
    (microsoft.public.vb.general.discussion)
  • Re: cleaning up Windows DLL (made with VB6)
    ... The method you referred to works fine with an ActiveX dll (working with VBA ... Automation Addin functions will be double listed ... a new session of Excel. ...
    (microsoft.public.vb.general.discussion)
  • Re: Accesing functions in dll created in VBA
    ... > keyword to instantiate a class when accessing the dll from another ... code to VB and create the dll there. ... the one thing you can do is package your app as a COM Addin for Excel and expose your class from the COM Addin. ...
    (microsoft.public.office.developer.vba)
  • Re: cleaning up Windows DLL (made with VB6)
    ... First thing to say is that Register method can easily crash Excel if not ... Addins" which mean you your UDF in a cell formula can directly call the dll. ... involves aliasing the UDFs in your addin with functions in a Windows-style ...
    (microsoft.public.vb.general.discussion)
  • Re: cleaning up Windows DLL (made with VB6)
    ... screaming) down this road because M/soft removed the functionality from Excel ... involves aliasing the UDFs in your addin with functions in a Windows-style ... I can now make Windows DLLs from VB6 (the kind you can ... ' No per-thread cleanup neededEnd Select ...
    (microsoft.public.vb.general.discussion)
Loading