Does anyone know how to fire an event or tell when a user is looking at the source code to your Excel Addin?The reason for this, is that we have released a rather sensitive Addin which has the password turned on, but we want to make sure that people are not messing around with our source code, either extending it or stealing it.CheersSteve.

Two options come to mind:The first one is unpractical and probably easy to hack: Basically you somehow need to catch the event whenever Excel is running and the add-in loaded, even though the add-in itself is not executing. This would imply code external to the add-in in question, which monitors the VBA IDE objects and events. Since this external code must be running whenever the add-in is loaded, you'd probably want the add-in's initialisation routine to load its own 'monitor'. This external monitor could be in the form of another add-in (.xla/ .xll), or an .exe. . The difficulty is that both components must be secure. Another option along the same lines is to build a COM (.dll) add-in which hooks into the VBA IDE and monitors the IDE whether or not the add-in in question is loaded. But again, how do you prevent a savvy user from disabling it...The second and better option would be to take your sensitive code out of a VBA add-in completely and place it into a VB ActiveX control.Considering security alone, I would choose VB over VC++ because VB compiled in p-code is actually harder to crack/decompile/reverse-engineer than a dll/exe compiled in VC++. This is by far the easiest solution and should be secure enough for most purposes ... but then again there's nothing like a 100% secure system.

But has anyboby an tutorial (in pdf or word) describing how to create a dll with vba? I never made a dll.

Ok, yeah that was my first thought was to move all the code into a VB Active X dll, but it could mean a lot of extra work and testing, where as using the Excel events (if such a thing exists) to catch when someone is in the VB IDE would be a nice and easy implementation.

I am 99% certain the even you want doesn't exist.I am 100% certain I could crack it in <30 seconds.Fact is that VBA code is stored in (nearly) clear text in the XLS.Microsoft Visual C++, and several other toolkits come with hex editors, which would allow any vaguely competent programmer to lift your code without even starting Excel, so no events can protect you. As you no doubt know, VC++ is about as rare as herpes.The sort of person who steals code, is going to know these tricks, but of course the converse is not true, I won't steal your code, honest I've done a very quick piece on bunging VB code into DLLs in the "1st steps to create dll with VBA " thread.Is there widespread demand for such a tutorial ?You're right testing/Debugging is more work, the trick here is to "understand" the MS DLL mindset. Thus when you debug a server DLL you have to tell MSVC or VB that you're debugging the client application, in this case Excel.Thus you can set breakpoints in the VBA environment and the VB one on what you might see as the same code.DominiConnor

If the event does not exist within the VBA object model, you can use Win32 API calls to catch the appropriate messages. You are probably right about VBA code security (I've never tried it myself), but as I mentioned you'd need a lot of free time and more than a straight hex editor /debugger to work on an active x dll compiled to vb p-code.

Catchting the right messages without breaking Excel would be non trivial but it would work, at least for a given version of Windows/Excel.The best compromise is to pick a few critical functions, shove them in an ActiveX control. You can thus maximise protection/effort.Dominiconnor