Detecting VBA Function Caller

[hatman]

I would like to access the Call Stack programmitcally. Possible?

The twist:
I have an addin that has code to be run in the Workbook_AddinUninstall event. I would like to add a conditional that will only run this code If and ONLY IF the addin has been uninstalled by the user. I have another Addin (which is already distributed to a whole slew of people at my company) which will, in all likelihood, uninstall that addin now and then. That's okay, it's part of what that other addin is supposed to do. But when it does, I do NOT want the code in Workbook_AddinUninstall to be run. If it wasn't such a pain updating EVERYBODY's install of the other addin, I can think of about 10 different ways of solving my problem by modifying code in the psuedo-calling code...

Suggestions?

 

[Norie]

hatman

I'm sure I've seen this asked before and I don't think I've ever seen a comprehensive answer.

The only thing I've seen are workarounds.

 

[hatman]

Thats' about what I expected... thanx for breaking it to me easy, Norie... no chance that any of those workarounds might satisfy my requirements, I am sure...

 

[tusharm]

Maybe, develop add-ins that work irrespective of the state of other add-ins?

Thats' about what I expected... thanx for breaking it to me easy, Norie... no chance that any of those workarounds might satisfy my requirements, I am sure...

 

[hatman]

Maybe, develop add-ins that work irrespective of the state of other add-ins?

Never thought of that

All sarcasm aside, it's a good thought, but not one that is realistic here. Last year sometime, after distributing several addins, I came to the realization that updating those addins with bug fixes and enhancements was going to be a headache and a half... especially as I continued to distribute more addins So I conceived of a single addin that would compare the currently insalled version of each of my other addins with the latest available version. If required, this addin manager would (in my original concept) uninstall an out-of-date addin, then download and install the latest version. The concept was pretty simple, but the execution became more convoluted. In it's final form, it logs the current version of each addin into the registry, then uninstalls each of those addins before the application closes... then on application startup it is able to perform version comparison based on the registry entries and download the latest file before installing the addin. All of it's addin operations are performed based on the list in the registry. What I forgot to take into account were future addins that would need to be controlled by this addin manager. So I built a new addin... and when it is installed, it adds it's own information into the registry. And when it is uninstalled by the user, it deletes it's own information from the registry. In testing it, I discovered that the addin manager triggers the uninstall event, which causes the registry info to be deleted, so on startup the addin does not get re-installed. Bummer. Trying to figure this one out without buiding a new addin manager (can be done, but very time consuming, and since I am not in one of the Computer Departments, I really don't get a lot of resources to play these games). If you have any suggestions, I would LOVE to hear them.

 

[Wolfshead]

Hi
I'm not sure if this will help (or if it's even possible with addins) but could you :
Construct the addin to be a series of modules exported as bas files or even contained in another workbook.
On opening the addin it would use VBE to read in the code modules it requires to perform its functionality. All you would need to do it to amend the contributory modules.
Hope this helps

Wolfshead

 

[hatman]

Thanks for your idea, wolfshead.

It turns out, however, that this is all moot. The machine that I was using to test the interactio of my code did not have the latest version of my addin manager on it. This drove me to add registry manipulations in my new addin, which caused all kinds of problems. When I built my addin manager in the first place, it seems that I created a class module that would perform the registry manipulations upon install or uninstall of a controlled addin... and the event handler gets disabled before the manager starts uninstalling the other addins, therefore the registry settings do not get deleted . I simply updated the addin manager on my test machine (to coincide with the version that everyone else has) and eliminated the registry manipulations from the new addin, and voila! the whole things works like it's supposed to.

 

[Jaafar Tribak]

I am not sure I follow this properly, but how about settinga Public Boalean flag in the Calling Addin to indicate\signal if the Uninstall event is called by the calling AddIn ?

Regards.

 

[hatman]

I am not sure I follow this properly, but how about settinga Public Boalean flag in the Calling Addin to indicate\signal if the Uninstall event is called by the calling AddIn ?

Regards.

Hmm, perhaps. Turns out, though, that since all of this particular functionality was able to be removed from the called procedure (since I forgot I had had put it all in the calling procedure in the first place) the called procedure no longer needs to know whether it was called by a procedure or directly by the user...