Excel 2000. I have wkbUtils.xla with an auto-signed certificate, Excel
Security on High.

wkbUtils.xla opens at Excel startup and Workbook_Open runs, creating
an on-the-fly command bar with an msoControlPopup control. I loop
through one of the modules' CodeModule Property to find the names of
all the subs there and place in an array, vProcs(). Back on the
msoControlPopup I then add an msoControlButton for each each of the
subs in vProcs(), with the following OnAction:

.OnAction = "'wkbUtils.Runner " & """" & vProcs(i) & """" & "'"

As you can see, instead of calling each sub directly, I call
wkbUtils.Runner, passing the sub name to it. Runner then brings up a
userform with various controls allowing the user to set options and
then click "Run" to start the macro. It also contains a progress bar.

The problem is, when I have Security set to high, and click one of the
msoControlButtons, it won't run wkbUtils.Runner. It's as if because
I'm adding another level of "calling" to the mix, it doesn't recognize
that Runner is in a trusted, certified workbook (in fact, the same
workbook that it already ran code from).

It works if security is at medium? I had heard that along about SP3 of
xl2000 (as I recall) and later versions of Excel, this undocumented
convention for passing an argument to an onaction macro was not supported.
Maybe it has to do with the security setting.

--
Regards,
Tom Ogilvy


"Ladislav Ligart" wrote in message
om...
Excel 2000. I have wkbUtils.xla with an auto-signed certificate, Excel
Security on High.

wkbUtils.xla opens at Excel startup and Workbook_Open runs, creating
an on-the-fly command bar with an msoControlPopup control. I loop
through one of the modules' CodeModule Property to find the names of
all the subs there and place in an array, vProcs(). Back on the
msoControlPopup I then add an msoControlButton for each each of the
subs in vProcs(), with the following OnAction:

.OnAction = "'wkbUtils.Runner " & """" & vProcs(i) & """" & "'"

As you can see, instead of calling each sub directly, I call
wkbUtils.Runner, passing the sub name to it. Runner then brings up a
userform with various controls allowing the user to set options and
then click "Run" to start the macro. It also contains a progress bar.

The problem is, when I have Security set to high, and click one of the
msoControlButtons, it won't run wkbUtils.Runner. It's as if because
I'm adding another level of "calling" to the mix, it doesn't recognize
that Runner is in a trusted, certified workbook (in fact, the same
workbook that it already ran code from).

It works only at Low, and I'm at SP3.

Follow up:

I found that if I removed the parameter passing, my wkbUtils.Runner
proc is called even with security on High:

fails .OnAction = "'wkbUtils.Runner " & """" & vProcs(i) & """"
& "'"
works .OnAction = "wkbUtils.Runner"

So it's the parameter that's messing things up.

Other tidbit:

With the parameter in Runner, "wkbUtils.Runner" doesn't show in
Alt+F8. But when I remove it, it does show:

no show Public Sub Runner(ProcToRun As String)
shows Public Sub Runner()

So it seems Excel views macros with parameters somehow differently.

It doesn't really see them differently. You can't click on a macro that
requires an argument and hit run, which is pretty much wat the Alt+F8
approach is designed to do - so excel doesn't make them visible in the list.

--
Regards,
Tom Ogilvy

"Ladislav Ligart" wrote in message
om...
Follow up:

I found that if I removed the parameter passing, my wkbUtils.Runner
proc is called even with security on High:

fails .OnAction = "'wkbUtils.Runner " & """" & vProcs(i) & """"
& "'"
works .OnAction = "wkbUtils.Runner"

So it's the parameter that's messing things up.

Other tidbit:

With the parameter in Runner, "wkbUtils.Runner" doesn't show in
Alt+F8. But when I remove it, it does show:

no show Public Sub Runner(ProcToRun As String)
shows Public Sub Runner()

So it seems Excel views macros with parameters somehow differently.