Aktuelle Version vom 21:01, 30. Mai 2011

AccessCodeLib.AddInHost.[...]

Assembly: vollständiger Name inkl. AccessCodeLib.AddInHost.

• MS.net 4.0
• MEF ???
• Host für VBE + Office-App.
  • Add-in-Host für Office 2000 bis 2010 ff

• PIA - welche Version? - hoffentlich ohne spezielle PIA (late binding im Host)
• Vorerst keine Shims - getrennte Appdomain

• Laden von Plug-Ins - Host lädt Plug-In
  • Laden über:
    • zentrales XML
    • Verzeichnis + XML je Plug-In
    • Registry
  • Informationen von Plug-In:
    • Für User: Name, Beschreibung, Versionsnummer, URL, Copyright
    • Für Host: ID (z. B. direkt von Assembly), für welche Office-Anwendung(en) ist Plug-In, Einsatz von Plug-In ab Host-Version
  • Host: Ladeverhalten: wie VBE-Add-Ins
  • Lade-Reihenfolge festlegen? ... NEIN - (Noch nicht)

• Application-Objekt (VBE + Office-Application) liefern

---

• Zugriff auf Command bars / Ribbons
  • Weiche zw. Commandbar und Ribbon (nur Host ist dafür zuständig)
    • Kein direktes Reagieren auf CommandBar-Events im Plug-In - Nur Host reagiert auf Commandbar-Events
    • Eventhandler analog MS.net oder Delegates
  • Plug-In stellt nur Daten zur Verfügung vs. Host stellt Zugriff zur Verfügung
  • Funktionsumfang von Ribbon/CommandBar ???
  • Hot-Keys - Wer bestimmt? Plug-In legt fest, Host meldet doppelte?
  • Aufräumen - Command bar, ... STABIL

• VBE: Tool-Window erzeugen + bestehende verwenden (GUID)

• Office-Anwendungseigenschaft im Host für Plug-In
  • Dokument/Datenbank ist geladen
  • ...

• Fehlerbehandlung durch Host (z. B. ein Fehler über Event von CommandBar)
• Beobachten vom Laufzeitverhalten / Abgestürztes Add-In nicht mehr laden

• Optionen-Dialog (für Host + Plug-Ins?) - gemeinsame Optionen?
• Eigenschaften/Informationen vom Host für Plug-Ins (z. B. Username)