Rubberduck: New @InvokedViaShape annotation

[IvenBach]

Justification
We're currently adding ProcedureNotUsed to a procedure that is accessed via form control (button - or genericly via a shape) and this feels like a code smell. Creating a new annotation to clarify this helps make clearer the intent of the access. The ProcedureNotUsedInspection should then be updated to mention this new annotation to aid discovery. If this procedure is invoked by buttons/shapes it should be marked with the @InvokedViaShape annotation to indicate this.

Description
Modules with the annotation will be self documenting as to how they are accessed.

Additional context
Alternate names @AccessedViaShape, @AccessedVia( { Button | Shape | ... } ), @InvokedVia ( { Button | Shape | ... } ). I'm not stuck on any particular one.

[bclothier]

Note that this isn't host-specific; Access would need this for macros, too. I imagine other hosts have similar entry points. I think to make it generic, it should be '@InvokedVia("whatever") where the arg is required. It's then up to the user to document how/what is invoking this "not used procedure"

[Vogel612]

We could make this even more general, actually. What about @EntryPoint?

[retailcoder]

I like @EntryPoint quite a lot! I think the argument (if any) should be optional though.

'@EntryPoint
Public Sub DoSomething()

Should be just as valid as:

'@EntryPoint("CommandButton1")
Public Sub DoSomething()

Usage guidelines (we need that!) should mention that the string argument is not validated against the host document (i.e. nothing warns you if there's no CommandButton1 on any sheet, for example).

[bclothier]

Why would we want just @EntryPoint without the argument? Don't we want to encourage users to document their code? Even if the argument can't be validated, it's still better than just saying it's magical.

[retailcoder]

@bclothier in many of my projects there's nothing but a gigantic "Click Me" button/shape that's attached to a macro, it's the only entry point, and the name of the shape/button is irrelevant - I'd slap an @EntryPoint annotation there and be done with it: I'd find it annoying to be forced to supply an argument that I don't need and that isn't helpful.

OTOH having the possibility to add an argument to easily identify what's being called by what, is very welcome - I just wouldn't want to be forced to put it in.

[Vogel612]

There's another use-case for @EntryPoint without arguments: If the project is intended as a library, the entry point is callable from arbitrary external code and therefore has unknown triggers. Also isn't there the possibility of wiring multiple buttons to the same macro?