.XLA: Making it an AddIn vs adding a Reference?

[Peter T]

I hadn't read about your xls open event code. That should all work fine with
Application.run which can also include non object type arguments such as
strings or values, but not arrays. For object types, need to pass it's
identity as a number or string, eg thisworkbook.name or Range.Address.

Regards,
Peter T

 

[(PeteCresswell)]

Per Peter T:

From what you describe, the addin does all the work and you don't need to
pass any arguments,...

When deciding whether to use a toolbar menu.button you may want to consider
how to restrict calls to the addin to process only relevant workbooks or

That's where the passed arguments come in.

 

[(PeteCresswell)]

Per Norman Jones:

Application.Run "'MyAddin.xla'!myMacro", parm1, parm2

I'm going with Application.Run just because I have a deadline and
bco limited brainpower.

It seems to work - even truncated to "myMacro", Parm1, Parm2

And that's good for me because I version-number my files, as in
PerformanceAnalysis.004.xla, PerformanceAnalysis.005.xla... and
so-forth. Needing the .XLA's name would break my little wagon.

One purely-informational (at least for the moment) question: it
looks to me like add-in code is not available to .Run when the
spreadsheet is opened via an instance of MS Excel opened up in MS
Access VBA code. Does that sound right? or are we back
omitting the .XLA name vs supplying it?

 

[Norman Jones]

Hi Pete,

I have no problem running a procedure
in an Excel add-in from another office
application.

I use the full path of the add-in because
it will work for any location and it will
open the addi-in if it is closed.

 

[Jon Peltier]

Use a constant for the file name, so it needs changing only once.

Const sAddIn As String = "MyAddIn.xla"

Application.Run sAddIn & "!myMacro", parm1, parm2

- Jon
-------
Jon Peltier, Microsoft Excel MVP
Tutorials and Custom Solutions
Peltier Technical Services, Inc. - http://PeltierTech.com
_______