That is an interesting approach, and I will have to try it out. In the
meantime, another wrinkle: Solver will not work on a protected worksheet.

What a roller coaster I have been on. I was so excited when I found I could
install solver with code, then found out it will not work on a protected
worksheet.

Then was excited when I found out I could invoke it while on an unprotected
sheet, then let down again when I got a message saying target cell had to be
on an active sheet.

There is no workaround for this, I don't think, but I am going to keep
chewing on it



"Tim Williams" <saxifrax@pacbell*dot*net wrote in message
...
You could always use two workbooks: one protected one with all the
"secret" stuff and one unprotected one which has the solver reference. You
could then expose the solver functions through the second workbook to your
code in the first one.

Caveat: never done this. But seems like it should work.

Tim.


"William Benson" wrote in message
...
I need to protect a workbook's VBA project. But I do not know how to do
this while at the same time preserving the right to set and unset
references to dll's at runtime (My code adds the solver add-in and sets a
project reference to it). Not only that, I cannot let the user set a
reference manually and save the workbook, because I would have to give
them the VBA Project password in order to make this change.

I might save a workbook with reference already set, prior to
distributing, but I am sure that will result in broken links for some
users.

Can someone help me out of this Catch 22? My client does not want the
project viewable.

Is the answer to build compiled modules in an ActiveX.DLL? He doesn't
want to pay for that as of now.

Bill Benson